[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EDNS0 revisions



> 3. change 5.3 as follows.  old:
> 
>    5.3. Responders who do not understand these protocol extensions are
>         expected to send a response with RCODE NOTIMPL, FORMERR, or
>         SERVFAIL.  ...
> 
>    new:
> 
>    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.  ...

>    old:
> 
>              ... 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.  ...
> 
>    new:
> 
>              ... 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.
>         ...

	I think formalising the reaction to timeout for EDNS failues
	to fall back to plain DNS is wrong.  As dependany of EDNS
	increases (e.g. DNSSEC) it is much more important that
	packet loss is treated as packet loss and not broken servers
	/ middle boxes.

	Fallback to EDNS udpsize=512 maybe but not plain DNS on timeout.
	This will interoperate with firewalls that enforce a 512 byte
	packet size and not loose EDNS signaling which is required
	for DNSSEC.

	Yes there are some load balancers that do the wrong thing and
	drop queries but they are NOT RFC 103[45] compliant if they
	do that.  Codifing such non-compliance is wrong.

	Should we codify non response to non A queries as right? 
	Should we codify NXDOMAIN responses to unknow qtypes as right?
	Should we codify returning the wrong SOA record as right for
	negative responses?

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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