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

[Mark Andrews]

In message <201701302214.v0UMElTL029245 at aurora.sol.net>, Joe Greco 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?
> > 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).
> 
> Because DNS is a core service, and things that actively break DNS and
> force resolver implementations to do stupid things in order to work
> around hare-brained software written by people who didn't understand
> (or even read) the spec, or refused to update it as the spec has 
> evolved, are creating interoperability issues.
> 
> Trying to "fix" this within the DNS framework creates a false sense 
> that the firewall isn't really at fault, and that future issues will
> similarly be addressed within the "faulty" protocol.
> 
> There's probably a fairly strong argument to be made that creating
> fallback workarounds for some of these problems is just as much part
> of the problem, but I find it hard to blame developers for trying to
> make things work in suboptimal environments.

Which is why BIND 9.11 isn't retrying with a EDNS query without a
cookie option.  More work arounds just cause more problems.  The
existing work around for servers/firewalls dropping EDNS queries
causes issues with DNSSEC validation.  The recursive server doesn't
know why it didn't get a answer.  Packet loss can look like a
firewall dropping EDNS.

> But in the end, this is similar to blocking TCP 53.  It's broken, and,
> more importantly, relies on workarounds and retries and othe cruft 
> that allows the status quo to remain, which creates new hazards as we
> move forward.  It may not be quite the same as a conventional CVE, but
> I don't think the community has a viable alternative mechanism to seek
> a correction.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
> With 24 million small businesses in the US alone, that's way too many apples.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org