[dns-operations] Hall of DNS Shame (?)

[Mark Andrews]

In message <CALMep06F9HO5ejJLSH5sou5M_tEtHG1NbyUqBzeGr3DQGM7Rog at mail.gmail.com>, Steven Carr writes:
> On 30 January 2017 at 19:44, Mark Andrews <marka at isc.org> wrote:
> >
> > The first vendors that need to be contacted are firewall vendors.
> > They need to remove the idiotic packet dropping by default for:
> >
> > * dropping requests with EDNS version != 0
> > * dropping requests with EDNS option being present
> > * dropping requests with EDNS NSID option being present
> > * dropping requests with A EDNS flag being set other than DO.
> > * dropping requests with AD=1
> > * dropping requests with DO=1 (nearly gone)
> > * dropping requests with the last MBZ bit set.
> >
> > They need to issue CVE's for all code that has these properties.
> 
> Why would any of the above "broken" implementations warrant a CVE?

Note the word dropping.  That is denial-of-service.  That required
resolvers to implement workaround code.  Now most servers have
implemented fallback to plain DNS if a EDNS query fails.  That was
a workaround for firewall stupidity like this.  It was also a
workaround for Microsoft DNS's failure to respond to the second
EDNS query after returning a FORMERR to the first which also really
requires a CVE to be issued for it.  Packets get lost.  Not answering
the second query means that retries are not answered.

If you have a signed zone behind such a firewall and the client
does anything that causes the firewall to be dropped, like say
sending a DNS Cookie, then dropping back to plain DNS won't work.
Dropping back from EDNS + Cookie -> plain EDNS -> plain DNS takes
too long.

It takes BIND 9.11.0 6.5 seconds to resolve health.gov.au due to
the firewalls dropping EDNS + Cookie for what should be a 60ms
resolution and that is without DNSSEC being in the picture.  It
also around 50 queries.

6.5 seconds is more time than web browsers wait.

So yes this behaviour requires a CVE because most if not all of
the DNS operators have no clue this is happening.

> AFAIU CVE are for information security exposure and security
> vulnerabilities, how do any of the above consititute one of those? In
> order to raise a CVE you're going to have to prove it's causing damage
> (or has the potential to cause damage).
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org