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

[Kumar Ashutosh]

Hi Mark 
Two things confuse me
The draft (https://tools.ietf.org/html/draft-andrews-edns1-00) - by you says
"
The updated EDNS
   specification [RFC 6891] makes ignoring unknown EDNS options a
   explicit requirement but failed to bump the EDNS version number.

   Currently there are EDNS version 0 servers that *ignore unknown EDNS
   Options*.  Those that return FORMERR when unknown EDNS options are
   present.  Those that return BADVERS when unknown EDNS options are
   present.  Those that return REFUSED when unknown EDNS options are
   present and presumably those that return NOTIMP (though the author
   has not seen one).

"

It appears that the ignoring of unknown EDNS option means, responding back with a failure (forerr, badvers etc.). Can you clarify it a little bit.

Second 
"> 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.

Not if you are implementing RFC 6891.
"

The RFC 6891 asks EDNS 0 compliant responders MUST respond to queries containing OPT RR with a response containing OPT RR, so that the client is able to distinguish. But it is not clear if it just an empty OPT RR or same. 

I think that can be explicitly qualified.

Thanks
Ashu
Program Manager | Windows Networking| DNS & SDN

-----Original Message-----
From: Mark Andrews [mailto:marka at isc.org] 
Sent: Thursday, May 28, 2015 14:32
To: Kumar Ashutosh
Cc: Joe Abley; 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 <562cc134b2724b889f07ded8737c43f1 at HKNPR30MB017.064d.mgd.msft.net>, K umar Ashutosh writes:
> 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.

It says to ignore the option not the request.

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

Not if you are implementing RFC 6891.

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

You can see the expected behaviour with this query / respone.  The query has a EDNS EXPIRE option set (RFC 7314) which is not supported by the server.  You still get back the SOA record but you don't get back the expire option.

; <<>> DiG 9.11.0pre-alpha <<>> +qr +expire soa . @a.root-servers.net +noauth +noadd ;; global options: +cmd ;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14277 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; EXPIRE
;; QUESTION SECTION:
;.				IN	SOA

;; QUERY SIZE: 32

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14277 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 25 ;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.				IN	SOA

;; ANSWER SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2015052800 1800 900 604800 86400

;; Query time: 262 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Thu May 28 18:58:21 EST 2015
;; MSG SIZE  rcvd: 812

Mark

> Thanks
> Ashu
> Program Manager | Windows Networking| DNS & SDN

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