nominalism of standards

[Havard Eidnes]

> Paul Vixie wrote:
>>> ...
>>
>> i'll go further: i think that's a good clarification of and alteration
>> to the standards. i just don't think it's wise to expect a tcp-only
>> initiator, or a tcp-only responder, to function reliably. (ever.) so the
>> standard is nominal, and should guide other standards, but in this case
>> may give unusable guidance to implementers and operators.
>
> let me put that differently and perhaps more understandably:
>
> <<That having been said, a stronger document set written today would not
> be able to put all of the DNS genies back into their bottles. Too many
> implementations have guessed differently when presented with a loose
> specification, and interoperability today is a moving, organic target.
> When I periodically itch to rewrite the specification from scratch, I
> know there are too many things that must be said that also cannot be
> said. It’s as though, in a discussion of the meaning of some bit
> pattern, a modern description of the protocol—written with full
> perspective on all that has been done in the DNS field—would have to
> say, “It could mean x but some implementations will think it means y so
> you must be cautious.”>>
>
> http://queue.acm.org/detail.cfm?id=1242499

I think I agree, it's just that I think there's a difference between
"what is nominally adhering to the specifications as written" and
"what is good operational advice", and I perceived the statement which
started this to say something about the former ("DNS servers aren't
required to support TCP.").

If someone were to set up a new authoritative name server and asked me
if DNS over TCP is required to be supported also for non-AXFR queries,
I would without hesitation say "yes", and point to RFC7766 (thanks,
David, for finding the additional quote I was looking for, but could
not find off-hand).  Its predecessor, RFC5966, said essentially the
same wrt. this requirement, and that document is now 7 years old, so
it would not be entirely unreasonable to expect implementors who
continue to maintain their products to have taken notice (although
that is perhaps ... somewhat optimistic if we're instead talking about
"all" implementors of "things which operate or ... interfere with
DNS").

However, as Paul says, expecting a recursive resolver which only does
TCP today to get a sufficiently good lookup success rate would be too
optimistic (of course depending on your target and environment).
However, that's not because the current collection of specs covering
DNS say that TCP/DNS is optional, it's because for a long time many
have (perhaps mistakenly) thought that TCP/DNS is only (or "would ever
be") needed for AXFR towards slave name servers.

In short, there's a difference between scripture and practice.

Regards,

- Håvard