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. -- 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
