rDNS Epic Failures

Over the past week we’ve been helping a client get their systems properly configured. One of the issues we needed to resolve was reverse DNS entries (rDNS). Pretty simple task huh? Especially for the “network engineers” at a data centre. Surely they should know how to do this.

For more than eight days we had to work with this colo-provider. We asked for rDNS entries. After two days they responded, asking for clarification. Um? REVERSE DNS, add it to your NS!!.

A day later they responded that it was complete. We checked. No entry was found. SERVFAIL was the response from the `host` command.

Using `dig` directly to their NS we were able to see that their NS (the authoritative one for this block of IPs according to ARIN) was responding to these was REFUSED!!.

Usually `dig` responds with something like this:

;; HEADER opcode: QUERY, status: NOERROR, id: 64327
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Their epic-failure response looks like this:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 34593
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

They are the authoritative NS for this block of IPs and they refused PTR queries from the public internet, which they are supposed to be serving. Apparently this had been an issue at their facility for weeks if not months. It took us three days to explain to their "engineers" why this was an issue! Read the fucking RFCs idiot!

Of particular humour was when they demonstrated to us their NS was working, by testing the NS from it-self (epic fail!). Our point was that the NS wasn't working from outside (London, Dallas, Seattle). What did they do? Test from localhost. Um? Are you kidding me?

It's unfortunate that there are so many amateurs. If you're sick of working with them call us. We follow standards and persistently push others to do the same.

http://blog.edoceo.com/