Hi Tobias, I'll continue with the threading of this conversation, though it may be getting challenging to follow! :-)
> On 22 Oct 2024, at 6:40 PM, Tobias Fiebig <tob...@fiebig.nl> wrote: > > >> I'm sorry but I don;t understand the point you are making here. > > - A DNS query for an FQDN with a length of 255 using DNSSEC leads to a > 336b message on the wire. It is unlikely that we will cram enough > into DNS to raise this above 1280. You probably need to think about DNSSEC-signed responses to DNSKEY queries (particularly during key roll scenarios) , and also DNSSEC-signed NSEC queries. > - In the past, some vocal voices were rather clear that any changes > should be transparent for recursive implementations, as it is > unlikely that these will be changed so quickly. If you look at the pool of recursive resolvers and weight these resolvers against the population of users' stub resolver that they server the population of recursive resolvers that matter (i.e. cumulatively serve more than 80% of the entire user base) is small. change in recursive resolver behaviours is entirely feasible in today's public network. > - If a recursive receives responses from authoritatives adhering to > draft-ietf-dnsop-avoid-fragmentation-20, i.e., also the guidance > on authoritatives in draft-momoka-dnsop-3901bis-06, the messages > the recursive will receive will be fine. and if the authoritatives deviate from this behaviour? > - A recursive replying from cache might then create on-the-wire > messages that creates an issue. That, though, would either require > providing explicit guidance on recursive implementations w.r.t. > packet size, which was discouraged earlier given the difficulty of > changing all in-place implementations, or need to accept that this > already is a visible problem and in the authority of an individual > operator. as I said above I find to hard to agree that the population of recursive resolvers (that matter) is in fact that great. > > Hence, even though i do see the appeal in regulating this aspect, I > am currently unsure how it interacts with earlier suggestions on the > draft. we are not "regulating" - we are trying to offer good advice to increase the robustness of DNS resolution. > > Also, I do have some scope concerns. Resolving those, would likely > require a more comprehensive approach, ensuring a tighter per-ID > scope. once a document recommends a particular operational configuration that is at variance from current operastional behaviour it is an obligation of the part of the recommender to explain qwhat this recommendation is at worse harmless, and at best a distinct improvement. If the document claims that this is "out of scope" then I would argue that the recommednation itself is "out of scope" > >>> >> HE territory? For the acronym challenged (myself included) what >> are you referring to here? > > Ah, I was referring to 'Happy Eyeballs'; Initially in RFC6555, later > revised in RFC8305, this specifies how clients should interact in dual- > stack setting for selecting the IP protocol to use. > > At the moment, there is draft-pauly-v6ops-happy-eyeballs-v3 ongoing. > This draft also includes guidance on transport protocol selection as > well, even though--at the moment--this only provides guidance on TCP > vs. QUICK. Happy eyeballs has historically not applied to DNS resolvers, either at the stub or the recursive level. The operational practice of using "first to respond" in a DNS resolution comparison (A vs AAAA query) in HE tends to make the use of such a technique in the DNS itself kinda circular. Frankly I can understand why the DNS implentations have generally tended to avoid protocol bias in the ordering of the server addresses used by resolvers (i.e. why Happy Eyeballs is generally NIOT used in the DNS). > >> I would've though that a document that is recommending dual stack >> operation of DNS resolvers would either provide some clarification on >> its dual stack behaviour or provide a pointer to an RFC that >> contains this clarification. > > The idea here was to seperate the operational requirement (equal > footing operation of IPv4 and IPv6) in this document, in line with the > prior phrasing of RFC3901, while leaving the selection aspect out of > scope. Adding this in this document would conflict with the prior work > of generally specifying that behavior in a dedicated draft. > > This leaves, in my opinion, four options: > > - Leave this aspect unmentioned, as per the approach in the (pre HE) > original RFC3901 not an option I favour, as is evident from my comments :-) > - Create dedicated document(s) specifying transport protocol selection > for DNS (which might be relevant given the abundance of transports; > DoUDP, DoTCP, DoT, DoH, and all of that for v4 and v6); Especially > for DoT and DoH, though, this would also necessitate specifying > public key discovery for the authoritative and recursive case (i > recently pondered over TLSA in ADDITIONAL for that); There is also > the case of recursive discovery there, that needs to be addressed, > especially in the absence of PKI valid certificates; Even though > there TLSA in ip6.arpa/in-addr.arpa might be a thing. If we knew what we were doing and what we wanted to do in terms of DNS resilience this would make sense. By this I mean that a happy eyeballls approach of "prefer IPv6" does not make sense if the result is slower DNS resolution times. Like it or not IPv6 is far less tolerant of the margins of UDP behaviolur and in the DNS I can see why some folk woould cobnclude that speed to respond matters above all considerations. So if we understood what protocol selection means in the DNS if might be a good time to embark upon such a course of action. BUt I donl;t that our common understanding of the issues at play here is sufficient shared and understood to write such a document at this point in time. > - Add it in the current draft, potentially creating conflicting > guidance for DNS in comparison to the general efforts going on It's an option I favor. The document should explain why protocol selection has implications in terms of performance and robustness of the DNS and a blind adherence fo whatever "the general efforts going on" might di9ctate is not necessarily in the interests of the robustness and performance of the DNS itself. > - Add these considerations to the discussion around > draft-pauly-v6ops-happy-eyeballs-v3 I would argue against that. The DNS is different. > > I _personally_ would argue that the second approach would be the way to > go, aggregating the corresponding documents in a BCP ('a' BCP, as BCP91 > is currently 'DNS IPv6 Transport Operational guidelines'; The BCP could > rather become 'Operational Guidelines on Discovering, Providing, and > Selecting DNS Transports for Authoritative and Recursive Servers') like I aid above this is not a well understood space, and I don;t think that we understand what is a BCP in the context of protocol selection and the DNS. > > Such would then have to contain (at least; open for suggestions): > > - 3901bis > - draft-ietf-dnsop-avoid-fragmentation > - draft-tbd-dnsop-dns-auth-transport-selection > Guidance on how to select from available protocols; Would need > an additional document draft-tbd-dnsop-dns-auth-key-discovery > to enable DoH/DoT without names; Which should be straight > forward > - draft-tbd-dnsop-dns-rec-transport-selection > Expanding on, among others RFC9606, also needing an additional > document draft-tbd-dnsop-dns-rec-key-discovery for recursive > DNS key discovery in the case of DoH/DoT > > The issue there is that there are some rather neat things that can be > done, especially to bring DoT/DoH to authoritative DNS (via TLSA in > additional, given that that would signal proto/port already); > > However, there are also just 24h in my day, so if the WG would be > interested in a more fundamental 'all bases covered' approach that does > not blow a single document beyond clarity (imho), it might be good to > discuss this in Dublin more extensively (and have some of the documents > authored by more people, if there would be interest in such a > fundamental overhaul ;)); > > I do certainly see the appeal of nailing down that door for good by > creating an (extensible) BCP covering all bases. > ll this started when I responded to the original 3091-bis draft contending that a "lets prefer IPv6 for DNS resolution" was in fact NOT an operationally sound recommendation, and there are failure scenarios in today's DNS where such a recoomendcation imposed performance and robustness penaltiers. and we should avoid making such recommendations. In my view getting RFCs or BCPs out the WG's door is NOT the aim of the game we are in - it's provding well considered and useful advice about making stuff work!. I'd like to think that we all agree on that, and sometimes the seemingly simple (update 3901) has a set of quite complex implications. We should not be avoiding that work, in my opinion. cheers, Geoff
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org