Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

[Richard Gibson <[e-mail]>]

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.