> 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. > > And there is of course the ever-present issues with the resolver’s treatment > of non-in-bailiwick > glue records. > > > Geoff > > > > > > > > >> >>> Section 5 deviates away from protocol requirements into registry practice >>> and >>> the deviation appears to be at best a somewhat random thought! >>> >>> It makes no sense to me to even include sections 4 or 5 in this document. >> >> I guess what the document is trying to say is "this glue that is not >> optional also applies to records that are technically not glue because >> it is authoritative data". We really only want to mention that these >> should still be added and TC=1 should still be set if it does not fit. >> >> Paul >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
