Original text:
The DNS uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone. <del> Servers are expected to return 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. </del>  1. The Domain Name System (DNS) RFC1034, RFC1035 uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone.  Glue records are added to the <del> parent zone as part of the delegation process.  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 clarifies that expectation. </del>  1.1. 2. <del> Replace </del>  <del> "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  Go to step 4." </del>  <del> with "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  If all glue RRs do not fit, set TC=1 in the header.  Go to step 4." 3. </del>  While not common, real life examples of servers that fail to set TC=1 <del> when glue records are available exist and they do cause resolution </del>  failures. <del> 3.1. </del> The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC writing, this configuration has been corrected and the response correctly sets the TC=1 flag. <del> DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del>  <del> 3.2. </del>  <del> Sibling glue are glue records that are not contained in the delegating zone itself, but in another delegated zone.  In many cases, these are not strictly required for resolution, since the </del>  resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling <del> zone.  However, most nameserver implementations provide them as an optimization to obviate the need for extra traffic. </del>  <del> Question: if sibling glue from the same delegating zone does not fit into the response, should we also recommend or require that TC=1 be set? </del>  <del> 3.3. </del>  <del> Here is a more complex example of sibling glue that lives in another zone, but is required to resolve a circular dependency in the zone configuration. </del>  <del> 3.4. </del>  When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones <del> depending on this glue are not broken.  Technically, these NS records are no longer glue records, but authoritative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </del>  <del> 4. </del>  This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. <del> 5. </del>  There are no actions for IANA.

Reviewer comments:
Misc updates .. Rework Sibling Glue section, and clarify that they MUST be included, and also subject to TC=1 if they don't fit. Remove the cross parent zone cyclic dependency example, which doesn't work (I think we agreed to that, but I can be persuaded to add it back, if we want to point out a misconfiguration as a warning). Move the paragraph about non-optionality of types of additional section data into the tail end of the Intro. It deserves to be more prominently mentioned than buried at the end of the example of missing glue. Addressed Duane's comment that the "Why is Glue Required?" section did not actually say why, but instead just gave examples. Instead, I added a one phrase explaining why to the Intro section that defines glue records. I don't think it requires a separate section. Removed Duane's comment about "I think the document should say that some servers might experience an increase in TCP if implementations require all glue or set TC=1. If not in this section then somewhere else._". I agree we should address this, so I've made an "issue" for it. And we can add the relevant text in the next update, once we figure out where it goes (an "Operational Considerations" section perhaps?).
NAME - added your tweaks. Please review/approve!

Revised text:
The DNS uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone.  <ins> 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. </ins> 1. The Domain Name System (DNS) RFC1034, RFC1035 uses glue records to allow iterative clients to find the addresses of nameservers that are contained within a delegated zone.  Glue records are added to the  <ins> 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 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 (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. DNS responses sometimes contain optional data in the additional section.  Glue records however are not optional.  Several other protocol extensions, when used, are also not optional.  This includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </ins> 1.1. 2.  <ins> The following is a simple example of glue records present in the delegating zone "test" for the child zone "foo.test".  The nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both below the delegation point.  They are configured as glue records in the "test" zone: </ins>  <ins> Referral responses from "test" for "foo.test" must include the glue records in the additional section (and set TC=1 if they do not fit): </ins>  <ins> 2.1. </ins> While not common, real life examples of servers that fail to set TC=1  <ins> when glue records are available, exist and they do cause resolution </ins> failures.  The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC writing, this configuration has been corrected and the response correctly sets the TC=1 flag.  <ins> 3. Replace "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  Go to step 4." with </ins>  <ins> "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  If all glue RRs do not fit, set TC=1 in the header.  Go to step 4." </ins>  <ins> 4. Sibling glue are glue records that are not contained in the delegated zone itself, but in another delegated zone from the same parent.  In many cases, these are not strictly required for resolution, since the </ins> resolver can make follow-on queries to the same zone to resolve the nameserver addresses after following the referral to the sibling  <ins> zone.  However, most nameserver implementations today provide them as an optimization to obviate the need for extra traffic from iterative resolvers. This document clarifies that sibling glue (being part of all available glue records) MUST be returned in referral responses, and that the requirement to set TC=1 applies to sibling glue that cannot fit in the response too. </ins>  <ins> 4.1. </ins>  <ins> Here the delegating zone "test" contains 2 sub-delegations for the subzones "bar.test" and "foo.test". </ins>  <ins> Referral responses from "test" for "foo.test" must include the sibling glue (and set TC=1 if they do not fit): </ins>  <ins> 5. </ins> When a zone is deleted but the parent notices that its NS glue records are required for other zones, it MAY opt to take these (now orphaned) glue records into its own zone to ensure that other zones  <ins> depending on this glue are not broken.  Technically, these address records are no longer glue records, but authoritative data of the parent zone, and should be added to the DNS response similarly to regular glue records. </ins>  <ins> 6. </ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations.  <ins> 7. </ins> There are no actions for IANA.