[dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

[Kumar Ashutosh]

I might be opening an already discussed question here (from RFC 6891):
Any OPTION-CODE values not understood by a *responder or requestor
   MUST be ignored*.  Specifications of such options might wish to
   include some kind of signaled acknowledgement.  For example, an
   option specification might say that if a responder sees and supports
   option XYZ, it MUST include option XYZ in its response.

This statement can be interpreted in multiple ways. 
Does it mean that, ignore the query altogether or
Ignore the OPT value only and process the query as if it does not exist.

The responder may also choose to simply respond back with same OPT record as it received if it supports EDNS0/1 and respond with failure if it does not.

If we are suggesting to drop the query altogether, it will impede the introduction of new OPT options (e.g. the client subnet one) as legacy machines will start dropping those packets with new OPT RRs.



Thanks
Ashu
Program Manager | Windows Networking| DNS & SDN

-----Original Message-----
From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On Behalf Of Mark Andrews
Sent: Thursday, May 28, 2015 07:34
To: Joe Abley
Cc: dns-operations at dns-oarc.net
Subject: Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.


In message <AD0F3C7E-72D4-4786-AF6C-1BF9CBAF833D at hopcount.ca>, "Joe Abley" writ
es:
> On 27 May 2015, at 13:00, Mark Andrews wrote:
> 
> > No. Just "different query - must be bad".  "Different query - don't 
> > know what to do -> drop" from firewall vendors.
> 
> For an enterprise, given that there's no defined use, format (and 
> therefore need) for EDNS(1), if your security posture is "default 
> deny, accept what we know we need" then dropping DNS messages with 
> EDNS(1) seems like exactly the right thing to do, doesn't it?

TLD operators are there to provide a service to the public and to the delegated zone.  Part of that service is a expectation that they will properly implement the protocol.

Or you can educate firewall vendors that it really does hurt their customers when you block extension mechanisms.  It makes life hard for their customer's customers.  Nameservers do handle the extensions even if not always correctly (formerr rather than ignore or ignore rather than badvers depending upon the extension) so it is most a case of blocking just because they can rather than because it is protecting anything.  Nameservers don't fallover these days, 20 years ago some did.

> I understand the point that this posture makes future development and 
> deployment of EDNS(1) hard. I understand why that's a pain for 
> protocol development in the DNS. You don't have to explain either of 
> those things to me. (Just saying.)
> 
> But it's not like anybody is going to succeed in getting an enterprise 
> or their firewall vendor to say yes when the request they are hearing 
> is "can you please open up this hole for an experimental protocol that 
> nobody apart from me knows anything about, so that I can play with it".

No.  It's tell me nicely that you don't support the extension.
Dropping packets is just plain anti-social and always has been.

A firewall can generate a BADVERS response, just like it can generate a TCP RST.  You don't have to break the protocol, you can co-operate with the protocol.

> Remember, these are the people that think ICMP is a security risk.
> 
> 
> Joe
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs