# Intro
Almost everyone knows DNS is the phone book of the internet and that it is broken up into various types of records… but how does it really work?
# Types of DNS records
A DNS query starts with a question to a DNS server. For any DNS question to ask of a server, they will respond with an answer. These answers are key:vaue pairs for any given question. Let’s examine some types of questions, for example…
# A
A records tell us the IPv4 address that a given name resolves to. Using dig (A simple command line utility to perform DNS look-ups) to ask for the A record for www.google.com:
$ dig A www.google.com
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> A www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30217
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 247 IN A 142.250.191.164
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 59
Other times we might see, as in the case of cloudflare.com that there are multiple values to the same key.
$ dig A cloudflare.com
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> A cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49636
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com. IN A
;; ANSWER SECTION:
cloudflare.com. 75 IN A 104.16.132.229
cloudflare.com. 75 IN A 104.16.133.229
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 75
# AAAA
Not too interesting, the IPv6 counterpart to our above A record.
$ dig AAAA cloudflare.com
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> AAAA cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12053
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com. IN AAAA
;; ANSWER SECTION:
cloudflare.com. 168 IN AAAA 2606:4700::6810:84e5
cloudflare.com. 168 IN AAAA 2606:4700::6810:85e5
;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 99
# PTR
PTR records can be thought of as the inverse, providing a name mapping to an IPv4/IPv6 address. Lets take google’s IPv4 address from above and do a lookup.
To query one with dig we utilize the -x argument instead of specifying PTR as the record type like we did with A.
$ dig -x 142.250.191.164
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -x 142.250.191.164
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57533
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;164.191.250.142.in-addr.arpa. IN PTR
;; ANSWER SECTION:
164.191.250.142.in-addr.arpa. 84739 IN PTR ord38s30-in-f4.1e100.net.
;; Query time: 27 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 95
Note the curious portion of the question section. It is our IP address in reverse with .in-addr.arpa. appended to it.
We will touch on this more in a later section. In this case, note our answer: ord38s30-in-f4.1e100.net.
which is one of the reverse names for Google’s server.
$ dig +short A ord38s30-in-f4.1e100.net.
142.250.191.164
# NS
For any given server, we need to understand how to actually query names for any given location. For example…
$ dig whitehouse.gov ns
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> whitehouse.gov ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58569
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;whitehouse.gov. IN NS
;; ANSWER SECTION:
whitehouse.gov. 86400 IN NS wally.ns.cloudflare.com.
whitehouse.gov. 86400 IN NS ernest.ns.cloudflare.com.
;; Query time: 152 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 101
We can see that whitehouse.gov is served by Cloudflare. Understanding how the entire name-server chain works will be explained in a later section.
# SOA
SOA records stand for Start of Authority, and can be queried like any other.
$ dig statefarm.com SOA
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> statefarm.com SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24778
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;statefarm.com. IN SOA
;; ANSWER SECTION:
statefarm.com. 300 IN SOA ns74-am.statefarm.com. root.statefarm.com. 3799 10800 3600 2419200 300
;; Query time: 628 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 91
The first entry will signify a name server for the domain. The second entry, confusingly enough, represents an email.
In this case, our first . is replaced by an @ to come out with root@statefarm.com. This is our “domain contact”
so to speak.
# TXT
Text records are arbitrary records that typically contain domain verification text. As in our previous examples…
$ dig statefarm.com txt
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> statefarm.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61457
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;statefarm.com. IN TXT
;; ANSWER SECTION:
statefarm.com. 300 IN TXT "vmware-cloud-verification-ebcaad8f-d80c-4937-a5eb-beae0ac7647b"
statefarm.com. 300 IN TXT "Dynatrace-site-verification=2c1d3749-4815-4e2f-9e2d-548f91ad6675__ck4kaq57tgo2i40i4qcnml4tn5"
statefarm.com. 300 IN TXT "unity-sso-verification=869f7686-8120-414b-b4cb-81acf21eb143"
statefarm.com. 300 IN TXT "dell-technologies-domain-verification=statefarm.com_90ab7254-abce-409a-9871-e57765ee06e0_1722089303"
statefarm.com. 300 IN TXT "_keb28hftnm8r1juahvq669ccy34rxhs"
statefarm.com. 300 IN TXT "infoblox-domain-mastery=37c4f2bb9e2c3c7895ef3a08ab324167ca8012adda6d9365850fd5dbc41edac3c0"
statefarm.com. 300 IN TXT "yahoo-verification-key=+n1JpZryZZxmOpQjafQZfzBN+IpCelY8XUw9m1enSTM="
statefarm.com. 300 IN TXT "liveramp-site-verification=0S7n5roiw5pwuyFp0nPtaKD1vji7s9njFHb_SeXhgJo"
statefarm.com. 300 IN TXT "confluent-verification=b1fc325f-ebd4-4bed-8817-e323930d2701"
statefarm.com. 300 IN TXT "v=spf1 include:spf-00104b02.pphosted.com include:spf-00104b03.pphosted.com include:spf-00104b04.pphosted.com ~all"
statefarm.com. 300 IN TXT "google-site-verification=dBkEsjv9URgEpuC2J4Ec9RWLreVDCPw4g3kukgD4nVI"
statefarm.com. 300 IN TXT "google-site-verification=HIL7kX87WOVaTsTCdULCXDz4abDh9a7dMhfcChvHn-w"
statefarm.com. 300 IN TXT "google-site-verification=mfVHn7eESOGj8ClMbOEOZ4OBVocXXU4dknQRD5iem2Q"
statefarm.com. 300 IN TXT "hover-site-verification=ZxnVaO8KLt"
statefarm.com. 300 IN TXT "google-site-verification=WHICQV05cGSovIYMhfCdVR8sDIt6ien3H73lzHfEzhs"
statefarm.com. 300 IN TXT "cisco-ci-domain-verification=3703a183b39432db5ac302eb2d603e009e5dab42a5fb0e2d0e63794feb7b5fad"
statefarm.com. 300 IN TXT "l4cd3yXILz0DOwXK6dTOZQ"
;; Query time: 208 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; MSG SIZE rcvd: 1427
This can clue you in to what an organization may be utilizing with its tech stack…
# MX
MX records are what are utilized for mail transfer, if you need to send email to a domain, those names are the specific servers to talk to when sending. Email clients handle this for you automatically.
$ dig mx statefarm.com
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> mx statefarm.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7321
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;statefarm.com. IN MX
;; ANSWER SECTION:
statefarm.com. 300 IN MX 10 mxa-00104b02.gslb.pphosted.com.
statefarm.com. 300 IN MX 10 mxb-00104b02.gslb.pphosted.com.
;; Query time: 308 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 114
# AXFR
Now, onto something a bit more interesting. AXFR records are Zone Transfer’s. What this means is we ask
the server for all the names it knows about. Exploration of this is left as an exercise for the reader.
# But how do we get there?
When we navigate to a site, it’s a given that google.com will take us to the right spot… But is it clear how we get there?
First, we need a name server to ask in order to turn google.com into an IP address.
On Linux our default name server is specified in the /etc/resolv.conf file.
$ cat /etc/resolv.conf
nameserver 1.1.1.1
Which is indicating that we will utilize the name server 1.1.1.1. When we dig …
$ dig google.com
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26020
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 207 IN A 142.250.191.238
;; Query time: 27 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 55
We get back an answer in the form of an A RECORD with a value of 142.250.191.238. Which is nice… but how does 1.1.1.1 know the answer to our question?
# Walking the Chain
To answer this, lets download our own DNS resolver. After downloading, compiling, and the initial setup, our unbound instance is listening on port 53 locally. Lets issue our query for google.com while using tcpdump.
$ dig google.com
--- CUT ---
17:41:11.748710 lo In IP 127.0.0.1.41455 > 127.0.0.1.53: 28959+ [1au] A? google.com. (51)
17:41:11.749068 eth0 Out IP 192.168.121.47.8190 > 192.112.36.4.53: 30639% [1au] NS? . (28)
Interesting, our local device connects out to 192.112.36.4 asking for the name server for .. But where does this . query and this 192.112.36.4 server come from?
This . can be thought of as the “root” of all the domain name services on the internet and is a name like any other (Though often omitted for brevity). For example, for any given address such as google.com we would actually query google.com.. This is easier to think about backwards. For example: .com.google. Where we ask each sequential server where to gather information about the next. First we would ask the server responsible for . where to find com. Next we would ask the com servers where to find google and so on and so forth.
If we look around our local install of unbound for this IP…
$ rg '192.112.36.4'
unbound/unbound.conf
1225: primary: 192.112.36.4 # g.root-servers.net
We can see that this server is hard coded in our configuration file as a server to talk to! This is what is known as a root-hints file, allowing us to bootstrap any DNS query.
Knowing this, lets issue our own query for . at that server…
$ dig '.' ns @192.112.36.4
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> . ns @192.112.36.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31967
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 4c713c70a88c78fe0100000067e6e0a6f11c497a76eebbb4 (good)
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS l.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS m.root-servers.net.
;; ADDITIONAL SECTION:
m.root-servers.net. 518400 IN A 202.12.27.33
l.root-servers.net. 518400 IN A 199.7.83.42
k.root-servers.net. 518400 IN A 193.0.14.129
j.root-servers.net. 518400 IN A 192.58.128.30
i.root-servers.net. 518400 IN A 192.36.148.17
h.root-servers.net. 518400 IN A 198.97.190.53
g.root-servers.net. 518400 IN A 192.112.36.4
f.root-servers.net. 518400 IN A 192.5.5.241
e.root-servers.net. 518400 IN A 192.203.230.10
d.root-servers.net. 518400 IN A 199.7.91.13
c.root-servers.net. 518400 IN A 192.33.4.12
b.root-servers.net. 518400 IN A 170.247.170.2
a.root-servers.net. 518400 IN A 198.41.0.4
m.root-servers.net. 518400 IN AAAA 2001:dc3::35
l.root-servers.net. 518400 IN AAAA 2001:500:9f::42
k.root-servers.net. 518400 IN AAAA 2001:7fd::1
j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30
i.root-servers.net. 518400 IN AAAA 2001:7fe::53
h.root-servers.net. 518400 IN AAAA 2001:500:1::53
g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d
f.root-servers.net. 518400 IN AAAA 2001:500:2f::f
e.root-servers.net. 518400 IN AAAA 2001:500:a8::e
d.root-servers.net. 518400 IN AAAA 2001:500:2d::d
c.root-servers.net. 518400 IN AAAA 2001:500:2::c
b.root-servers.net. 518400 IN AAAA 2801:1b8:10::b
a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30
;; Query time: 367 msec
;; SERVER: 192.112.36.4#53(192.112.36.4) (UDP)
;; MSG SIZE rcvd: 851
Cool. This is a list of all the root name servers on the internet. Each of the 13 servers has a corresponding A record and a AAAA record. All of these servers have the information needed to communicate with the next level of servers. Eg “com.” or “net.”. Who actually owns this server, though? Lets use the whois command to find out.
$ whois 192.112.36.4
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
NetRange: 192.112.36.0 - 192.112.36.255
CIDR: 192.112.36.0/24
NetName: LOCALNET
NetHandle: NET-192-112-36-0-1
Parent: NET192 (NET-192-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: DoD Network Information Center (DNIC)
RegDate: 1991-06-26
Updated: 2021-12-14
Ref: https://rdap.arin.net/registry/ip/192.112.36.0
OrgName: DoD Network Information Center
OrgId: DNIC
Address: 3990 E. Broad Street
City: Columbus
StateProv: OH
PostalCode: 43218
Country: US
RegDate:
Updated: 2025-03-13
Ref: https://rdap.arin.net/registry/entity/DNIC
OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName: Network DoD
OrgTechPhone: +1-844-347-2457
OrgTechEmail: disa.columbus.ns.mbx.hostmaster-dod-nic@mail.mil
OrgTechRef: https://rdap.arin.net/registry/entity/MIL-HSTMST-ARIN
OrgAbuseHandle: REGIS10-ARIN
OrgAbuseName: Registration
OrgAbusePhone: +1-844-347-2457
OrgAbuseEmail: disa.columbus.ns.mbx.arin-registrations@mail.mil
OrgAbuseRef: https://rdap.arin.net/registry/entity/REGIS10-ARIN
OrgTechHandle: REGIS10-ARIN
OrgTechName: Registration
OrgTechPhone: +1-844-347-2457
OrgTechEmail: disa.columbus.ns.mbx.arin-registrations@mail.mil
OrgTechRef: https://rdap.arin.net/registry/entity/REGIS10-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
Neat, one of the root DNS servers is owned by the US DoD. Information about the rest can be found below…
--------------------------------------------------------------------------------------
| IP | ORG |
|---------------|--------------------------------------------------------------------|
|202.12.27.33 | ORG-WA3-AP |
|199.7.83.42 | ICANN (ICANN) |
|193.0.14.129 | RIPE NCC Global Information Infrastructure Team |
|192.58.128.30 | VeriSign Global Registry Services (VGRS) |
|192.36.148.17 | RIPE Network Coordination Centre (RIPE) |
|198.97.190.53 | Headquarters, USAISC (HEADQU-3) |
|192.112.36.4 | DoD Network Information Center (DNIC) |
|192.5.5.241 | Internet Systems Consortium, Inc. (ISC-94-Z) |
|192.203.230.10 | National Aeronautics and Space Administration (NASA-Z) |
|199.7.91.13 | University of Maryland (UNIVER-262) |
|192.33.4.12 | PSINet, Inc. (PSI) |
|170.247.170.2 | Latin American and Caribbean IP address Regional Registry (LACNIC) |
|198.41.0.4 | VeriSign Infrastructure & Operations (VIO-2) |
--------------------------------------------------------------------------------------
Lets find out what is the proper name server for “com.”
$ dig "com." ns @192.112.36.4
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> com. ns @192.112.36.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25824
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e810e24ca692288b0100000067e6e15142d85497047490a9 (good)
;; QUESTION SECTION:
;com. IN NS
;; AUTHORITY SECTION:
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
;; ADDITIONAL SECTION:
m.gtld-servers.net. 172800 IN A 192.55.83.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
a.gtld-servers.net. 172800 IN A 192.5.6.30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
;; Query time: 280 msec
;; SERVER: 192.112.36.4#53(192.112.36.4) (UDP)
;; MSG SIZE rcvd: 856
Again, 13 IPv4 addresses and 13 IPv6 addresses. Who owns the COM servers?
$ whois 192.5.6.30
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
NetRange: 192.5.6.0 - 192.5.6.255
CIDR: 192.5.6.0/24
NetName: VGRSGTLD-1
NetHandle: NET-192-5-6-0-1
Parent: NET192 (NET-192-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: VeriSign Global Registry Services (VGRS)
RegDate: 2000-11-30
Updated: 2021-08-12
Ref: https://rdap.arin.net/registry/ip/192.5.6.0
OrgName: VeriSign Global Registry Services
OrgId: VGRS
Address: 12061 Bluemont Way
City: Reston
StateProv: VA
PostalCode: 20190
Country: US
RegDate: 2000-11-30
Updated: 2022-09-09
Ref: https://rdap.arin.net/registry/entity/VGRS
OrgAbuseHandle: NETWO480-ARIN
OrgAbuseName: Network Admin
OrgAbusePhone: +1-703-948-4300
OrgAbuseEmail: netadmin@verisign.com
OrgAbuseRef: https://rdap.arin.net/registry/entity/NETWO480-ARIN
OrgTechHandle: SEREM-ARIN
OrgTechName: Seremet, Ibrahim
OrgTechPhone: +1-703-948-3308
OrgTechEmail: iseremet@verisign.com
OrgTechRef: https://rdap.arin.net/registry/entity/SEREM-ARIN
OrgTechHandle: NETWO480-ARIN
OrgTechName: Network Admin
OrgTechPhone: +1-703-948-4300
OrgTechEmail: netadmin@verisign.com
OrgTechRef: https://rdap.arin.net/registry/entity/NETWO480-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
Repeating this for all the other addresses, we can see that they are all owned by Verisign.
Lets ask one of them about google’s name servers…
$ dig "google.com." ns @192.42.93.30
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> google.com. ns @192.42.93.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN NS
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com. 172800 IN A 216.239.38.10
;; Query time: 199 msec
;; SERVER: 192.42.93.30#53(192.42.93.30) (UDP)
;; MSG SIZE rcvd: 287
And who owns those servers?
$ whois 216.239.34.10
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
NetRange: 216.239.32.0 - 216.239.63.255
CIDR: 216.239.32.0/19
NetName: GOOGLE
NetHandle: NET-216-239-32-0-1
Parent: NET216 (NET-216-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOGL)
RegDate: 2000-11-22
Updated: 2012-02-24
Ref: https://rdap.arin.net/registry/ip/216.239.32.0
OrgName: Google LLC
OrgId: GOGL
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US
RegDate: 2000-03-30
Updated: 2019-10-31
Comment: Please note that the recommended way to file abuse complaints are located in the following links.
Comment:
Comment: To report abuse and illegal activity: https://www.google.com/contact/
Comment:
Comment: For legal requests: http://support.google.com/legal
Comment:
Comment: Regards,
Comment: The Google Team
Ref: https://rdap.arin.net/registry/entity/GOGL
OrgAbuseHandle: ABUSE5250-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-650-253-0000
OrgAbuseEmail: network-abuse@google.com
OrgAbuseRef: https://rdap.arin.net/registry/entity/ABUSE5250-ARIN
OrgTechHandle: ZG39-ARIN
OrgTechName: Google LLC
OrgTechPhone: +1-650-253-0000
OrgTechEmail: arin-contact@google.com
OrgTechRef: https://rdap.arin.net/registry/entity/ZG39-ARIN
RTechHandle: ZG39-ARIN
RTechName: Google LLC
RTechPhone: +1-650-253-0000
RTechEmail: arin-contact@google.com
RTechRef: https://rdap.arin.net/registry/entity/ZG39-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#
Unsurprisingly, those servers are owned by google.
# Understanding PTR Chain
We can do the same lookup procedure for PTR records as well. Lets take an arbitrary IP address 1.1.1.1 and look it up!
First, we lookup the NS value for in-addr.arpa.
$ dig ns in-addr.arpa.
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> ns in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17934
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;in-addr.arpa. IN NS
;; ANSWER SECTION:
in-addr.arpa. 3600 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 3600 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 3600 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 3600 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 3600 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 3600 IN NS f.in-addr-servers.arpa.
;; Query time: 316 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; MSG SIZE rcvd: 153
Which gives us some name servers to ask about the next portion 1.in-addr.arpa.
$ dig ns 1.in-addr.arpa. @a.in-addr-servers.arpa.
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> ns 1.in-addr.arpa. @a.in-addr-servers.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49948
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 86de02fba8f2cb930100000067f037d393b650ebb92d6007 (good)
;; QUESTION SECTION:
;1.in-addr.arpa. IN NS
;; AUTHORITY SECTION:
1.in-addr.arpa. 86400 IN NS ns1.apnic.net.
1.in-addr.arpa. 86400 IN NS ns3.lacnic.net.
1.in-addr.arpa. 86400 IN NS ns2.apnic.net.
1.in-addr.arpa. 86400 IN NS rirns.arin.net.
1.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net.
;; Query time: 280 msec
;; SERVER: 2620:37:e000::53#53(a.in-addr-servers.arpa.) (UDP)
;; MSG SIZE rcvd: 208
So on and so forth until we arrive at…
dig PTR 1.1.1.1.in-addr.arpa. @alec.ns.cloudflare.com
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> PTR 1.1.1.1.in-addr.arpa. @alec.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17779
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.1.1.1.in-addr.arpa. 1800 IN PTR one.one.one.one.
;; Query time: 511 msec
;; SERVER: 2606:4700:58::adf5:3b3b#53(alec.ns.cloudflare.com) (UDP)
;; MSG SIZE rcvd: 78
Our final value of one.one.one.one.
# Conclusion
Overall, dns is one of the critical services of the internet. I hope that this post has shed some light on the topic and you’ve taken something away from it.