Subject: Re: edns-0

From: Kevin Darcy <[email-masked]>
Date: Wed, 05 Mar 2008 00:42:31 -0500

Wouter Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Changed subject line.
>
> Mark Andrews wrote:
> |>>     EDNS has been on standards track for 9+ years now.  It takes
> |>>     less than a day to add EDNS support to a nameserver.  There
> |>>     really is no excuse anymore for any vendor shipping a DNS
> |>>     server that doesn't respond to EDNS queries using EDNS.
> |>>
> |>>     If you have a DNS server, however old, that drops EDNS
> |>>     queries then you should ship a fix.  The server is BROKEN
> |>>     and the rest of us are feed up with working around broken
> |>>     implementations.
> |> "send diffs."
> |
> |    5.3. Responders who do not understand these protocol extensions
> |    are expected to send a response with RCODE NOTIMPL or FORMERR
> |    as per RFC 1034.  Firewalls that do not pass EDNS are expected
> |    to respond requests with FORMERR.
> |
> |    5.4. Firewalls that see a UDP/EDNS request that indicates a UDP
> |    buffer size that is larger than the firewall's maximum DNS/UDP
> |    transmission size should respond to the EDNS request with
> |    RCODE=<TBA> and set the UDP size to the firewalls maximum DNS/UDP
> |    transmission size.
>
> I like the text up to here. The remainder is not going in the draft.
>
> |    5.5. There are firewalls that pass EDNS queries but fail to allow
> |    responses larger that 512 octets through.  A client MAY choose to
> |    treat a timeout out as indicating the a UDP buffer size of 512
> |    octets should be advertised in future requests.
>
> Firewalls that drop responses larger than 512 should send an errorcode.
>
> |    5.6. There are responder and firewalls that silently drop EDNS
> |    requests.  A client MAY choos to treat timeouts as indicating
> |    lack of EDNS support.  The client however MUST first attempt
> |    making EDNS requests with a UDP payload size of 512 if it makes
> |    this decision.
>
> Firewalls should not silently drop EDNS, but instead send the rcode.
I don't like this at all. It moves us a big step away from the 
End-to-End Principle, from *passive* violation of the principle -- a 
firewall posing as "noise", passing or dropping packets as its policy 
dictates, with packet drop being handled by the usual retry/retransmit 
mechanisms and/or parameters -- to *active* violation of the principle, 
by deliberate and direct in-transit manipulation of the 
endpoint-to-endpoint payload by an intermediate node.

In my opinion, this is almost as bad as NAT or its associated in-transit 
DNS "fixups".

Beyond the pure protocol objection, I also have little confidence that a 
firewall implementor who hasn't bothered to add EDNS0 compatibility 
after all this time is suddenly going to acquire the enthusiasm and 
wherewithal to enhance their product(s) with a new "error code" feature. 
Or, if they attempt it, they'll probably get it wrong.

                              - Kevin

--
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/>