On 12/3/2019 5:21 PM, Ralf Weber wrote:
Moin!
On 3 Dec 2019, at 3:15, Michael StJohns wrote:
From 2181:
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its
entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room.
I finally got a chance to go back and do some reading and found the
above.
The way I read this is that setting the bit simply because you
couldn't include diagnostic info is a no-no. Let's not do it.
I disagree. The EDNS0 OPT RRSet is needed and thus if can not be
fitted entirely a TC bit has to be set. Also 2181 was before EDNS0 so
IMHO it doesn’t apply here anyway. EDE is all is new stuff we have to
decide over what do with it now and not some ancient RFC. And a lot of
people (including me) have said that they, because of the rare cases
this appears, see TC as the right solution as it is simple and
backwards compatible. EDE already is complex we should not increase it
complexity for a rare corner case.
*bleah*
In the querying EDNS0 set a bit (EDERequested) that says "Consider EDE
as 'important' in the response - return TC if there is an overflow and
EDE is omitted". Maybe set a second bit (EDERequired) that says "EDE
is more important than any other data - return it at the head of the
response and drop something else in preference."
Responder:
If EDERequested or EDERequired is set, and overflow occurs because of
the EDE, set the TC bit on the response.
If EDERequired is set, return the EDE EDNS0 option in preference to any
other data - you may still end up setting the TC bit if other info is
omitted.
The first bit says that the client understands EDE and that it considers
it is as important as any other data and should not be omitted without
setting the TC bit.
Clients that don't understand EDE (e.g. most of them right now) that
would ignore EDE anyways don't need to re-query for data that they don't
understand.
Clients that do understand EDE leave both bits unset if they really
don't care about the reasons why (e.g. the typical end user), can set
the first bit if they do (typical resolver) and can set both bits for
debugging (the geeks in the DNSOP group).
In the case of truncation due to EDE, omit the EDE option from the
response EDNS0 RR. If you're still overflowing, set the TC. (E.g. this
isn't about omitting the EDNS0 in the response, only about removing
bloat when the client hasn't indicated the bloat is useful.
Later, Mike
So long
-Ralf
—--
Ralf Weber
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
