Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

[Warren Kumari <[e-mail]>]

On Wed, Jan 31, 2024 at 8:57 PM, Paul Hoffman <[e-mail]>
wrote:

> On Jan 31, 2024, at 17:39, Paul Wouters <[e-mail]> wrote:
>
> On Wed, 31 Jan 2024, Paul Hoffman wrote:
>
> On Jan 31, 2024, at 15:15, Paul Wouters <[e-mail]> wrote:
>
> Can they write a draft with why they are going against the RFC?
>
> Yes, that is possible. However, I think it would be unfair to the DNS
> community to hold up draft-ietf-dnsop-rfc8109bis waiting for that to
> happen, and it would be a bad policy to make draft-ietf-dnsop-rfc8109bis
> less honest about the current and possible future waiting for that to
> happen.
>
> As Mark just clarified. This isn't glue, so perhaps the text just needs
> updating.
>
> The current text is:
>
> <t>If some root server addresses are omitted from the Additional section,
> there is no expectation that the TC bit in the response will be set to 1.
> At the time that this document is written, many of the root servers are not
> setting the TC bit when omitting addresses from the Additional section.</t>
>
> <t>Note that <xref target="RFC9471"/> updates <xref target="RFC1035"/>
> with respect to the use of the TC bit. It says "If message size constraints
> prevent the inclusion of all glue records for in-domain name servers, 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 to
> retrieve the full response."</t>
>
> Maybe we should add to the second paragraph:
>
> Note, however, the root server addresses are not glue records, so setting
> the TC bit in truncated responses from the root servers is not required by
> RFC 9471.
>
> Does this solve your and Warren's issues?
>


Oh. Erm… yes!
That's a short, simple and elegant solution, and works for me…. I was
expecting this to require much more text changes, but this works. Nice!



> It raises another question why some root servers do set the TC bit though.
>
> If I read 1035 correctly, it specified the TC bit for all truncation, not
> just for truncated glue records.
>

Yup. RFC9471 updates RFC1034 to say:
"NEW:

   |  Copy the NS RRs for the subzone into the authority section of the
   |  reply.  Put whatever NS 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
   |  for in-domain name servers do not fit, set TC=1 in the header.  Go
   |  to step 4.
"
This says that all glue has to fit before setting TC.

I personally still think of "TrunCation" as meaning what the English word
means:

   1. shorten the duration or extent of.
   2. shorten by cutting off the top or end.
   3. (botany) (of a leaf, feather, or other part) ending abruptly as if
   cut off across the base or tip.

Or as it said in 1035:
"TC              TrunCation - specifies that this message was truncated
                due to length greater than that permitted on the
                transmission channel."

… but I understand that I can be in the rough….

Whatever the case, it seems like there is some confusion / lack of
agreement on what all RFC9471 means…

W


> --Paul Hoffman
>