Draft: draft-ietf-dnsop-glue-is-not-optional

Commentary: and talk more generically about message size constraints regardless of transport . For 
 As currently written the document only talks about setting TC=1 over UDP . This sort of implies that UDP is the only possible transport where  flag has meaning . We do n't talk about setting  over TCP because the assumption is that TCP always has enough room for all glue or whatever . But this does n't account for two possibilities 1 ) a future transport that is limited in space 2 ) some kind of ridiculous zone configuration with so many NS and glue records that they wo n't even fit in a single DNS - over - TCP message . Would it be better to just say " set TC=1 if glue does n't fit " and not bring UDP or TCP into the requirements language ? 
 I like the idea of that , but I think simultaneous possession and ingestion of cake is also possible -- make the general , transport - agnostic point but also give the UDP / TCP fallback as an example that is known to be common at the time of writing .  
 I prefer mentioning UDP and TCP and to say clearly never set it for TCP . I would n't consider " insanely weird " TCP that requires TC=1 
 would or would n't ? 
 was merged so closing this for now
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 over UDP transport, 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 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.
The Domain Name System (DNS) RFC1034, RFC1035 uses referral glue
records to allow iterative clients to find the addresses of
nameservers that are contained within a delegated zone.  Referral
glue records are added to the parent zone as part of the delegation
process and returned in referral responses, otherwise a resolver
following the referral has no way of finding these addresses.
Authoritative servers are expected to return all available in-domain
referral glue records in a referral response.  If message size
constraints prevent the inclusion of all in-domain glue records over
UDP transport, the server MUST set the TC (Truncated) flag to inform
the client that the response is incomplete, and that the client
SHOULD use TCP to retrieve the full response.  This document
clarifies that expectation.
The Domain Name System (DNS) RFC1034, RFC1035 uses referral glue
records to allow iterative clients to find the addresses of
nameservers that are contained within a delegated zone.  Referral
glue records are added to the parent zone as part of the delegation
process and returned in referral responses, otherwise a resolver
following the referral has no way of finding these addresses.
Authoritative servers are expected to return all available in-domain
referral glue records in a referral response.  If message size
constraints prevent the inclusion of all in-domain glue records over
the chosen transport, 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 retrieve the full response.  This
document clarifies that expectation.
An example of missing glue is included here, even though it is not
really a type of glue.  While not common, real examples of responses
that lack required glue, and with TC=0, have been shown to occur and
cause resolution failures.
An example of missing glue is included here, even though it can not
be considered as a type of glue.  While not common, real examples of
responses that lack required glue, and with TC=0, have been shown to
occur and cause resolution failures.
This document clarifies that when a name server generates a referral
response over UDP transport, it MUST include all available in-domain
glue records in the additional section, or MUST set TC=1.  When a
name server generates a referral response over TCP transport, it MUST
include all available in-domain glue records.
This document clarifies that when a name server generates a referral
response, it SHOULD include all available glue records in the
additional section.  If after adding all in-domain glue records, not
all sibling glue records fit in a response over UDP transport, the
name server is NOT REQUIRED to set TC=1.
This document clarifies that when a name server generates a referral
response, it MUST include all available in-domain glue records in the
additional section, or MUST set TC=1 if constrained by message size.
At the time of writing, most iterative clients send initial queries
over UDP and retry over TCP upon receiving a response with the TC
flag set.  UDP responses are generally limited to between 1232 and
4096 bytes, due to values commonly used for the EDNS0 UDP Message
Size field RFC6891, FLAGDAY2020.  TCP responses are limited to 65,536
bytes.
This document clarifies that when a name server generates a referral
response, it SHOULD include all available glue records in the
additional section.  If after adding all in-domain glue records, not
all sibling glue records fit due to message size constraints, the
name server is NOT REQUIRED to set TC=1.