Subject: RFC 2782: "Unless and until permitted by future standards"

From: Stuart Cheshire <[email-masked]>
Date: Fri, 15 Jun 2001 18:49:28 -0700

>   Unless and until permitted by future standards
>   action, name compression is not to be used...

Are we at that point yet? How many name servers still don't understand 
SRV?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Jun 2001 14:16:52 -0000

> Are we at that point yet? How many name servers still don't understand 

My widely deployed DNS cache has no special SRV-handling code. The
required DNS standards do not require special SRV-handling code.

The BIND company has recently issued a draft that, among other things,
demands that I add SRV-decompression code. All my users are supposed to
change their software so that you can save a few bytes in SRV records?

I strongly object to the ludicrous notion that every DNS cache should be
upgraded for every new DNS record type that contains a domain name.

---Dan

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 22 Jun 2001 11:47:29 -0700 (PDT)

D. J. Bernstein writes:
> demands that I add SRV-decompression code.

If you are referring to draft-ietf-dnsext-unknown-rrs-00, this is not
true.  That draft merely *recommends* that you add such code, so that
your implementation will interoperate with broken servers that are
known to exist in the field.  The "SHOULD" in the draft does allow you
to omit the code after "carefully weighing" its implications, which
I'm sure you have done.

With regards to draft-ietf-dnsext-rfc2782bis-00, I think the "unless
and until" wording is unfortunate.  I can see it being interpreted in
two significantly different ways:

 a) Future standards action may introduce a negotiation mechanism
    whereby a client can specifically request that a server send it 
    SRV records in compressed form

or

 b) Future standards action may allow servers to compress 
    SRV records in responses by default, without prior negotiation

I suspect interpretation a) is the intended one, written with the
now-dead EDNS1 protocol in mind as a possible negotiation mechanism.
Under this interpretation, the wording is harmless, but it is also
unnecessary as such a negotiation mechanism can be introduced (if
deemed to be a good idea) without specifically allowing for it
in the specification of each RR type.

Under interpretation b) it would be unsafe for any DNS implementation
to treat SRV records transparently, since compressed names could
appear in them at any time after the implementation has been deployed
due to "future standards action".  This would effectively burden every
implementation with having to specifically support SRV decompression,
without deriving any benefit from this added effort.  It would also
directly contradict draft-ietf-dnsext-unknown-rrs-00.

Therefore, I propose removing the text "Unless and until permitted by
future standards action", leaving just the unambiguous "Name
compression is not to be used for this field.".

> upgraded for every new DNS record type that contains a domain name.

I agree completely.
-- 
Andreas Gustafsson, [email-masked]