On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews <ma...@isc.org> wrote:
> There is nothing to prevent us saying that responses to priming queries > SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in > the response or that the root server address should be looked up as if they > are glue in the root zone. The rules in RFC 1034 don’t handle priming > queries well in a number of ways. > > 1) all the addresses should be returned or TC should be set. > 2) the address of the root servers should be looked up as glue in the root > zone if not found elsewhere > 3) the addresses of the root servers should be included as glue in the > root zone if not otherwise there. > > I just (finally) gave this a second look/thought. I think Mark A's assertion/summary isn't quite 100% correct, based on the following particular details: - The concept of a DNS zone (from classic 103[345] RFCs) is a contiguous portion of the DNS tree. - The root server names are underneath 'root-servers.net'. - There is a delegation to 'net' from the root zone. - The servers themselves (as identified by their IP addresses) are authoritative for both '.' (root zone) and 'root-servers.net' - Thus, it is NOT the case that responses from the "root servers" to queries don't require the TC bit to be set if the entire set of authoritative A/AAAA records does not fit in the Additional section. - A careful parsing/analysis would suggest instead, that the A/AAAA records are in fact in-bailiwick (or whatever we call it these days) from the ' root-servers.net' zone. - As such, if the entire set of A/AAAA records does not fit, there are two alternative approaches: - Set TC - Add a referral to the 'net' zone with its glue (not 100% sure this is correct, but that's what I think would need to happen to satisfy resolvability of the NS names to A/AAAA addresses). Apologies if my analysis is wrong or the terminology is wrong or the suggested referral is incorrect... Brian > -- > Mark Andrews > > > On 2 Feb 2024, at 06:15, Wessels, Duane <dwessels= > 40verisign....@dmarc.ietf.org> wrote: > > > > > > > >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman <paul.hoff...@icann.org> > wrote: > >>> > >>> As Mark just clarified. This isn't glue, so perhaps the text just needs > >>> updating. > >> > >> The current text is: > >> > >> <t>If some root server addresses are omitted from the Additional > section, there is no expectation that the TC bit in the > >> response will be set to 1. At the time that this document is written, > many of the > >> root servers are not setting the TC bit when omitting addresses from > the Additional section.</t> > >> > >> <t>Note that <xref target="RFC9471"/> updates <xref target="RFC1035"/> > with respect to the use of the TC bit. > >> It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, > >> the server must set the TC (Truncated) flag to inform the client that > the response is incomplete > >> and that the client should use another transport to retrieve the full > response."</t> > >> > >> Maybe we should add to the second paragraph: > >> > >> Note, however, the root server addresses are not glue records, so > setting the TC bit in truncated responses from > >> the root servers is not required by RFC 9471. > >> > >> Does this solve your and Warren's issues? > > > > > > I have to confess that “root server addresses are not glue records” is a > very subtle point that was lost on me, and > > maybe lost on a lot of us, as evidenced by this discussion. > > > > I’m not particularly comfortable with the terseness of the statement > above. The terminology RFC doesn’t really help here because it doesn’t > provide a definition of what glue is glue or what is not glue. It just > references semi-conflicting statements in other RFCs. > > > > So I think if 8109bis is going to make the statement that root server > addresses are not glue, it deserves more explanation of why that is the > case. > > > > I also worry that it creates a new problem, which is what sort of > truncation policy applies to a priming response? If RFC 9471 does not > apply, does RFC 2181 Section 9 apply? Is a priming response with zero root > server IP addresses acceptable? > > > > DW > > > > > > _______________________________________________ > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
