Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Mark Andrews <[e-mail]>]

> On 29 Jul 2021, at 09:58, Geoff Huston <[e-mail]> wrote:
> 
> Hi Paul,
> 
>> On 29 Jul 2021, at 2:10 am, Paul Wouters <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]