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

Thu May 28 11:31:30 UTC 2015

In message <239c46218d5742838446ea9502573ee6 at HKNPR30MB017.064d.mgd.msft.net>, K
umar Ashutosh writes:
> Hi Mark=20
> Two things confuse me
> The draft (https://tools.ietf.org/html/draft-andrews-edns1-00) - by you say=
> s
> "
> 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.

RFC 2671 failed to clearly specify the behaviour of a server when
it receives a unknown EDNS option.  This resulted in a whole lot
of different behaviours including the behaviour that is specified
in RFC 6891.

RFC 2671 also specified that EDNS(1) queries get BADVERS independent
of the EDNS options.

In theory it should be possible to get clean behaviour for all EDNS
options by only sending them with EDNS(1) as a server that supports
EDNS(1) will have clean behaviour when handling unknown EDNS options.

In practice nameserver vendors have stuffed up EDNS version negotation
and firewall vendor have also broken EDNS version negotation by
dropping EDNS(1) queries.

http://ednscomp.isc.org/compliance/ts/gov.opt1fail.html

shows the sorts of failure modes seen when you combine EDNS(1) and
unknown EDNS options.

Mark

> Second=20
> "> The responder may also choose to simply respond back with same OPT=20
> > record as it received if it supports EDNS0/1 and respond with failure=20
> > if it does not.
> 
> Not if you are implementing RFC 6891.
> "
> 
> The RFC 6891 asks EDNS 0 compliant responders MUST respond to queries conta=
> ining 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.=20
> 
> 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]=20
> 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=20
> > 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=20
> > record as it received if it supports EDNS0/1 and respond with failure=20
> > if it does not.
> 
> Not if you are implementing RFC 6891.
> 
> > If we are suggesting to drop the query altogether, it will impede the=20
> > introduction of new OPT options (e.g. the client subnet one) as legacy=20
> > machines will start dropping those packets with new OPT RRs.
> 
> You can see the expected behaviour with this query / respone.  The query ha=
> s 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 optio=
> n.
> 
> ; <<>> DiG 9.11.0pre-alpha <<>> +qr +expire soa . @a.root-servers.net +noau=
> th +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 r=
> d; 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.veris
> ign-grs.com. 2015052800 180=
> 0 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org