I like this idea, and am aware of at least two other proposals that
would (or would have) benefited from a new OPT record [EDNS header flag
bit] to communicate "incomplete response" as distinct from "truncated
response" (the latter encouraging retry over a transport supporting
larger messages, the former merely indicating that other data _could_
have appeared without encouraging a retry).
* for refuse-any, indicating the existence of records not included in
a response to a QTYPE=ANY query:
https://mailarchive.ietf.org/arch/msg/dnsop/dfYqw2nUQqlcC2V6y34xKCtSE8Y
* for multiple-responses, indicating the existence of records that the
server could have included with better authentication or a different
transport:
https://mailarchive.ietf.org/arch/msg/dnsop/TmAWzUWUiHI2k1LXmx7rTzQD9lc
[EDNS header flag bit]:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13
On 11/13/19 18:05, Viktor Dukhovni wrote:
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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
