[dns-operations] EDNS weirdness with certs.godaddy.com?

[Mark Andrews]

In message <554168F7.7070807 at lbl.gov>, Michael Smitasin writes:
> A few weeks ago we got reports of users unable to visit the
> certs.godaddy.com site, which had previously worked. Digging into it, it
> looks to be a DNS problem. We run our own name servers (BIND) so I do
> have access to configurations, though to the best of my knowledge, no
> config changes were made on our end. Running it through dnsviz.net also
> reports a problem:
> 
> > secureserver.net. to where.secureserver.net.: The server(s) responded
> > with a malformed response or with an invalid RCODE. (208.109.80.40,
> > 208.109.132.40)secureserver.net. to where.secureserver.net.: The
> > server(s) were not responsive to queries over TCP. (208.109.80.40,
> > 208.109.132.40)
> > certs.gd.where.secureserver.net./A: The response had an invalid RCODE
> > (FORMERR) until EDNS was disabled. (208.109.132.40)
> > certs.gd.where.secureserver.net./A: The response had an invalid RCODE
> > (FORMERR) until EDNS was disabled. (208.109.80.40)

FORMERR is not a problem with a RFC 103[45] server.  This just indicates
a pre EDNS server.
 
> Taking packet captures on our name servers while querying themselves
> (dig @127.0.0.1 certs.godaddy.com) will sometimes show a response from
> the GoDaddy name server, but our name servers don't seem to register it,
> they'll keep asking for NS records until the dig query times out.

This is broken behavior on the part of the server.  It should respond
to NS queries.  DNS is a query/response protocol and a server should
respond to all queries.

It should also not set the AD bit in the response as is it not
DNSSEC aware.  Nor should it set the last unallocated bit in the
response if it is set in the query.

; <<>> DiG 9.11.0pre-alpha <<>> certs.gd.where.secureserver.net @208.109.132.40 +norec +noedns +zflag
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47602
;; flags: qr aa ad; MBZ: 0x4; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;certs.gd.where.secureserver.net. IN	A

;; ANSWER SECTION:
certs.gd.where.secureserver.net. 60 IN	A	173.201.19.2

;; Query time: 39 msec
;; SERVER: 208.109.132.40#53(208.109.132.40)
;; WHEN: Thu Apr 30 13:54:35 EST 2015
;; MSG SIZE  rcvd: 65


>  Other
> times it'll return a Form-Err. I seem to be able to reproduce the
> Form-Err reliably by doing a dig +trace, or querying the authoritative
> name server for the target of the certs.godaddy.com CNAME
> (certs.gd.where.secureserver.net):
> 
> dig @gns1.secureserver.net certs.gd.where.secureserver.net +edns=0
> 
> (That query succeeds if you use +noedns instead)
> 
> Interestingly, we have 2 name servers, plus my own personal name
> servers, which do not have this issue. As mentioned in the DNSviz
> errors, the difference seems to be EDNS. I took a peek at some of the
> packet captures, and this appears to be the only significant difference:
> 
> > <root>: type OPT
> >     Name: <Root>
> >     Type: OPT (41)
> >     UDP payload size: 4096
> >     Higher bits in extended RCODE: 0x00
> >     ENDS0 version: 0
> >     Z: 0x8000
> >             1... .... .... .... = DO bit: Accepts DNSSEC security RRs=
> 
> >             .000 0000 0000 0000 = Reserved: 0x0000
> >     Data length: 0
> 
> Also interestingly, queries of the parent domain, secureserver.net, work
> fine, though they have a completely different set of authoritative name
> servers.
> 
> Anyone else run into this or have ideas what it could be? Does GoDaddy
> have a firewall that's mangling EDNS queries?

Load balancers are notorious for not being protocol compliant.
Returning bad / inconsistent rcodes.  Not answering anything other
than A (lately A or AAAA) queries.  These servers should be replaced
with something that is protocol compliant.

Mark

> Thanks,
> 
> --=20
> Michael Smitasin
> Network Engineer
> LBLnet Services Group
> Lawrence Berkeley National Laboratory
>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org