> On 7 Feb 2024, at 09:57, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > > > 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
RFC 1034 really doesn’t handle "priming queries" well. ‘dig ns . @$rootserver’, in the general case, will not return address records for the servers as they are not part of the data above the bottom of zone cuts. This has always been the case even when the server where known by their original names as they where in delegated name spaces. It just happened to work because the implementations where buggy and leaked GLUE or just obscured addresses into ANSWERS rather than only returning GLUE in DELEGATIONS as is specified. This leaking has been cleanup in most implementations. The current work around to get addresses in the additional section, with the Internet's root servers, is to also server root-servers.net but that doesn’t ensure that all the addresses are returned and doesn’t result in TC=1 being set. Applying the same work around to the pre root-servers.net root zone would have required the root servers serving 13(?) other zones to get the address records. Now I think we want the priming response to indicate when the additional section couldn’t fit the address records in (i.e. set TC=1). It may also be useful for the general NS query case. I also think that we need a mechanism other than serving additional zones to supply the address records (e.g. add addresses records to the root zone for the root and have the root servers retrieve them). Both of these things require protocol CHANGES. Setting TC=1 shouldn’t cause problems for resolvers as they should all be expecting it for any query they make. The root NS RRset could be bigger than 500 bytes and the resolvers should handle that. There may be some broken ones that don’t. Mark > -- > 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 -- 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
