TTR Networks

Beginner · Linux Network Connectivity · section 7 of 11

Names in traceroute: reverse DNS

✓ Lab-tested 17 October 2026 on Debian 12

Without -n, traceroute prints a name next to each hop's address. Those names don't come from the routers. For every address, traceroute asks DNS a reverse question: what name belongs to this IP? That's a PTR record, and whether one exists is entirely up to whoever holds the address. That's why some hops have names and others show only a number.

How an address gets a name

Reverse DNS reuses the normal DNS hierarchy by writing the address backwards under a special domain. The PTR for 192.0.2.1 lives at 1.2.0.192.in-addr.arpa (IPv6 uses ip6.arpa, one hex digit per label). Writing it backwards puts the most significant part first in the hierarchy, so each organisation that hands out addresses controls a suffix:

  1. IANA delegates in-addr.arpa and its /8 zones to the Regional Internet Registries, mirroring who allocated which address space.
  2. When an organisation receives address space, it registers its nameservers with the RIR. In RIPE and APNIC that's a domain: object in the registry database, much like the RPSL objects in the routing-security track. ARIN does it through its portal, attached to the network registration. The RIR then publishes NS records delegating, say, 100.51.198.in-addr.arpa to the holder.
  3. The holder runs those nameservers and creates a PTR record per address, usually generated automatically from the router configuration.

Delegation happens on octet boundaries: a /24 or /16 in IPv4, and a nibble (4 bits) in IPv6. Customers with smaller blocks usually ask their ISP to set PTRs for them; RFC 2317 describes a workaround for delegating smaller blocks.

Reading router names

Operators encode useful facts in their router names: the interface (with dashes for slashes), the router and its role, and the site, often an airport code (syd, lax) or a telecom building code. xe-0-0-1.cr1.syd2.lab.example reads as "interface xe-0/0/1 on core router 1 at Sydney site 2". Network engineers use these names to spot where a path really goes, for example a "Sydney to Sydney" path that detours through Los Angeles.

Don't trust names blindly

A PTR record is just a claim by whoever controls the reverse zone. It isn't verified, it's often stale, and it can be deliberately misleading. A name is only trustworthy if it forward-confirms: looking up the name returns the same address (FCrDNS). Mail servers require this of each other. And because every hop's name is a DNS lookup, a slow or broken resolver makes traceroute look slow — one more reason to use -n when troubleshooting.

Interactive: Reverse DNS, decoded Pick an address to see the reverse name traceroute looks up and who controls each level. 8.8.8.8 shows what answered at each step of the real lookup below. Then switch tabs to decode router names. (needs JavaScript)

Following the delegation for 8.8.8.8 (real output)
user@mac ~ % dig +trace +nodnssec -x 8.8.8.8

; <<>> DiG 9.10.6 <<>> +trace +nodnssec -x 8.8.8.8
;; global options: +cmd
.			73642	IN	NS	c.root-servers.net.
.			73642	IN	NS	e.root-servers.net.
.			73642	IN	NS	j.root-servers.net.
.			73642	IN	NS	b.root-servers.net.
.			73642	IN	NS	i.root-servers.net.
.			73642	IN	NS	a.root-servers.net.
.			73642	IN	NS	k.root-servers.net.
.			73642	IN	NS	h.root-servers.net.
.			73642	IN	NS	l.root-servers.net.
.			73642	IN	NS	m.root-servers.net.
.			73642	IN	NS	f.root-servers.net.
.			73642	IN	NS	d.root-servers.net.
.			73642	IN	NS	g.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 5 ms

in-addr.arpa.		172800	IN	NS	a.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	b.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	c.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	d.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	e.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	f.in-addr-servers.arpa.
;; Received 425 bytes from 199.7.91.13#53(d.root-servers.net) in 17 ms

8.in-addr.arpa.		86400	IN	NS	u.arin.net.
8.in-addr.arpa.		86400	IN	NS	y.arin.net.
8.in-addr.arpa.		86400	IN	NS	r.arin.net.
8.in-addr.arpa.		86400	IN	NS	z.arin.net.
8.in-addr.arpa.		86400	IN	NS	arin.authdns.ripe.net.
8.in-addr.arpa.		86400	IN	NS	x.arin.net.
;; Received 186 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 202 ms

8.8.8.in-addr.arpa.	86400	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	86400	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	86400	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	86400	IN	NS	ns3.google.com.
;; Received 131 bytes from 192.82.134.30#53(y.arin.net) in 138 ms

8.8.8.8.in-addr.arpa.	86400	IN	PTR	dns.google.
;; Received 73 bytes from 216.239.32.10#53(ns1.google.com) in 187 ms
  • Line 1: +trace makes dig do the walk itself, starting from the root, instead of asking a resolver. +nodnssec hides signatures to keep it readable.
  • Lines 5–18: Step 0: the root servers' names, fetched from the local resolver (its address replaced here).
  • Lines 20–26: A root server (d.root-servers.net) refers the query to the servers for in-addr.arpa.
  • Lines 28–34: Those refer 8.in-addr.arpa to ARIN, the registry that manages 8.0.0.0/8, plus one RIPE NCC server as a secondary.
  • Lines 36–40: ARIN refers 8.8.8.in-addr.arpa to Google's own nameservers. This delegation exists because Google registered those nameservers with ARIN.
  • Lines 42–43: Google's server answers with the PTR record: dns.google.
Forward-confirming the name (real output)
user@mac ~ % dig +short -x 8.8.8.8
dns.google.
user@mac ~ % dig +short dns.google A
8.8.8.8
8.8.4.4
  • Lines 1–2: Reverse: 8.8.8.8 → dns.google.
  • Lines 3–5: Forward: dns.google → includes 8.8.8.8. The name and the address agree, so the name is confirmed (FCrDNS).
Registering the reverse zone with the RIR (example registry object)
domain:         100.51.198.in-addr.arpa
descr:          Reverse zone for 198.51.100.0/24
admin-c:        EX123-RIPE
tech-c:         EX123-RIPE
zone-c:         EX123-RIPE
nserver:        ns1.isp.example
nserver:        ns2.isp.example
ds-rdata:       12345 13 2 9F86D081884C7D659A2FEAA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08
mnt-by:         EXAMPLE-MNT
source:         RIPE
  • Line 1: The zone being delegated: 198.51.100.0/24 written backwards. The holder can only create this inside address space registered to them.
  • Lines 3–5: Contacts, including zone-c, the person responsible for the zone's contents.
  • Lines 6–7: The holder's nameservers. The RIR checks they answer for the zone, then publishes NS records delegating it.
  • Line 8: Optional DNSSEC: a DS record so resolvers can validate the PTRs. The values here are examples.
Creating PTR records in the lab
# On the lab router: dnsmasq answers forward AND reverse queries for the lab.
dnsmasq --no-resolv --no-hosts --bind-interfaces --listen-address=192.0.2.1 \
  --local=/lab.example/ --local=/2.0.192.in-addr.arpa/ --local=/100.51.198.in-addr.arpa/ \
  --address=/server.lab.example/198.51.100.20 \
  --host-record=xe-0-0-1.cr1.syd2.lab.example,192.0.2.1 \
  --ptr-record=20.100.51.198.in-addr.arpa,old-web.lab.example
  • Line 3: Answer authoritatively for the two reverse zones, so unknown addresses get NXDOMAIN instead of being forwarded.
  • Line 5: host-record creates both directions: A and PTR. That's what makes a name forward-confirm.
  • Line 6: ptr-record creates only the reverse record: a leftover name for a server that's since been renamed.
Names in traceroute, and checking them (real output)
root@client:~# traceroute 198.51.100.20
traceroute to 198.51.100.20 (198.51.100.20), 30 hops max, 60 byte packets
 1  xe-0-0-1.cr1.syd2.lab.example (192.0.2.1)  0.353 ms  0.293 ms  0.280 ms
 2  old-web.lab.example (198.51.100.20)  0.269 ms  0.221 ms  0.208 ms
root@client:~# dig -x 192.0.2.1 +noall +answer
1.2.0.192.in-addr.arpa.	0	IN	PTR	xe-0-0-1.cr1.syd2.lab.example.
root@client:~# dig +short -x 192.0.2.1
xe-0-0-1.cr1.syd2.lab.example.
root@client:~# dig +short xe-0-0-1.cr1.syd2.lab.example
192.0.2.1
root@client:~# dig +short -x 198.51.100.20
old-web.lab.example.
root@client:~# dig +short old-web.lab.example
root@client:~# dig -x 192.0.2.99 | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5302
  • Lines 1–4: Without -n, every hop gets a PTR lookup and the name is printed with the address in brackets.
  • Lines 5–6: The lookup traceroute did for hop 1, made visible.
  • Lines 7–10: The router's name forward-confirms: name → 192.0.2.1.
  • Lines 11–13: The server's PTR says old-web, but that name doesn't resolve forward. A stale record: the server is really server.lab.example. Traceroute printed the stale name without complaint.
  • Lines 14–15: No PTR at all: NXDOMAIN. Traceroute would print just the address.

Check your understanding

A traceroute hop shows be10.cr2.lax1.isp.example but the RTT is only 3 ms from Sydney. What's the most likely explanation?

  • Packets really did reach Los Angeles in 3 ms
  • The PTR name is wrong or stale: names are just claims by the address holder
  • The router answered with a different interface address
  • DNS caching made the reply faster

Check your understanding

Your company holds 198.51.100.0/24, but dig -x 198.51.100.25 returns NXDOMAIN at the RIR level. What's missing?

  • A PTR record on your nameservers
  • A reverse delegation: a domain object (or the ARIN equivalent) for 100.51.198.in-addr.arpa naming your nameservers
  • An A record for your website
  • A route object in the IRR