Tuesday, November 8, 2022< ^ >
Benno Overeinder has set the subject to: DNSOP interim-2021-dnsop-03
Room Configuration
Room Occupants

[09:21:11] <zulipbot> (Tim Wicinski) Can folks hear me or see those slides?
[09:22:56] MarcoSIDN@MacPro joins the room
[09:26:43] <zulipbot> (Ralf Weber) We heard you typing earlier, but its quiet now
[09:27:55] <zulipbot> (Tim Wicinski) thx do have the noisy keyboard
[09:33:35] <zulipbot> (Nigel Hickson) Good morning indeed.  Thanks for Session
[09:33:49] <zulipbot> (Tim Wicinski) with my noisy keyboard !
[09:33:49] <zulipbot> (Tim Wicinski) taking notes via
[09:37:17] <zulipbot> (Peter van Dijk) audio is terrible
[09:37:47] <zulipbot> (David Lawrence) Lots of static and echo from your link, Tim
[09:37:47] <zulipbot> (Hazel Smith) OK, so it's not jujst me that's hearing the "darth vader" voice?
[09:38:00] <zulipbot> (Anthony Somerset) tim your mic seems to be causing some wierd dalek like inteference
[09:38:00] <zulipbot> (David Lawrence) Getting worse
[09:38:13] <zulipbot> (Anthony Somerset) @meetecho may need your assistance incase its a room issue
[09:38:26] <zulipbot> (Suzanne Woolf) @meetecho we're having some trouble with echoes for a remote speaker
[09:38:27] <zulipbot> (Wes Hardaker) tim turn off and back on again.
[09:38:39] <zulipbot> (Daniel Gillmor) it's echoing bees
[09:38:40] <zulipbot> (Suzanne Woolf) thx
[09:38:53] <zulipbot> (Shane Kerr) Wow reboot actually worked.
[09:39:06] <zulipbot> (Suzanne Woolf) There is no need to reboot Tim :-)
[09:39:06] <zulipbot> (Daniel Gillmor) the bees are returning
[09:39:19] <zulipbot> (Peter van Dijk) small numbers of bees spotted
[09:39:19] <zulipbot> (Peter van Dijk) they're gaining ground
[09:39:30] MarcoSIDN@MacPro leaves the room
[09:39:32] <zulipbot> (Warren Kumari) Turn if off and on again!
[09:39:32] <zulipbot> (Jan-Frederik Rieckers) And it gets worse again.
It seems that the audio signal is duplicated somehow.
[09:39:34] MarcoSIDN@MacPro joins the room
[09:39:47] <zulipbot> (Anthony Somerset) its starting to degrade again
[09:39:47] <zulipbot> (Anthony Somerset) tim your mic seems to be causing some wierd dalek like inteference
[09:40:00] <zulipbot> (Jan-Frederik Rieckers) and the duplicated signal is delayed. Wow. I would really like to know how this could happen....
[09:40:00] <zulipbot> (Tim Wicinski) I'll drop out.  Arrggh !
[09:40:13] <zulipbot> (Anthony Somerset) its starting to degrade again
[09:40:13] <zulipbot> (Tim Wicinski) We agree !
[09:40:26] <zulipbot> (Warren Kumari) Yup, an echo and a delay >= the echo canceller time
[09:41:37] <zulipbot> (Éric Vyncke) WG chairs have the 'power' to request a DNS directorate review
[09:41:52] <zulipbot> (Tim Wicinski) Thanks Eric V!
[09:41:52] <zulipbot> (Tim Wicinski) We shall
[09:42:05] <zulipbot> (Suzanne Woolf) Happy to push the relevant button to get a review-- good reminder to have, thx Geoff
[09:42:18] <zulipbot> (Éric Vyncke) 👍
[09:42:31] <zulipbot> (Lorenzo Miniero) Looks like that's the audio stream we're getting from the browser, so it's not a mixing quirk on our end. Tim, have you tried using a different browser just to see if that may fix it?
[09:42:57] <zulipbot> (Anthony Somerset) is it just me or does the network feel flaky/laggy in the room?
[09:43:11] <zulipbot> (Warren Kumari) DNSDIR Review requested.
[09:43:45] <zulipbot> (Warren Kumari) Much thanks to everyone who serves on the DNSDIR and the DNSDIR secretaries....
[09:43:58] <zulipbot> (Tim Wicinski) Using Firefox @lorenzo, I could try Brave; Safari but not during the session
[09:48:19] MarcoSIDN@MacPro leaves the room
[09:48:43] <zulipbot> (Warren Kumari) I can probably drives the slides if that helps?
[09:50:27] <zulipbot> (Tim Wicinski) it appears to be stuck "processing decks"
[09:50:52] <zulipbot> (Anthony Somerset) @**Lorenzo Miniero**  heads up
[09:51:11] <sftcd> I get a 404 for
[09:51:18] <zulipbot> (Tim Wicinski) This is a good reason to get your slides in early
[09:51:57] <zulipbot> (Alessandro Amirante) yeah it seems that the deck is not available on the datatracker
[09:52:10] <zulipbot> (Alessandro Amirante) it 404s
[09:52:27] <zulipbot> (Tim Wicinski)
[09:52:40] <zulipbot> (Warren Kumari) Reuploading them....
[09:53:54] <zulipbot> (Warren Kumari) Plan is that I can just share my screen with the sldies if that works for the chairs...
[09:54:10] <zulipbot> (Suzanne Woolf) @meetecho we're having a very weird problem with slides in the datatracker
[09:54:23] <zulipbot> (Suzanne Woolf) OK thx Warren
[09:54:39] <zulipbot> (Alessandro Amirante) they should be available now
[09:54:42] dkg joins the room
[09:55:07] <zulipbot> (Benno Overeinder) Thanks!
[09:55:20] <zulipbot> (Tim Wicinski) So Roy gets Willem to give his talk?!?
[09:55:30] <sftcd> I'm not sure but think the dns name on that slide should be :-)
[09:56:10] <dkg> says "Defolio is run by Estonian Marketing Association"
[09:56:28] <sftcd> yeah, that's not mine:-)
[10:08:22] <zulipbot> (Mark Andrews) will need fixing as the slides are not there yet
[10:08:42] <zulipbot> (Peter van Dijk) I've been ignoring the .alt draft, as an implementer. I see now that I was wrong about that. This keeps happening :)
[10:08:55] <zulipbot> (Benjamin Schwartz) I vote for MAY
[10:09:12] <dkg> why would MAY be preferable to SHOULD ?
[10:09:21] <dkg> "weird" is not a good argument against
[10:09:35] <zulipbot> (Benjamin Schwartz) (... with some language explaining that they're not allowed to break DNSSEC in the process)
[10:10:01] <zulipbot> (Mark Andrews) .onion hacks break DNSSEC
[10:10:27] <zulipbot> (Peter van Dijk) MAY sounds better than SHOULD, but still seems way too strong
[10:10:53] <zulipbot> (Benjamin Schwartz) Another option would be to simply note that Local Root is allowed, which subsumes this
[10:11:17] <zulipbot> (Eric Orth) Maybe a better argument than "weird" is that informational implies a lack of strict requirements and thus MUST and maybe SHOULD become a bit ambiguous as to how strict of a requirement it actually is.
[10:12:50] <zulipbot> (Peter van Dijk) to qualify "some resolvers", it looks like Unbound and Knot Resolver handle .onion specially by default; BIND and PowerDNS Recursor do not
[10:13:16] <zulipbot> (Ralf Weber) Akamai Cacheserve also not
[10:13:42] <zulipbot> (Peter van Dijk) thanks - can't "git grep" that one here ;)
[10:13:55] <zulipbot> (Andrew Campling) Listening to thia presentation seems to make an increasingly strong
[10:14:23] <zulipbot> (Stéphane Bortzmeyer) DNAME in the root:-)
[10:14:55] <zulipbot> (Andrew Campling) *Listening to this discussion, it seems to make an increasingly strong case for not moving forward with .alt
[10:15:28] <zulipbot> (Benjamin Schwartz) Also, Aggressive NSEC will minimize the number of queries to the root anyway
[10:17:54] <zulipbot> (Tim Wicinski) Queue is closed, folks can place their comments here and will be incorporated into minutes
[10:18:08] <zulipbot> (Warren Kumari) +QNAME minimization....
[10:19:08] <zulipbot> (Ray Bellis) With my RSO hat on - I disagree with those assertions.    We simply cannot know at this point.
[10:20:09] <zulipbot> (Ray Bellis) If name spaces under .alt end up being very popular then the leakage load could become significant.
[10:21:05] <zulipbot> (Warren Kumari) ... but if there is no .alt, the same thing is true. Having them in .alt means that negative caching can help suppress.
[10:21:26] <zulipbot> (Warren Kumari) I think it isn't "if things in .alt become popolar", it is more "if alternative resolution things leak"
[10:21:43] <dkg> meetecho: minor echo of the remote speaker via the room mic
[10:22:16] <dkg> i think the speaker can hear it too
[10:22:16] <zulipbot> (Ray Bellis) if we're going to put requirements on resolvers, it should be on *stub* resolvers only.
[10:23:36] <zulipbot> (Viktor Dukhovni) We have language for .HOME that covers synthesis.
[10:23:51] <zulipbot> (Viktor Dukhovni) So .alt can be handled just like .HOME
[10:24:09] <zulipbot> (Ray Bellis) there is no .home - Homenet got forced to use instead
[10:25:25] <zulipbot> (Suzanne Woolf) Those who we had to kick out of the queue-- apologies and if you put your coments in the chat they'll be picked up in the minutes
[10:26:38] <zulipbot> (Warren Kumari) We could ask them too -- some implementations may do it - e.g systemd people are quite active at adding things.
[10:26:51] <zulipbot> (Eric Orth) As a stub implementor, I'd appreciate a MAY on dropping alt queries, just as general permission in case I ever get around to adding it.
[10:27:04] <zulipbot> (Lars-Johan Liman) In response to @**Benjamin Schwartz** : the queries are not supposed to appear at all. If you leak a query to you local resolver, I'd argue that not responding at all is the appropriate way to treat this. No need neither for doing a full cycle to find the "NXDOMAIN" from the root, nor for sythesizing. Just "shut up" or respond with "REFUSED".
[10:27:05] <zulipbot> (Warren Kumari) Sorry, context was unclear -- them == stub resolver people.
[10:27:35] <zulipbot> (Ray Bellis) @eric ultimately the "protocol" switch has to happen in the client (stub) anyway, at least w.r.t. those API calls that go into `gethostbyname()`, etc.
[10:28:15] <zulipbot> (Mark Andrews) Mirror zones and aggressive negative caching will suppress traffic to the root in recursive servers and keep DNSSEC  working
[10:28:28] <zulipbot> (Ray Bellis) so in this context when I say stub I mean the "name resolution service" on the client, *before* it gets to the point of saying "oh, you mean DNS"
[10:28:56] <zulipbot> (Benjamin Schwartz) @Lars If this is "not a protocol change" then I think it's clear that it shouldn't change the behavior of recursive resolvers, and we should still be able to ask "does .alt exist in the root" and get a signed answer.
[10:30:01] <zulipbot> (Mark Andrews) Do not intercept queries for .alt in recursive servers.  The above two solutions should be enough.
[10:30:01] <zulipbot> (George Michaelson) @ray putting "name resolution service"  into quotes gets to the point that it might be GNS or NIS/yellow pages
[10:30:21] <zulipbot> (Ray Bellis) @ggm yes, and that's a good thing.
[10:30:34] <zulipbot> (George Michaelson) ie its out-of-scope of the DNS to tell a host how it maps names
[10:30:47] <zulipbot> (George Michaelson) except where "name resolution service"  *IS* the DNS
[10:32:14] <zulipbot> (George Michaelson) It's probably just a language thing but when a document puts times in and its "five minutes" it feels like a heuristic to a human problem, not an algorithm. -"try it for a bit but give up if you want to make some coffee"
[10:32:27] <zulipbot> (Ray Bellis) The whole point of this draft is that it's *not* DNS, though.  Surely it's not our of scope to say that client stubs *MUST NOT* send their queries to the upstream DNS resolver?
[10:32:48] <zulipbot> (Anthony Somerset) EDNS client subnet resolution failures - i guess depends on the class of error - e.g. SERVFAIL vs NXDOMAIN
should we handle different error classes differently like we do email errors (permanent fails vs temporary fails)
[10:33:01] <zulipbot> (Benjamin Schwartz) @Ray If it's "not DNS", then surely there is no stub resolver!
[10:33:14] <zulipbot> (George Michaelson) @ray yea, I could go there. "hey, non-DNS implementors. if you implement a fallback, failover or side query to the DNS, do us a favour and don't ask for this list of things"
[10:34:01] <zulipbot> (Ray Bellis) @ben see above - I'm really talking one level below that, e.g. `getaddrinfo()`
[10:34:14] <zulipbot> (Ray Bellis) i.e. the NSS layer
[10:34:27] <zulipbot> (Peter van Dijk) note that 7871 currently prohibits ecs-scoped NXDOMAINs; that doesn't mean the same should go for failures, though
[10:35:04] <zulipbot> (Benjamin Schwartz) @Ray Leaving aside the question of whether that layer actually exists, what recommendation would you make about names containing characters that are not allowed in the root zone?  .alt is the same: a label that, by policy, is not permitted to appear in the root.
[10:38:32] <zulipbot> (Ray Bellis) @ben _if_ those queries leak to the root, return signed NXDOMAIN.   If the name is not in a form that's even legal in the DNS then they'll likely get a FORMERR from their configured DNS recursive resolver.   Either way, the client will get a name resolution failure and there's not much else we as DNS operators can do to mitigate that.    It's down to the client and its "protocol switch" to do the right thing and not leak.
[10:41:20] <zulipbot> (Mark Andrews) DNS allows any characters in the labels.  The root zone rules for `delegated zones` are DLH restricted.
[10:41:48] <zulipbot> (Ray Bellis) btw, another argument not to DNAME to AS112 for .alt is that anyone can stand-up an AS112 server, and without QNAME minimization the full .alt query name (if legal DNS) will appear in their logs
[10:43:18] <zulipbot> (Ray Bellis) @Mark I was thinking of the case where the name length or label lengths exceed DNS's constraints (255/63).  That said, I still think it would be a mistake for any alt naming system that wants to co-exist alongside the DNS to allow this.
[10:45:42] <zulipbot> (Stéphane Bortzmeyer) @**Mark Andrews** Not just a matter of allowed characters but also of size.
[10:45:55] <zulipbot> (Éric Vyncke) 'link local' can be weird when connected to multiple links though
[10:51:50] <sftcd> FWIW I'm in favour of progressing draft-homburg-add-codcp, not sure how feasible it is to expect stubs to implement, nor how often people use such local proxies, but I do have such a setup so would use it
[10:53:26] <dkg> can we stop saying that we don't standardize APIs?  we *have* documented APIs and they are deeply useful in clarifying our thinking about what we offer to the layers above us.
[10:53:37] <dkg> APIs do *not* evolve fast
[10:55:03] <zulipbot> (Ray Bellis) `getaddrinfo()` was defined in RFC 2553
[10:55:36] <dkg> i mean, some do, but some are extremely long-lived.   thoughtful API design can shape the ecosystem to align it with what features the protocols support.
[10:55:59] <zulipbot> (Stéphane Bortzmeyer) We are in 2022, guys, we no longer use only C, how to design and specify an API for N programming languages?
[10:57:27] <sftcd> given that "we want better than getaddrinfo()" has been clear for some years and seemingly nothing much has happened, I don't think that desire is a good reason to hold up or not do related work at this point (at the same time it'd be great if real work happened on "better than getaddrinfo()")
[10:57:33] <zulipbot> (Warren Kumari) REST!  <runs away>
[10:57:37] <dkg> Stéphane, there are still bindings from the C ABI to most programming languages, so that can be useful.  Or, for languages whose idioms are significantly different, it's possible to just take inspiration from an abstract API if it's widely understood.
[10:59:11] <zulipbot> (Sean Turner) Captive Portal API:
[10:59:39] <zulipbot> (Benjamin Schwartz) @Sean That's a protocol, not an API :)
[10:59:52] <zulipbot> (Warren Kumari) My question was what are the privacy / fingerprinting implications when these leak? Currently e.g an ISP resolver just sees lots of queries from my (IPv4) NAT. When the forwarder on my CPE blindly forwards these, doesn't it share a bunch more about my internal list of clients?
[10:59:53] <zulipbot> (Ray Bellis) on any POSIX system there's a good chance that other languages' name lookup functions internally use `getaddrinfo()` anyway.
[11:00:08] <zulipbot> (Sean Turner) I'll go back under my bridge.
[11:00:21] <zulipbot> (Warren Kumari) Erm. Isn't any IPC API basically a protocol?
[11:01:27] <zulipbot> (Benjamin Schwartz) @Warren Depends on whether it uses shared memory...
[11:01:40] <zulipbot> (Warren Kumari) I send you an RPC <message>, you send a <response>. These are formatted protocol messages
[11:03:10] <zulipbot> (Benjamin Schwartz) For API work at the IETF, I usually point to TAPS
[11:03:30] <zulipbot> (Warren Kumari) Even with shared memory -- I put a specially formatted "packet" in memory (this packet might be just '(int32) 17'), but we have an agreement on "octet 1 means X, octet 2 means Y". You parse and understand this message/language, and so do I...
[11:03:43] <zulipbot> (Warren Kumari) This is all navel gazing...
[11:04:23] <zulipbot> (Warren Kumari) (Sorry, unclear -- I meany my  "isn't IPC a protocol" is navel gazing)
[11:12:36] <zulipbot> (Peter van Dijk) -  Key Relay Mapping for the Extensible Provisioning Protocol
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!