Subject: [dnsext] Protocol standards and implementations vs. configurations

From: Matthew Dempsky <[email-masked]>
Date: Wed, 23 Sep 2009 12:00:55 -0700

On Wed, Sep 23, 2009 at 6:59 AM, Tony Finch <[email-masked]> wrote:
> That's an exception for a particular operational environment. RFC
> requirements are about implementations. When they say an implementation
> MUST implement something, that doesn't mean an operator can't turn it off.

A few people have expressed this viewpoint, and I'd like to know if
this is truly the view of this working group on what an IETF standard
means. E.g., if RFC 1123 (or whichever) was to be updated to say "DNS
servers MUST respond to queries sent over TCP", would it still be
acceptable for a production DNS server to not respond to queries over
TCP as long as the software allowed the operator to "turn it back on"?

When I read an RFC, I interpret it as how I can expect other software
to behave when deployed, not as how that software could theoretically
behave if the operator configured it a particular way.  As an
implementor, the former is much more useful than the latter in
ensuring interoperability.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 23 Sep 2009 15:27:31 -0400

>TCP as long as the software allowed the operator to "turn it back on"?

Matthew,
This is an excellent question,

Tony's opinion is close to my personal one.
Standards track RFC specify what needs to be implemented.
BCP's and Informational RFC's by groups in the OPS area suggest
what are acceptable practices.

Based on this a DNS authorative server that distributed without
TCP support can not claim to be RFC compliant (IMHO).
If a DNS resolver that supports TCP is configured by an administrator
to not use TCP/53 then that operator is only hurting
him/her-self and his/her customers. (I assume the operator has
done his/her homework and determined this is safe to do. )

Shipping a non TCP supporting DNS software may hurt users that pick up
the product and install it without thinking about the implications.

>ensuring interoperability.

The way people can figure out how to mis-use tools has never stopped 
amazing me :-)
but the largest group is going to use for the standard default configuration.

         Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Sep 2009 16:33:24 -0400

> TCP as long as the software allowed the operator to "turn it back on"?

Please see Olafur's post from the Chairs from earlier.  It is of
course possible to have items that are mandatory to implement that
might still not be used in particular environments.  Rather than
continuing to debate hypothetical changes to the text, I think it'd be
really great if participants waited until the promised draft shows up,
and then offered specific changes to that text.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.