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

[Mark Andrews]

In message <D8AB84CE-6D19-4787-A3AB-F4F5AC17CD40 at dukhovni.org>, Viktor Dukhovni writes:
> 
> > On Jan 24, 2017, at 12:52 PM, Robert Edmonds <edmonds at mycre.ws> wrote:
> > 
> >> I can contribue a bunch of DNS operators that botch authenticated
> >> denial of existence in a variety of ways, some instead mangle SOA
> >> record signatures, and some others drop requests for TLSA records.
> > 
> > I think these kinds of errors are in another category, and there are
> > already some pretty good tools for dealing with them like DNSViz.
> > Sending the wrong data correctly encoded is different from incorrectly
> > encoding the data.
> 
> Yes, DNSViz provides useful tooling to document the issue when corresponding
> with the operators in question, however it applies no public pressure to
> address the issue in a timely manner.
> 
> I don't see why a list of poor DNS implementations should be limited to
> malformed packets, and exclude well formed bad data.
> 
> While I've had luck working directly with some providers (with 
> Transip, Forpsi, Binero, Neustar and a few others addressing reported
> issues), some other providers ignored problem reports until the issue
> was raised in a public forum.

Even raising it in a public forum doesn't work.  Qwests DNS server
are still not fixed 4 months after pointing out that they return
BADVERS to DNS COOKIES and as they are serving signed zones this
results in SERVFAIL on nanog.  BADVERS is for EDNS version negotiation.
There is another opcode reserved for "I don't understand" / "I got
something unexpected" and that is FORMERR.  See RFC 1034 and RFC
1035.

What I think was being thought was "There are options here, this
must be a EDNS(1) query with the wrong version number so we will
send BADVERS".  Just forget that it has another defined meaning.

Can the vendor(s) that made this choice please issue a CVE against
this behaviour.

We mark the server as broken for EDNS and move on.  Yes, this breaks
DNS resolution of signed zones if you are validating.  You can tell
named to not send cookies to these servers in named.conf.  This way
the error is raised to a level where a person needs to intervene.

Those that return FORMERR to unknown EDNS options also return FORMERR
to EDNS(1) queries with unknown EDNS options.  I can understand
returning FORMERR to EDNS(0) but to EDNS(1) when options are TLVs
that you can skip over and return BADVERS and negotiate back to
EDNS(0).  That choice has never made sense.  It defeats the entire
purpose of EDNS version negotiation.

Can the vendor(s) that made this choice please issue a CVE against
this behaviour.

Again we mark the server broken for EDNS and move on.  Yes, this
breaks DNS resolution of signed zones if you are validating.

Can all the firewall vendors that block well formed DNS packets
because that contain something NEW please issue CVE's against
those products.

Can Microsoft please issue a CVE against their old DNS servers that
don't answer the second EDNS query from a address.  Replies get
lost and not answers results in a denial of service.  We have been
attempting to work around this misbehaviour for over a decade now
and it is still causing operational issues.

Mark

> -- 
> 	Viktor.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org