On Wed, Jan 31, 2024 at 8:57 PM, Paul Hoffman <paul.hoff...@icann.org>
wrote:
> On Jan 31, 2024, at 17:39, Paul Wouters <p...@nohats.ca> wrote:
>
> On Wed, 31 Jan 2024, Paul Hoffman wrote:
>
> On Jan 31, 2024, at 15:15, Paul Wouters <p...@nohats.ca> 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
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
