Subject: Re: EDNS0 revisions

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Jan 2008 01:24:40 +1100

> At 15:19 -0800 12/31/07, Noah Treuhaft wrote:
> 
> >I think it's reasonable for a responder who does not understand the OPT
> >pseudo-RR to ignore it and respond as though the OPT were absent from
> >the request.  As the above paragraph stands, that's unexpected behavior.
> >Is there any reason it should be?
> 
> Maybe my recollection is hazy, but I think the theory is that any 
> responder that does not understand the OPT pseudo-RR would barf when 
> seeing a record in the additional section in a query.

	There were servers that never parsed to the end of a incoming
	packet.

> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Think glocally.  Act confused.
> 
> --
> 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: bert hubert <[email-masked]>
Date: Tue, 1 Jan 2008 15:56:21 +0100

> 	There were servers that never parsed to the end of a incoming

To this day, the PowerDNS Authoritative Server still does not react to
incoming EDNS0 options. It silently ignores the OPT record at the end of the
packet, and does not send one back in the response.

This might be rectified in 3.0. 

The PowerDNS Recursor does parse & react to OPT records.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Jan 2008 17:28:49 +0000

> > 	There were servers that never parsed to the end of a incoming packet.

since there was no requirement in 1034/1035 that SERVFAIL be sent or that
the additional data section be empty, that is perfectly valid behaviour.

> ...

sounds like perfectly valid 1034/1035 behaviour to me.

i propose the following:

@@ -254,7 +254,8 @@
 .LP
 5.3. Responders who do not understand these protocol extensions are expected
 to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or to appear to
-"time out" due to inappropriate action by a "middle box" such as a NAT.
+"time out" due to inappropriate action by a "middle box" such as a NAT, or
+to ignore extensions and respond only to unextended protocol elements.
 Therefore use of extensions SHOULD be ``probed'' such that a responder who
 isn't known to support them be allowed a retry with no extensions if it
 responds with such an RCODE, or does not respond.  If a responder's
 capability

---

From: bert hubert <[email-masked]>
Date: Tue, 1 Jan 2008 21:53:01 +0100

> sounds like perfectly valid 1034/1035 behaviour to me.

Sounds good to me. Additionally, as of today the PowerDNS Authoritative
Server supports EDNS0 on incoming queries:
http://wiki.powerdns.com/cgi-bin/trac.fcgi/changeset/1123

	Bert

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Jan 2008 11:19:13 +1100

> sounds like perfectly valid 1034/1035 behaviour to me.

	We should split this into two parts.  Correct behaviour and
	observed behaviour.   We can debate where silently ignoring
	the OPT record fits.

	1. State what non-EDNS servers are supposed to do.
	
5.3. Responders who do not understand these protocol extensions are expected
to send a response with RCODE FORMERR or NOTIMPL.

	State what other issues have been seen.

5.4. ....

---

From: Kenji Rikitake <[email-masked]>
Date: Wed, 2 Jan 2008 15:31:27 +0900

In the message <[email-masked]>
dated Tue, Jan 01, 2008 at 04:36:53AM +0000,
Paul Vixie <[email-masked]> writes:
> still, it's possible that an older implementation wouldn't notice the OPT RR
> at all.  [...]

The tinydns and dnscache of djbdns-1.05 does not notice the OPT RR at all.

Also an interesting reference from this mailing list:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00842.html

FYI
// Kenji Rikitake

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Jan 2008 09:41:23 -0500

>The PowerDNS Recursor does parse & react to OPT records.

What happens if there is an OPT in the query but not in the response?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jan 2008 16:27:22 +0000

> > still, it's possible that an older implementation wouldn't notice the OPT
> > RR at all.  [...]
> 

as i said before, nothing about 1034 or 1035 requires a SERVFAIL or FORMERR
when a query contains an unexpected additional-data section.

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00842.html

in retrospect, that test plan assumes too much about non-EDNS0 clients and
servers.  considerable latitude has to be shown by an EDNS0 initiator as far
as determining that the responder doesn't speak EDNS0.  either all of the
various possible kinds of non-EDNS0 behaviour have to be enumerated, and the
test matrix needs more rows and columns, or else we have to admit that this
approach will have only limited application.