Tag Archives: dns

GoDaddy – mixed-case DNS WTFery.

A friend passed me a bounce of mail to my domain; DNS-related it said.

Dutifully, I checked the record:

$ dig @ns43.domaincontrol.com mibus.org mx

; <<>> DiG 9.7.3 <<>> @ns43.domaincontrol.com mibus.org mx
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 541
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;MibUs.OrG. IN MX

;; ANSWER SECTION:
MibUs.OrG. 3600 IN MX 10 aspmx.l.google.com.
MibUs.OrG. 3600 IN MX 20 alt2.aspmx.l.google.com.
MibUs.OrG. 3600 IN MX 20 alt1.aspmx.l.google.com.

;; AUTHORITY SECTION:
MibUs.OrG. 3600 IN NS ns43.domaincontrol.com.
MibUs.OrG. 3600 IN NS ns44.domaincontrol.com.

;; Query time: 89 msec
;; SERVER: 216.69.185.22#53(216.69.185.22)
;; WHEN: Fri Feb 24 08:42:50 2012
;; MSG SIZE rcvd: 155

Yep, there it is.

(...and yes, I'm with GoDaddy. I'm horribly likely to shift at my next renewal - if not before. But anyway).

Wait. "MibUs.OrG."?

It's repeatable, on that _one_ NS, from both the US and here in Australia. The other NS, is fine. Non-MX queries... are also fine. Mixed-case queries for the MX, all come back in that one same (different) case.

What. The. Hell.

I made a change to my zone data with their pretty web-based console. Re-ran the query... and it was fine. Except, all the mixed-case queries all came back lowercase.

Hmm. I wonder.

I made another change.

$ dig @ns43.domaincontrol.com Mibus.Org mx

; <<>> DiG 9.7.3 <<>> @ns43.domaincontrol.com Mibus.Org mx
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57417
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;Mibus.Org. IN MX

;; ANSWER SECTION:
Mibus.Org. 3600 IN MX 10 aspmx.l.google.com.
Mibus.Org. 3600 IN MX 20 alt2.aspmx.l.google.com.
Mibus.Org. 3600 IN MX 20 alt1.aspmx.l.google.com.

;; AUTHORITY SECTION:
Mibus.Org. 3600 IN NS ns43.domaincontrol.com.
Mibus.Org. 3600 IN NS ns44.domaincontrol.com.

;; Query time: 86 msec
;; SERVER: 216.69.185.22#53(216.69.185.22)
;; WHEN: Fri Feb 24 08:47:52 2012
;; MSG SIZE rcvd: 155

...and now, all DNS queries come back with this "proper case" version.

It's my humble opinion as a DNS administrator elsewhere, that they're running some sort of fancy reverse-caching DNS server in front of their "real" DNS servers; one that fakes the "AA" flag on responses, doesn't drop the TTL, and is cleared by their software on updates.

Oh, and one that preserves the case of the first query it sees in its cache, and keeps it around.

Why is this important? Well, for starters it's just stupid. For seconds, people are starting to use bit 0x20 (ie., the "shift" bit) for adding extra entropy in to DNS queries. GoDaddy's DNS servers go well beyond breaking it and in to the territory of royally messing it up.

How not to screw up DNS

DNS is a wonderful distributed system, with plenty of safeguards and fallbacks to ensure continuous operation.

But still, screwups happen. Here’s some tips on what to do to try to ensure you aren’t caught out in the cold.

Tip 1: Have multiple servers.

Without a doubt, this is the biggest tip about DNS. Designed in from the beginning was an assumption that you’d have multiple nameservers for a given zone. So… have them!

Put them as far apart as you reasonably can – different hosts, different networks, different power. The more they share, the more risk you’re in.

Countertip: Hosting your DNS server only over your ADSL link.

Tip 2: Do backups.

Pretty standard sysadmin fare. RAID isn’t a backup, and neither is a slaved nameserver.

Tip 3: Nameservers must all agree.

You know how kids will sometimes ask their parents the same question independently, hoping for a different answer? It’s important that the parents always give the same answer, and it’s downright vital that your nameservers do too. Don’t let them get out of sync!

Typically, zone transfers fix all your woes here, but do make sure they’re working.

Tip 4: Test your changes directly against all nameservers.

It’s just a small change, right? What could go wrong? Lots! So test each server individually. If one doesn’t update, maybe you have a problem that you need to fix. (Or maybe it’s just a bit laggy – it happens). “dig” is your friend.

Countertip: Not realising until too late that you’re breaking Tip 3

Tip 5: Make your NS records match your glue.

If you’ve told your domain registrar that your nameservers are ns1.example.org and ns2.example.org, then make sure you put that in your zone file too – all sorts of wacky caching issues can ensue when you don’t.

Tip 6: If you use a CNAME record, don’t use anything else.

CNAMEs are a really convenient way of saying “www.example.org is really webserver.example.org”. You can’t then say “But www has an MX of foo.example.org” or “www is also a subdomain with nameservers at …”.

That’d be contradictory, because you’ve already said with the CNAME that it’s really webserver.example.org. It can’t be both, if it’s both then it’s actually something different altogether and needs its own records.

Relatedly, don’t point a CNAME at anything other than a plain hostname – Don’t try to CNAME www.example.org to example.org, it’ll just break stuff.

Tip 7: Don’t firewall out DNS queries to your nameserver.

No, really. The whole internet needs to be able to look up domain names, not just some of it, not just most of it. (You’re excused if it’s a private nameserver, of course!).

Counterpoint: Using bogon filters on nameservers and ignoring genuine queries.

Bonus Tip: Monitor your servers.

If you’re running DNS servers in production, monitor them so you know that you haven’t lost one. Once it’s all set up right, you really can lose one without noticing.