Original text:
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 <del> 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. </del>  1. 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 <del> 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. </del>  DNS responses sometimes contain optional data in the additional section.  In-domain referral glue records, however, are not optional. 2.4. <del> 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. </del>  The example below is based on a response observed in June 2020.  The names have been altered to fall under documentation domains.  It 3.1. This document clarifies that when a name server generates a referral <del> 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. </del>  3.2. 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 <del> all sibling glue records fit in a response over UDP transport, the </del>  name server is NOT REQUIRED to set TC=1. Note that users may experience resolution failures for domains with

Reviewer comments:
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 TC flag has meaning. We don't talk about setting TC over TCP because the assumption is that TCP always has enough room for all glue or whatever. But this doesn'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 won't even fit in a single DNS-over-TCP message. Would it be better to just say "set TC=1 if glue doesn'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. Joe
I prefer mentioning UDP and TCP and to say clearly never set it for TCP. I wouldn't consider "insanely weird" TCP that requires TC=1
would or wouldn't?
was merged so closing this for now

Revised text:
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  <ins> 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. </ins> 1. 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  <ins> 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. </ins> DNS responses sometimes contain optional data in the additional section.  In-domain referral glue records, however, are not optional. 2.4.  <ins> 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. </ins> The example below is based on a response observed in June 2020.  The names have been altered to fall under documentation domains.  It 3.1. This document clarifies that when a name server generates a referral  <ins> 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. </ins> 3.2. 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  <ins> all sibling glue records fit due to message size constraints, the </ins> name server is NOT REQUIRED to set TC=1. Note that users may experience resolution failures for domains with