> On 29 Jul 2021, at 10:12 am, Mark Andrews <ma...@isc.org> wrote: > > > >> On 29 Jul 2021, at 09:58, Geoff Huston <gih...@gmail.com> wrote: >> >> Hi Paul, >> >>> On 29 Jul 2021, at 2:10 am, Paul Wouters <p...@nohats.ca> wrote: >>> >>> On Wed, 28 Jul 2021, Geoff Huston wrote: >>> >>>> i.e. amend section 3 to read:... >>>> >>>> 3. Recommendations >>>> >>>> This document clarifies RFC1034 in that in-bailiwick [RFC8499] glue (being >>>> part of all >>>> available glue records) MUST be returned in referral responses, and there >>>> is a requirement >>>> to set TC=1 if all in-bailiwick glue cannot fit in the response. >>> >>> I think the reasons for returning non-in-bailiwick are the same as for >>> in-bailiwick glue. You want to give the client as many DNS servers as >>> possible to increase resilience of the zone. What is your argument for >>> making this less resilient? >> >> The current version of the draft proposes a mandatory (“MUST”) inclusion of >> all >> in-bailiwick glue records, all “sibling” glue records and is silent on all >> other >> (non-in-bailiwick) glue records. >> >> I had suggested text that was intended to maintain the approach already used >> in >> the draft but I suggested dropping the mandatory (MUST) inclusion of the >> so-called >> “sibling” glue records, and leaving the mandatory to include provision only >> relating to in-bailiwick glue records. >> >> Now the draft/operational advice could go in many directions at this point: >> >> a) for basic functionality of DNS resolution it should be mandatory (MUST) >> to include >> in-bailiwick glue records (it’s not clear if “all”) is appropriate for the >> basic >> functionality of the DNS resolution protocol. >> >> b) for more robust resolution performance it would be a good idea (SHOULD? >> MUST?) to include _all_ >> in-bailiwick glue records. >> >> It's unclear to me that a compelling case can be made to MUST include _all_ >> glue records in a referral >> response, particularly relating to non-in-bailiwick glue records. > > Take the case where only one of the servers for the delegated zone is > available. If it is not a > MUST you end up with resolution failures despite the server being available. > The MUST ensures that > the requisite bootstrapping record is available. > >> For me it appears to depend on the actions of the resolver as to whether >> this would be faster >> or not. If all resolvers blindly re-query using TCP for all UDP responses >> where TC=1 is seen in >> responses, then the additional query could be seen as wasted time that could >> contribute to >> slower resolution times. If resolvers actually treat TC=1 in a more optional >> manner, as in “more >> information is available, but if you've got what you needed to move on, then >> don’t bother >> with the TCP followup query.” I suppose it depends on how strictly one >> interprets the guidance in >> Section 9 of RFC2181, which appears to state that TC=1 means requery, to >> paraphrase the text >> in that RFC. >>
It's a tradeoff. If TC=1 mandates a requery using TCP then this additional robustness is gained at the expense of a slower resolution of a referral response. I would normally expect such tradeoffs to be described in terms of MAY or even SHOULD to guide the implementer / operator as to a suggestion resolution of these factors while still leaving room for some folk to tailor their DNS enviroment to meet a different set of priorities. A MUST pre-ordains a particular set of priorities (in this case an improved robustness for all at the cost of resolution time), which seem to be to be somewhat presumptive. When we have a situation that negatively impacts a small proportion of use cases, then it is reasonable to impose some time / performance penalty on _all_ use cases by making mandatory (MUST) changes to the protocol to address such corner cases? (No, I don't have a simple answer to this question, either in this specific case of the more general situation, but it seems that this question is at the core of what we are talking about here.) Geoff _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
