Re: [DNSOP] On some terminology in draft-ietf-dnsop-respsize (truncation)

[Joe Abley <[e-mail]>]

On 3 Mar 2014, at 18:46, Paul Vixie <[e-mail]> wrote:

> i know of code that's in widespread use which assumes that TC=1 means that the last non-empty section was damaged but that it is safe to cache anything found in earlier sections. this code is clearly wrong-headed, but as i said, is in wide-spread use.
> 

> a protocol clarification (not a change, which dnsop can't by charter make) might be that a sender should send empty response, authority, and additional sections when setting TC=1, and that a receiver must act as if the response, authority, and additional sections are empty if it sees TC=1.

I'm aware of a SIP ATA apparently in semi-widespread use amongst customers of a large independent ISP in Canada which (a) doesn't support TCP transport, (b) doesn't support EDNS(0), and (c) issues an IN/SRV query to bootstrap, the response to which is large and reliably features TC=1.

The ISP in question switched from BIND9 to Unbound in their resolver clusters, and the helpdesk phone started to ring.

BIND9 would return a truncated but non-empty response, which would be good enough for the ATA to work (from the user's perspective). Unbound would send empty ANSWER, AUTHORITY and ADDITIONAL sections, which left the ATA stranded and caused much end-user ire.

Clearly the ATA in question is quite broken (or, the service's SRV RRSet was unreasonably large considering the client limitations). Surely this is not the only broken situation of this type on the Internet, however.

The fact that the change from BIND9 to Unbound behaviour has been observed to result in a non-zero support cost is pertinent, I think, when imagining clarifications to the specification.


Joe