Subject: ENDS compliance question

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 21 Sep 2007 12:35:05 -0400

Can an implementation silently ignore ENDS0 on query?

RFC2671 says implementation that does not support EDNS is expected to
return one of the following RCODEs: FORMERR, NOTIMPL, SERVFAIL

Implementation that supports ENDS will return an OPT record in the
additional section.

Q1: If the answer to an OPT question does not contain
any of the RCODES above and NO OPT record is that compliant ?

Q2: Does it make a difference if the answer is larger than 512 bytes
before the OPT record is added ?  (question advertises size of 2048)

	Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Sep 2007 17:33:58 +0000

> any of the RCODES above and NO OPT record is that compliant ?

good question.  the intent of this framer was that it wouldn't be compliant.

> before the OPT record is added ?  (question advertises size of 2048)

no.  EDNS is a protocol, and requests are to be answered definitively.  in
practical terms, requestors who receive a useful answer that doesn't include
an OPT will probably still accept and use it.  but OPT should be answered by
OPT or an error code, and technically, a response without an OPT is undefined
if the request had an OPT, and in that case, a new request could be sent
without an OPT (falling back to unextended DNS).

---

From: Peter Koch <[email-masked]>
Date: Fri, 21 Sep 2007 23:12:53 +0200

> any of the RCODES above and NO OPT record is that compliant ?

Compliant to what?  The EDNS0 RFC clearly cannot rule the behaviour of
non-EDNS-aware implementations, that's why it says "expected to send a response
with RCODE NOTIMPL, FORMERR, or SERVFAIL". This would not make sense as
normative text, it is just meant to give the reasoning for why the "EDNS first"
strategy won't hurt.  However, a server implementation could possibly just
ignore the additional OPT RR in the additional data section of the query
and respond as usual.  At least a quick scan didn't reveal a requirement
in 1034/35 that a query must have ARCOUNT==0. So, with the already too often
stretched robustness principle applied, the response is OK.

> before the OPT record is added ?  (question advertises size of 2048)

There's no explicit text in RFC 2671 that requires the responding party
to announce the use of the additional features that would work without the
OPT RR (e.g., >512 octet payload, extended label types).  However, there's
some indication that the spirit of the document was to do exactly that:
4.5.4. suggests you can probe for the other party's EDNS capabilities,
which is only useful if the responding server does not (can be expected not to)
hide. So, "yes", it makes a difference.

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Sun, 23 Sep 2007 11:12:30 +1000

> Can an implementation silently ignore ENDS0 on query?

	There are implementations that don't attempt to read the
	additional section.  They silently ignore EDNS.

> return one of the following RCODEs: FORMERR, NOTIMPL, SERVFAIL

	The key thing here is that you get a reply.  I don't believe
	RFC 1034 allows of non-replies.   There is no point in having
	FORMERR in RFC 1034 if a implemention is allowed to drop
	responses.

> Implementation that supports ENDS will return an OPT record in the

	Correct.

> any of the RCODES above and NO OPT record is that compliant ?

	The server is not RFC 2671 compliant if it fails to add the
	OPT record.  This is how UPDATE clients can work out how
	big a UPDATE message they can send of UDP.
 
> before the OPT record is added ?  (question advertises size of 2048)

	No.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]