Skip to main content

DNS Glue Requirements in Referral Responses
draft-ietf-dnsop-glue-is-not-optional-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-glue-is-not-optional@ietf.org, rfc-editor@rfc-editor.org, swoolf@pir.org, warren@kumari.net
Subject: Protocol Action: 'DNS Glue Requirements in Referral Responses' to Proposed Standard (draft-ietf-dnsop-glue-is-not-optional-09.txt)

The IESG has approved the following document:
- 'DNS Glue Requirements in Referral Responses'
  (draft-ietf-dnsop-glue-is-not-optional-09.txt) as Proposed Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/


Ballot Text

Technical Summary

   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 glue
   records for in-domain name servers in a referral response.  If
   message size constraints prevent the inclusion of all glue records
   for in-domain name servers, 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.

Working Group Summary

This document has been around for some time and has benefited from discussion
among multiple DNS protocol implementers. This doesn't represent a large number
of people but it does represent a major portion of those who will have to
implement and maintain the behavior described.

The most difficult point was differences in usage of some specific terminology
("bailiwick"). This was handled by eliminating use of the term here and adding
it to draft-ietf-dnsop-8499bis, which notes that the term is confusing and
should be considered historic. 

Document Quality

This document has only very limited applicability to new implementations; it's
a clarification of a much older specification (RFC 1034). Implementers took
part in discussion of the draft and will be able to update their software where
it differs from the standard as clarified here.


Personnel

   Suzanne Woolf is DS.
   Warren "Ace" Kumari is RAD!!!!

RFC Editor Note