PTR Records Are Strange

When I first moved to San Francisco, I asked Sonic.net for a static IP address. The IP they assigned me is 75.101.96.6 (my actual IP address, be kind). I noticed something strange when using IRC. Many IRC clients will do reverse DNS lookups with whois queries, or automatically when users join or part channels. When I logged into Freenode, I’d see my IP displayed as leela.kabewm.com. I did a reverse DNS query to 75.101.96.6 with dig -x, and sure enough, there’s a PTR record for my apartment:

$ dig -x 75.101.96.6

; <<>> DiG 9.11.1-P3-RedHat-9.11.1-7.P3.fc27 <<>> -x 75.101.96.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13278
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;6.96.101.75.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
6.96.101.75.in-addr.arpa. 14399	IN	PTR	leela.kabewm.com.

;; Query time: 239 msec
;; SERVER: 192.168.86.1#53(192.168.86.1)
;; WHEN: Tue Oct 24 01:34:17 PDT 2017
;; MSG SIZE  rcvd: 83

I was naturally curious what the IP had been used for, but it turns out kabewm.com is entirely defunct. There’s still an SOA record, and even some MX records, but no A records exist for leela.kabewm.com or even kabewm.com itself:

$ dig A kabewm.com

; <<>> DiG 9.11.1-P3-RedHat-9.11.1-7.P3.fc27 <<>> kabewm.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54340
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kabewm.com.			IN	A

;; AUTHORITY SECTION:
kabewm.com.		549	IN	SOA	carl.ns.cloudflare.com. dns.cloudflare.com. 2026031700 10000 2400 604800 3600

;; Query time: 45 msec
;; SERVER: 192.168.86.1#53(192.168.86.1)
;; WHEN: Tue Oct 24 01:59:09 PDT 2017
;; MSG SIZE  rcvd: 98

This is kind of weird right? At one point in time someone created a DNS record for leela.kabewm.com, and a corresponding PTR record was allocated. The original A record is now gone, but the phantom PTR record lingers. How does this work? What do you need to do if you want to remove the phantom PTR record?

The way this actually works is kind of non-obvious, because everything in reverse DNS is reversed. Normally we think about domains in terms of a domain registrar, and zones defined by SOA records. But domains point to IP addresses, and often the the entities owning IP addresses aren’t necessarily the people who own the domains pointing to them. The IP addresses themselves are owned by ISPs and other large organizations who are big enough and important enough to have received an IP allocation. If you’re a big company like Google you own both your own domain name and the IP addresses the domain points to. But if you’re a regular Joe using a residential ISP, or someone using a cloud service like AWS or Google Cloud, you don’t own the IP address.

That means that if you want to remove an old PTR record, you don’t really go through the domain name system at all. Instead, you need to appeal to the entity who actually owns the IP. In my case, this means that I would can request that Sonic.net remove the old record.

How PTR Lookups Are Actually Resolved

Incidentally, this is all related to the reason that PTR records are formed with the IPv4 address octets in reverse order. As you may have seen from the dig -x output, the reverse DNS record for 75.101.96.6 is given by the PTR record for 6.96.101.75.in-addr.arpa. This is because IPv4 addresses are big-endian, in the sense that the most significant octet is the leftmost octet. This is also why big-endian is called “network byte order”: it’s literally the octet order we use with IPv4 addresses, which is the same left-to-right order English is written in. By contrast, DNS names are right-to-left hierarchical, in the sense that the most significant part, the TLD, is on the right. To map an IPv4 address to a PTR record, the left-to-right reading of IPv4 octets needs to become right-to-left in the PTR record, to maintain the original hierarchical structure.

As you can see here, the block 75.0.0.0/8 is controlled by ARIN, the regional registry for North America. So the top level DNS resolver for in-addr.arpa just needs to know that all of the subdomains of 75.in-addr.arpa belong to ARIN, and then it can delegate the rest of the lookup to ARIN. If you look up dig NS in-addr.arpa you’ll see that you see a list of name servers including a.in-addr-servers.arpa. If you query dig @a.in-addr-servers.arpa NS 75.in-addr.arpa you’ll see it delegates to a name server list with names like x.arin.net. As predicted, ARIN runs the DNS servers responsible for this part of the PTR hierarchy. Eventually this resolves to a DNS server owned by Sonic.net, which delegates for the range 75.101.96.0/24 (or equivalently, for 96.101.75.in-addr.arpa). Reverse DNS lookups aren’t terribly common, but in principle this system is extremely scalable, since it can be sharded with a fan-out of 256 levels for each octet.