Subject: AD+CD interoperability problems

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2000 22:46:07 -0000

Queries with AD or CD violate RFC 1035. My DNS cache discards them as
bogus. My DNS servers refuse them as bogus.

I've now encountered a serious interoperability problem, which DNSEXT
should document: the Ultrix version of BIND sends queries with AD+CD
set. I'm going to have to accept these queries; should I echo AD+CD in
the responses? Have any other bogus query bits been spotted?

I also see that there is a serious potential interoperability problem,
if DNSSEC is ever deployed: the DNSSEC documents allow clients and
caches to send queries with CD set. These queries violate RFC 1035; what
happens if they're rejected or discarded as bogus?

Evidently the DNSSEC designers assumed, incorrectly, that all other
caches and servers would respond to CD in a particular way. This DNSSEC
assumption constitutes a change in the base DNS protocol, and it needs
to be documented as such.

This is exactly the type of careless protocol extension that I
specifically asked about last month. To repeat the question, for
everyone working on DNS extensions: Exactly what assumptions are you
making on the behavior of non-extended servers?

---Dan

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

---

From: [email-masked]
Date: Tue, 22 Feb 2000 15:19:31 +1100

> bogus. My DNS servers refuse them as bogus.

	RFC 1035 states these are reserved for future use.  If you
	are a RFC 1035 client these bits must be zero when you send
	the query.  If you are a RFC 1035 server these bits must
	be zero when you send the response.

	That is about all RFC 1035 says about those bits.

	Unfortunately RFC 1035 does not say that if you are a
	RFC1035 server you should ignore those bits in queries
	received.  Then again it doesn't say you should test them
	either.  It does say that they may be set (reserved for future
	use).

	The only assumption made for DNSSEC was that RFC1035 servers
	and clients would ignore these bits in queries and answers
	respectively.  This is a valid assumption given the clients
	and servers at the time.  It is also a valid assumption that
	future implementers would make themselves aware of protocol
	extentions that have been published.

> the responses? Have any other bogus query bits been spotted?

	If you are a RFC 1035 server those bits are zero in your
	response.

> happens if they're rejected or discarded as bogus?

	They don't violate RFC 1035 as they are reserved for future use.
	A client should expect that they may be set in a response.

> making on the behavior of non-extended servers?

	Mark
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 22 Feb 2000 11:36:20 -0500

From:  "D. J. Bernstein" <[email-masked]>
Date:  21 Feb 2000 22:46:07 -0000
Message-ID:  <[email-masked]>
To:  [email-masked]

>bogus. My DNS servers refuse them as bogus.

RFC 1035 was updated in this regard years ago by RFC 2065.

>the responses? Have any other bogus query bits been spotted?

A query with the AD bit on does not conform to either RFC 1035 or to
RFC 2065/2535 (DNSSEC).  You should clear the AD bit in a response
unless you have cryptographically autenticated the response according
to DNSSEC and thus it would contain Authenticated Data.  If you are
not implementing DNSSEC, you should ignore the CD bit in requests and
it is immaterial whether it is on in responses or not.

>happens if they're rejected or discarded as bogus?

Its not just "allow".  Under some circumstances, DNSSEC strongly
encourages turning on CD in queries.

I assume your question above is rhetorical.

>to be documented as such.

DNSSEC assumes that security ignorant DNS servers will ignore the CD
bit.  This is entirely consistent with the general principle of
Internet architecture of being liberal in what you accept (RFC 1958,
section 3.9) although I will grant that that principle has not always
been applied in the DNS world.

This change is certainly documented in RFC 2065 issued in Janaury
1997, over two years ago, and in its successor RFC 2535, both of which
are properly labeled as updating RFC 1035. Furthermore, RFC 1035 does
not label its Z bits as being zero for all eternity but as reserved
for future use, use which would seem to me to require that they
sometimes not be zero.  And RFCs 2065 and 2535 clearly state that are
allocating two previously unused bits out of the DNS header.

Donald

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2000 19:27:03 -0000

The ``reserved means ignore'' argument is bogus. Packets that contain
opcode 14, rcode 11, or label 01 are normally discarded or rejected,
even though all of these numbers are marked as ``reserved'' in RFC 1035.

If a widespread client happens to ignore bogus rcodes by treating them
as rcode 0, and an extension assumes that all un-extended clients will
work this way, then that's a change to the un-extended protocol, and it
needs to be documented as such.

[email-masked] writes:
> It does say that they may be set

No. It says that they must not be set. ``Must be zero in all queries.''
These AD+CD queries blatantly violate this requirement.

I'm not objecting generally to changes in the protocol. But I am
objecting to inadequately documented transition plans: in particular,
mandatory changes that are hidden inside ``optional'' extension specs.

---Dan

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 22 Feb 2000 14:59:05 -0600

> The ``reserved means ignore'' argument is bogus. 

No it isn't.  But like any statement, it could be subjected to a
reductio ad absurdam lampooning.  If it's more important to win an
argument than to be correct, feel free.