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.