There are three noteworthy changes from the previous version of this draft:
1. We no longer use the term “referral glue”. 2. Instead of introducing new (and likely confusing) terms such as “sibling glue” and “in-domain glue” we now refer to these as “glue for sibling domain name servers” and “glue for in-domain name servers”. 3. Expanded the introduction paragraph that talks about not placing requirements on data in zones or registries (as suggested by Ralf). DW > On Apr 22, 2022, at 1:27 PM, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : DNS Glue Requirements in Referral Responses > Authors : M. Andrews > Shumon Huque > Paul Wouters > Duane Wessels > Filename : draft-ietf-dnsop-glue-is-not-optional-05.txt > Pages : 12 > Date : 2022-04-22 > > Abstract: > The DNS uses glue records to allow iterative clients to find the > addresses of name servers that are contained within a delegated zone. > Authoritative Servers are expected to return all available in-domain > glue records in a referral response. If message size constraints > prevent the inclusion of all in-domain glue records, the server MUST > set the TC flag to inform the client that the response is incomplete, > and that the client SHOULD use another transport to retrieve the full > response. This document updates RFC 1034 to clarify correct server > behavior. > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
