Hello DNSOP,

Here is a short summary of the changes between -03 and -04 of this draft:

We use "referral glue" on the assumption that other types of glue may be 
defined in the future. Not all authors necessarily like this change but we are 
trying it on for size.

Added an Operational Considerations section.

Noted that many current implementations set TC=1 only when no glue RRs fit. New 
requirements may lead to more truncation and TCP.

Sibling glue can be optional (hence a title change). Only require TC=1 when all 
in-domain glue RRs don't fit.

Avoid talking about requirements for UDP/TCP specifically, and talk more 
generically about message size constraints regardless of transport. However, we 
added a paragraph describing the current behavior of most iterative clients to 
start with UDP and fall back to TCP when truncated.

DW


> On Feb 8, 2022, at 2:33 PM, internet-dra...@ietf.org 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           : DNS Referral Glue Requirements
>        Authors         : M. Andrews
>                          Shumon Huque
>                          Paul Wouters
>                          Duane Wessels
>       Filename        : draft-ietf-dnsop-glue-is-not-optional-04.txt
>       Pages           : 10
>       Date            : 2022-02-08
> 
> Abstract:
>   The DNS uses referral 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
>   referral glue records in a referral response.  If message size
>   constraints prevent the inclusion of all in-domain referral 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

Reply via email to