Moin,
> You probably need to think about DNSSEC-signed responses to DNSKEY
> queries (particularly during key roll scenarios) , and also DNSSEC-
> signed NSEC queries.
I was not aware that there are cases where a recursive resolver sends
DNSSEC-signed responses to an authoritative to solicit a reply. Can you
point me to some further reading on this?
> > - 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.
In case it was not clear, iirc, the vocal voice was you, making the
same argument, but then in favor of not adding anything to the document
that might include guidance on recursive's behavior.
> > - 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?
This argument, equally, applies to anything else that could be written
in a document.
What if the authoritatives do not include RRSIGs even though asked for
them? What if an authoritative replies to a different port than the
source port of the query?
> as I said above I find to hard to agree that the population
> of recursive resolvers (that matter) is in fact that great.
>
No, above you made the claim that the population of recursive resolvers
that matter, as they serve towards a major portion of the stubs, is in
fact around 80% of all delivered responses.
> > 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.
>
I believe we both understand the semantics of 'regulating' in that
sentence as 'include operational guidance on the behavior of recursive
resolvers transport protocol selection for serving responses to stub
resolvers in the document', with the emphasis being on 'transport
protocol'.
> > 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"
I honestly find this quote-reply mildly difficult, as it cuts the
context of my quoted text. The quoted statement was specifically made
in the context of how recursives should behave for transport protocol
selection (instead of IP), i.e., that being a scope extension likely
better fit for a dedicated document due to the complexity of the
subject.
The point made there is that delving into specifics of resolver
behavior towards stubs downstream would again expand the scope of the
single document, suggesting instead that more targeted and hence
smaller documents collected in the BCP as a set (see below) might be
more sensible than one huge bike-shed-document.
Constructing a refusal to provide evidence out of that is... mildly
odd.
> 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).
Still, HE does not have a 'this does not apply to DNS' phrase, iirc.
And whatever is done, it should also lead to increased consistency
between documents. Hence, either we make it explicit here or there what
should be done.
> >
> not an option I favour, as is evident from my comments :-)
I might have read a slight indication of that between the lines.
> > - 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.
Not necessarily (Steurer et al., IMC 2024). ;-)
> 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.
Even though I see some appeal in leaving everything as is and going
back to tcp/6667, I would argue that the Internet as a whole disagrees,
and we should give this a try, at least.
> > - 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.
Yes, and at the same time it would create a rather large document where
somebody somewhere will always find some hair in some aspect. Hence, I
would argue that a small badge approach with contained documents
focusing on specific aspects is generally advisable here, especially
when the claim of the problem being to complex stands in the room.
> > - Add these considerations to the discussion around
> > draft-pauly-v6ops-happy-eyeballs-v3
>
> I would argue against that. The DNS is different.
Then it should say so somewhere. Especially with DNS-over-* becoming
more and more prominent.
> like I aid above this is not a well understood space, and I don;t
> thinkthat we understand what is a BCP in the context of protocol
> selection and the DNS.
I would argue that the BCP should be a set of documents instead of a
single large and difficult to maintain one, describing the ideal
operational parameters for different aspects of DNS infrastructure,
i.e., providing contained documents that focus on a specific aspects to
make it clear what is described where.
> 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.
If i remember correctly, the draft does not say anything about
_preferring_ IPv6 for DNS resolution. The draft just says that both
IPv4 and IPv6 should be supported, instead of only IPv4.
Creating a more easily attackable argument ("lets prefer IPv6 for DNS
resolution") instead of the actual statement ("lets also support IPv6
for DNS resolution") is not really a discussion style that is rather
pleasant to engage with.
> 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.
This is again a somewhat difficult paragraph. The statement I made
("nailing that door for good") referred to 'take the more complex
route, write multiple documents, and pull them together in the BCP to
cover all bases'; Making a 'we just need to write more drafts!' out of
that is... well... as I said, difficult.
> We should not be avoiding that work, in my opinion.
The one who claimed that we are incapable of that work, implying that
it should not be done, was you, in the email I am replying to.
As said above, I argue for "nailing that door for good" by providing a
set of (instead of one overly lengthy) documents addressing all aspects
carefully, which then also allows for easier maintenance of the BCP in
the future by containing more segmented and hence easier updateable
individual documents within the BCP.
So, which draft do you take? In my proposal of covering bases i still
see these untaken:
- draft-huston-dnsop-dns-auth-transport-selection
- draft-huston-dnsop-dns-rec-transport-selection
Then, though, reading it again, it might suffice to actually merge
those
two; Or split the 3901bis into rec/auth as well for set consistency.
With best regards,
Tobias
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
