[dns-operations] Hall of DNS Shame (?)
marka at isc.org
Mon Jan 30 21:27:53 UTC 2017
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
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
More information about the dns-operations