Dear DNSOP,

Changes to this draft from the previous version are as follows:
 
   *  Clarified scope to focus only on name server responses, and not
      zone/registry data.
   *  Reorganized with section 2 as Types of Glue and section 3 as
      Requirements.
   *  Removed any discussion of promoted / orphan glue.
   *  Use appropriate documentation addresses and domain names.
   *  Added Sibling Cyclic Glue example.

I'd say we still do not have consensus on treatment of sibling glue.  Section 
3.2 currently has the strict requirements with optional more lenient 
requirements in [square brackets]:

3.2.  Sibling Glue

   This document clarifies that when a name server generates a referral
   response, it MUST [SHOULD] include available sibling glue records in
   the additional section.  If all sibling glue records do not fit in a
   UDP response, the name server MUST [is NOT REQUIRED to] set TC=1.


DW


> On Oct 11, 2021, at 4:30 PM, [email protected] wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> 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           : Glue In DNS Referral Responses Is Not Optional
>        Authors         : M. Andrews
>                          Shumon Huque
>                          Paul Wouters
>                          Duane Wessels
>       Filename        : draft-ietf-dnsop-glue-is-not-optional-03.txt
>       Pages           : 9
>       Date            : 2021-10-11
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of nameservers that are contained within a delegated zone.
>   Authoritative Servers are expected to return all available glue
>   records in referrals.  If message size constraints prevent the
>   inclusion of all glue records in a UDP response, the server MUST set
>   the TC flag to inform the client that the response is incomplete, and
>   that the client SHOULD use TCP to retrieve the full response.  This
>   document updates RFC 1034 to clarify correct server behavior.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-03.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-03
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to