> On Nov 13, 2019, at 5:50 PM, Wes Hardaker <wjh...@hardakers.net> wrote:
>
>>> I added this text to the next version:
>>>
>>> <t>When the response grows beyond the requestor's UDP payload
>>> size <xref target="RFC6891" />, servers SHOULD truncate messages
>>> by dropping EDE options before dropping other data from
>>> packets. Implementations SHOULD set the truncation bit when
>>> dropping EDE options.</t>
>>
>> Are you sure that setting TC=1 when EDE doesn't fit is the right
>> trade-off? I'm somewhat skeptical...
>
> Well, that's what the other specs say. We could break from that, you're
> right, and it's a discussion I was going to mention in Singapore for
> that matter.
A colleague suggested that would could use another bit (from the EDNS
flags field, say bit 14 adjacent to DO) to signal that non-essential
diagnostic information was left out. Resolvers can then choose to
retry over TCP only if they deem it important to retrieve and use
EDE information.
It'd be a shame (though admittedly not frequent) to have a resolver
retry over TCP just to get the same answer with additional information
it does not need and perhaps does not even understand.
Of course this only matters in the rare (when not specifically elicited
by carefully crafted queries) case that it is the EDE options that push
the packet over the UDP size limit, and the rest of the payload would
otherwise just fit. Perhaps on that basis the extra bit is not warranted.
We could just say that EDE can be silently dropped, or could leave the
text as proposed, with EDE occasionally eliciting "avoidable" TCP retries.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
