From what I understood when my computer performs a DNS request it does the following:
Firstly my computer send a DNS request to its default dns server (my ISP DNS in my case).
Then my ISP DNS server send a request to a "root node DNS server".
My question is in that last point.
How does the ISP DNS server contact te root node (with an IP ? (I heard that DNS root node IPs where secret (in order to avoid attacks / spamming))).
Which port is used by the root node DNS
Can I contact directly from my computer the root DNS ? (if yes how ?)
Thank you very much !
Each recursive nameserver in the world ships with a preconfigured root zone with the list of root nameservers and their IPv4+IPv6 addresses.
By a process called "priming" on start, each recursive nameserver will connect one of these to query for the current list, so that it can update its list of root servers.
All of that is not hidden in any way because otherwise the DNS does not work.
Every nameserver (recursive or authoritative) uses port 53, for both UDP and TCP queries.
You can of course contact directly the root nameservers but based on your questions I believe you have a misconception on what purpose this may have.
The DNS is a tree, if you contact a root nameserver it will only be able to reply with data about the level just below it, that is the list of TLDs, and you will not get data there about domains further down the tree.
Some examples:
Getting list of current root nameservers
$ dig . NS
; <<>> DiG 9.12.0 <<>> . NS
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62572
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c0ea66cf097962ab
;; QUESTION SECTION:
;. IN NS
;; QUERY SIZE: 40
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62572
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 264162 IN NS a.root-servers.net.
. 264162 IN NS d.root-servers.net.
. 264162 IN NS m.root-servers.net.
. 264162 IN NS j.root-servers.net.
. 264162 IN NS e.root-servers.net.
. 264162 IN NS f.root-servers.net.
. 264162 IN NS l.root-servers.net.
. 264162 IN NS k.root-servers.net.
. 264162 IN NS g.root-servers.net.
. 264162 IN NS h.root-servers.net.
. 264162 IN NS b.root-servers.net.
. 264162 IN NS i.root-servers.net.
. 264162 IN NS c.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 600270 IN A 198.41.0.4
a.root-servers.net. 168267 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 600268 IN A 199.9.14.201
b.root-servers.net. 168267 IN AAAA 2001:500:200::b
c.root-servers.net. 600270 IN A 192.33.4.12
c.root-servers.net. 168267 IN AAAA 2001:500:2::c
d.root-servers.net. 600269 IN A 199.7.91.13
d.root-servers.net. 168267 IN AAAA 2001:500:2d::d
e.root-servers.net. 600268 IN A 192.203.230.10
e.root-servers.net. 168267 IN AAAA 2001:500:a8::e
f.root-servers.net. 600268 IN A 192.5.5.241
f.root-servers.net. 168267 IN AAAA 2001:500:2f::f
g.root-servers.net. 600268 IN A 192.112.36.4
g.root-servers.net. 168267 IN AAAA 2001:500:12::d0d
h.root-servers.net. 600270 IN A 198.97.190.53
h.root-servers.net. 168267 IN AAAA 2001:500:1::53
i.root-servers.net. 600270 IN A 192.36.148.17
i.root-servers.net. 168267 IN AAAA 2001:7fe::53
j.root-servers.net. 600268 IN A 192.58.128.30
j.root-servers.net. 168267 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 600268 IN A 193.0.14.129
k.root-servers.net. 168267 IN AAAA 2001:7fd::1
l.root-servers.net. 600268 IN A 199.7.83.42
l.root-servers.net. 168267 IN AAAA 2001:500:9f::42
m.root-servers.net. 600268 IN A 202.12.27.33
m.root-servers.net. 168267 IN AAAA 2001:dc3::35
;; Query time: 1 msec
;; SERVER: 192.168.10.229#53(192.168.10.229)
;; WHEN: Mon Oct 29 10:19:08 EST 2018
;; MSG SIZE rcvd: 811
Asking a root nameserver about data for a TLD (yes, red is a TLD)
$ dig #g.root-servers.net red. NS +nocookie
; <<>> DiG 9.12.0 <<>> #g.root-servers.net red. NS +nocookie
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18270
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;red. IN NS
;; QUERY SIZE: 32
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18270
;; 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:
;red. IN NS
;; AUTHORITY SECTION:
red. 172800 IN NS b0.nic.red.
red. 172800 IN NS c0.nic.red.
red. 172800 IN NS a2.nic.red.
red. 172800 IN NS a0.nic.red.
;; ADDITIONAL SECTION:
a0.nic.red. 172800 IN A 65.22.36.25
a2.nic.red. 172800 IN A 65.22.39.25
b0.nic.red. 172800 IN A 65.22.37.25
c0.nic.red. 172800 IN A 65.22.38.25
a0.nic.red. 172800 IN AAAA 2a01:8840:26::25
a2.nic.red. 172800 IN AAAA 2a01:8840:29::25
b0.nic.red. 172800 IN AAAA 2a01:8840:27::25
c0.nic.red. 172800 IN AAAA 2a01:8840:28::25
;; Query time: 104 msec
;; SERVER: 192.112.36.4#53(192.112.36.4)
;; WHEN: Mon Oct 29 10:20:35 EST 2018
;; MSG SIZE rcvd: 280
Asking a root nameserver for anything else down the tree (no direct reply as expected, just data to contact other nameservers for further recursive queries)
$ dig #g.root-servers.net www.stackoverflow.com. NS +nocookie
; <<>> DiG 9.12.0 <<>> #g.root-servers.net www.stackoverflow.com. NS +nocookie
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8649
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.stackoverflow.com. IN NS
;; QUERY SIZE: 50
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8649
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.stackoverflow.com. IN NS
;; AUTHORITY SECTION:
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
;; Query time: 105 msec
;; SERVER: 192.112.36.4#53(192.112.36.4)
;; WHEN: Mon Oct 29 10:21:50 EST 2018
;; MSG SIZE rcvd: 846
Related
I had purchased the domain "webcafe.tech" from Hostinger and added A record to GCP VM for Wordpress hosting. Earlier it was working fine. I added cloudflare for better security. At that time the site was working properly. But after few days I started getting error : "webcafe.tech’s server IP address could not be found.". I checked with support team. They updated that DNS propogation was stuck so they have reset it. I waited for 48hrs but for my location it is still not working.
I checked in intoDNS.com and found that it have propagated properly to all regions. But still from my location it is not working, so I tried different location, like mobile or public wifi. But no luck.
Then I tried tor and it is working properly there. Even support person told it is working fine from his location.
I tried using dig, here is the output:
C:\Program Files\ISC BIND 9\bin>dig webcafe.tech +short
C:\Program Files\ISC BIND 9\bin>dig webcafe.tech
; <<>> DiG 9.17.10 <<>> webcafe.tech
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26865
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;webcafe.tech. IN A
;; Query time: 2032 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu Mar 04 02:37:18 India Standard Time 2021
;; MSG SIZE rcvd: 41
C:\Program Files\ISC BIND 9\bin>dig webcafe.tech +trace
; <<>> DiG 9.17.10 <<>> webcafe.tech +trace
;; global options: +cmd
. 480854 IN NS k.root-servers.net.
. 480854 IN NS l.root-servers.net.
. 480854 IN NS m.root-servers.net.
. 480854 IN NS a.root-servers.net.
. 480854 IN NS b.root-servers.net.
. 480854 IN NS c.root-servers.net.
. 480854 IN NS d.root-servers.net.
. 480854 IN NS e.root-servers.net.
. 480854 IN NS f.root-servers.net.
. 480854 IN NS g.root-servers.net.
. 480854 IN NS h.root-servers.net.
. 480854 IN NS i.root-servers.net.
. 480854 IN NS j.root-servers.net.
. 480854 IN RRSIG NS 8 0 518400 20210315210000 20210302200000 42351 . ads06V0AhKOpuJ6zWLp1gY6wKDCULWzG04I0GBEH6sPJPedI77SVsJ83 bAvoPk4xTDOfNOP/Zjxc8aO2uThv+32YD7ceHvmxUg5BFOWTComjLfXI CXfPETCn0tMSS82QSPPXyBMsv2XLYas21RbReUYjtZoPTk2olimEDJ5q Bxyk7sBDQfsoIJ6F/F0L5BYpAhXJw4EV7/BJaOzzc+fPLLlQK4I5W1j1 12HWtqhg+H1ZVbv2SH2mm2eVVUAJg6sFC/cfiAR9HVWwCf4D4yFgm6+8 Uq+087Mvj4dhLS5tCieniBIwAXVBpF1bUVunSgmfoJ2oBEIvYl9usqWa 4zHe6g==
;; Received 525 bytes from 192.168.1.1#53(192.168.1.1) in 45 ms
tech. 172800 IN NS b.nic.tech.
tech. 172800 IN NS e.nic.tech.
tech. 172800 IN NS f.nic.tech.
tech. 172800 IN NS a.nic.tech.
tech. 86400 IN DS 50095 8 1 82F72F2462DEE25B99DA2470535AD0A7D131F1EB
tech. 86400 IN DS 50095 8 2 83F40D01141484D8F07305E5D2E44AC5663149054C598D6E9D993C66 1686C6EE
tech. 86400 IN RRSIG DS 8 1 86400 20210316170000 20210303160000 42351 . cAsLi5OXC4/bT/N/x5nu9LWQJIXnSbFkpA8/8V7FxWOYEuNYfJYjVO1Z P8BWT7IB3BKlMaAmGZxQEuQi6Q7plP1n68p+8sDDFdHDzqiy0T7KyZm4 6UScDk3fT3pmGS3nxRl61X67uEaWNy4fmukgkX62xsAdX2Yiq5YubsUq UEQDUpcKBQegnlgr4Hmpm+jhilHLe0mjfhkMXgQaT6mY9HnV8ZUrc1mY Ad9zm/tvj9gBUuEQQqJPTocrftSB3NL9UAJZVf8Ui8oxYdTXR7U0OLzM qfcyaJeSfNMR359kruWgnlcVmXoU+9SFExgCFnv5ahkQrLjAePZ8cVgV PVy+Ow==
;; Received 688 bytes from 192.36.148.17#53(i.root-servers.net) in 196 ms
webcafe.tech. 3600 IN NS ns1.dns-parking.com.
webcafe.tech. 3600 IN NS ns2.dns-parking.com.
webcafe.tech. 3600 IN DS 2371 8 2 55F22368BD05B6405E96C3E14D7A4FB138CCBB970D3FB44AEB911BD6 C7EC3104
webcafe.tech. 3600 IN RRSIG DS 8 2 3600 20210319200140 20210217140833 21876 tech. eDzK56jI7vgFFD3D+kFyMgcBMDemav4/m47KqAQKj48TkMP6QEYdbIV5 3RzfQ/F6yWmuJ6azb1EyPWjLF4gOOymDjBaaq40jewfL+3HQgSmrs8YM 6G8FSE+IwWpewOj653uevU/gCTIacVp38BFgPNUMPT1RRXaqQjIyRZ/d b7A=
;; Received 304 bytes from 212.18.248.60#53(e.nic.tech) in 179 ms
webcafe.tech. 14400 IN A 35.239.116.255
;; Received 57 bytes from 162.159.24.201#53(ns1.dns-parking.com) in 71 ms
Dig trace is showing result but dig short and nslookup is not working.
Can anyone help me out, how to fix this issue?
Edit:
Added GCP server DNS zone and updated Name servers, but still not working. Here are my records:
GCP DNS Zone Record
Hostinger DNS record
c:\Program Files\ISC BIND 9\bin>dig webcafe.tech
; <<>> DiG 9.17.10 <<>> webcafe.tech
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17639
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;webcafe.tech. IN A
;; Query time: 1512 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu Mar 04 15:30:12 India Standard Time 2021
;; MSG SIZE rcvd: 41
c:\Program Files\ISC BIND 9\bin>dig webcafe.tech +short
c:\Program Files\ISC BIND 9\bin>dig webcafe.tech +trace
; <<>> DiG 9.17.10 <<>> webcafe.tech +trace
;; global options: +cmd
. 422973 IN NS c.root-servers.net.
. 422973 IN NS d.root-servers.net.
. 422973 IN NS e.root-servers.net.
. 422973 IN NS f.root-servers.net.
. 422973 IN NS g.root-servers.net.
. 422973 IN NS h.root-servers.net.
. 422973 IN NS i.root-servers.net.
. 422973 IN NS j.root-servers.net.
. 422973 IN NS k.root-servers.net.
. 422973 IN NS l.root-servers.net.
. 422973 IN NS m.root-servers.net.
. 422973 IN NS a.root-servers.net.
. 422973 IN NS b.root-servers.net.
. 422973 IN RRSIG NS 8 0 518400 20210315210000 20210302200000 42351 . ads06V0AhKOpuJ6zWLp1gY6wKDCULWzG04I0GBEH6sPJPedI77SVsJ83 bAvoPk4xTDOfNOP/Zjxc8aO2uThv+32YD7ceHvmxUg5BFOWTComjLfXI CXfPETCn0tMSS82QSPPXyBMsv2XLYas21RbReUYjtZoPTk2olimEDJ5q Bxyk7sBDQfsoIJ6F/F0L5BYpAhXJw4EV7/BJaOzzc+fPLLlQK4I5W1j1 12HWtqhg+H1ZVbv2SH2mm2eVVUAJg6sFC/cfiAR9HVWwCf4D4yFgm6+8 Uq+087Mvj4dhLS5tCieniBIwAXVBpF1bUVunSgmfoJ2oBEIvYl9usqWa 4zHe6g==
;; Received 525 bytes from 192.168.1.1#53(192.168.1.1) in 85 ms
tech. 172800 IN NS a.nic.tech.
tech. 172800 IN NS b.nic.tech.
tech. 172800 IN NS e.nic.tech.
tech. 172800 IN NS f.nic.tech.
tech. 86400 IN DS 50095 8 1 82F72F2462DEE25B99DA2470535AD0A7D131F1EB
tech. 86400 IN DS 50095 8 2 83F40D01141484D8F07305E5D2E44AC5663149054C598D6E9D993C66 1686C6EE
tech. 86400 IN RRSIG DS 8 1 86400 20210317050000 20210304040000 42351 . Z8gH+XbVqLv6fagaF75qhHai+D+XVRfWkFECeZ2MS+SMBq47f91Fr/Ez +6wqNUozI4m2GbOpZ/uPhChz6ekikdlXIGTEQnq2aMVUsnY90xXSd4Vr j8fYHqnEpTDn1Z8GxZeBUneDDcygn7EIks2uaXfvHYsh4zhrucpAPUZW +JGLGtnKegTGCwmHpEle9Ho5RaXqJOMO1CO6Rj+5cWoHHMUjn3MLMwtR LiEL83l5mAqcj3Rwb7utj7SfXWTf5NbioLHONkkTv9cKvHDgDDPcmHHc CimyHoYbnL4/lsTw6pnZekWNntXWuGrK7GOW1WpOQysz9onIdqVdT+o7 8LMu7w==
;; Received 656 bytes from 198.97.190.53#53(h.root-servers.net) in 216 ms
webcafe.tech. 3600 IN NS ns-cloud-c1.googledomains.com.
webcafe.tech. 3600 IN NS ns-cloud-c2.googledomains.com.
webcafe.tech. 3600 IN NS ns-cloud-c3.googledomains.com.
webcafe.tech. 3600 IN NS ns-cloud-c4.googledomains.com.
webcafe.tech. 3600 IN DS 2371 8 2 55F22368BD05B6405E96C3E14D7A4FB138CCBB970D3FB44AEB911BD6 C7EC3104
webcafe.tech. 3600 IN RRSIG DS 8 2 3600 20210319200140 20210217140833 21876 tech. eDzK56jI7vgFFD3D+kFyMgcBMDemav4/m47KqAQKj48TkMP6QEYdbIV5 3RzfQ/F6yWmuJ6azb1EyPWjLF4gOOymDjBaaq40jewfL+3HQgSmrs8YM 6G8FSE+IwWpewOj653uevU/gCTIacVp38BFgPNUMPT1RRXaqQjIyRZ/d b7A=
;; Received 374 bytes from 194.169.218.60#53(a.nic.tech) in 181 ms
webcafe.tech. 300 IN A 35.239.116.255
;; Received 57 bytes from 216.239.38.108#53(ns-cloud-c4.googledomains.com) in 103 ms
Currently for webcafe.tech resolves only with nameservers ns-cloud-c[1-3].googledomains.com and ns[1-2].dns-parking.com. Al other servers that I tried return SERVFAIL what means that the server isn't able to answer properly for some reason.
Let's take a look at SOA record
>host -t soa webcafe.tech NS-CLOUD-C2.GOOGLEDOMAINS.COM
Using domain server:
Name: NS-CLOUD-C2.GOOGLEDOMAINS.COM
Address: 216.239.34.108#53
Aliases:
webcafe.tech has SOA record ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
> host -t soa webcafe.tech ns1.dns-parking.com
Using domain server:
Name: ns1.dns-parking.com
Address: 162.159.24.201#53
Aliases:
webcafe.tech has SOA record ns1.dns-parking.com. dns.hostinger.com. 2021030401 10000 2400 604800 3600
dns-parking.com still consider their servers as masters for your domain.
Also serial field in google servers is 21600 and for dns-parking.com it is 2021030401.
I'd recommend to change serial in googledomains.com to some number bigger than 2021030401. If problem persists, contact hostinger support.
I'm facing with this strange DNS issue on one of the CentOS boxes, in which the authoritative NS returns outdated records, which results in failure in the resolution.
The domain I'm trying to resolve is chengyu.ga.
Let's call the problematic CentOS box A and a normal CentOS box B.
Here is the dig trace when running on B, which returns correct answers:
$ dig chengyu.ga +trace +additional
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> chengyu.ga +trace +additional
;; global options: +cmd
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
;; Received 239 bytes from 172.31.0.2#53(172.31.0.2) in 0 ms
ga. 172800 IN NS a.ns.ga.
ga. 172800 IN NS b.ns.ga.
ga. 172800 IN NS c.ns.ga.
ga. 172800 IN NS d.ns.ga.
ga. 86400 IN NSEC gal. NS RRSIG NSEC
ga. 86400 IN RRSIG NSEC 8 1 86400 20200327050000 20200314040000 33853 . AUOV4PSeXQZ+PpcrnlNQIxmP1vnMcTe77+bQop06CAx1Q4oPMm+ujQY3 AMnp+ex8onrv
1VpJgaENd4gyf6bgOkYCNcy2hY/DpXyQ1UY/TLBZigkO Q+xtDwVcXnw/BvP+KpDeEj0KcMSh8qqRRkhVH77KPOEVgmQzyuUZ12GH sc9mmcwxT/Ugl+qG60ib7C3jFi8VYGsMNUk+p2RfDw5MPRPfFGZxEyNH XdmW7ABYm62
QdI1oAVPND9UjVkV/aw59Yq55cwrFqcQt+2aM10yrssII nx0o5NX3zqhMt2gkwOnZrGBgIxD1QdJXMZtT7aPk3UgaAvFnOgOpg81Y HtdTFg==
a.ns.ga. 172800 IN A 185.21.168.49
a.ns.ga. 172800 IN AAAA 2a04:1b00:c::1
b.ns.ga. 172800 IN A 185.21.169.49
b.ns.ga. 172800 IN AAAA 2a04:1b00:d::1
c.ns.ga. 172800 IN A 185.21.170.49
c.ns.ga. 172800 IN AAAA 2a04:1b00:e::1
d.ns.ga. 172800 IN A 185.21.171.49
d.ns.ga. 172800 IN AAAA 2a04:1b00:f::1
;; Received 594 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 3 ms
chengyu.ga. 300 IN NS ns-1096.awsdns-09.org.
chengyu.ga. 300 IN NS ns-58.awsdns-07.com.
chengyu.ga. 300 IN NS ns-720.awsdns-26.net.
chengyu.ga. 300 IN NS ns-1829.awsdns-36.co.uk.
;; Received 178 bytes from 185.21.171.49#53(d.ns.ga) in 186 ms
chengyu.ga. 60 IN A 3.112.158.242
chengyu.ga. 60 IN A 52.196.4.107
chengyu.ga. 60 IN A 13.114.167.91
chengyu.ga. 172800 IN NS ns-1096.awsdns-09.org.
chengyu.ga. 172800 IN NS ns-1829.awsdns-36.co.uk.
chengyu.ga. 172800 IN NS ns-58.awsdns-07.com.
chengyu.ga. 172800 IN NS ns-720.awsdns-26.net.
;; Received 226 bytes from 205.251.199.37#53(ns-1829.awsdns-36.co.uk) in 3 ms
And results from A:
$ dig chengyu.ga +trace +additional
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> chengyu.ga +trace +additional
;; global options: +cmd
. 259199 IN NS a.root-servers.net.
. 259199 IN NS b.root-servers.net.
. 259199 IN NS c.root-servers.net.
. 259199 IN NS d.root-servers.net.
. 259199 IN NS e.root-servers.net.
. 259199 IN NS f.root-servers.net.
. 259199 IN NS g.root-servers.net.
. 259199 IN NS h.root-servers.net.
. 259199 IN NS i.root-servers.net.
. 259199 IN NS j.root-servers.net.
. 259199 IN NS k.root-servers.net.
. 259199 IN NS l.root-servers.net.
. 259199 IN NS m.root-servers.net.
. 259199 IN RRSIG NS 8 0 518400 20200326050000 20200313040000 33853 . Qm1Ie0FEwyqy+PCVypAz7PuwJ4aFaQAjU2om+IRPQb/eQ2xjAwDm0YnW vws6lzDe5KKTkQYmSYmPyJ+ccoCk6zqvVVFzMjNQk5mgIpLdxvxLibkk 0hW5MFtY4fdFKmTS14RuqfEXVkEaYIph/Hvyh7Mw/5hKSttwMbJTELfx 8rBEQwVVFYcdazc2oko0UvnBSlnoYbpvlVR7QcrhJ7fAEQfzyy9SsR0Z jWn2G+OdwSfJgN1f7BXftC055yEnCWfG+qJNWrt+QofNolgQTbQDOY3t 3m9ITkBJvvPSUKH7mIIXHYMM3wbO6PenkY9VaPTYW+XkAxJvR+/r+UvE iEpSQw==
;; Received 525 bytes from 169.254.169.254#53(169.254.169.254) in 2 ms
ga. 172800 IN NS a.ns.ga.
ga. 172800 IN NS b.ns.ga.
ga. 172800 IN NS c.ns.ga.
ga. 172800 IN NS d.ns.ga.
ga. 86400 IN NSEC gal. NS RRSIG NSEC
ga. 86400 IN RRSIG NSEC 8 1 86400 20200327050000 20200314040000 33853 . AUOV4PSeXQZ+PpcrnlNQIxmP1vnMcTe77+bQop06CAx1Q4oPMm+ujQY3 AMnp+ex8onrv1VpJgaENd4gyf6bgOkYCNcy2hY/DpXyQ1UY/TLBZigkO Q+xtDwVcXnw/BvP+KpDeEj0KcMSh8qqRRkhVH77KPOEVgmQzyuUZ12GH sc9mmcwxT/Ugl+qG60ib7C3jFi8VYGsMNUk+p2RfDw5MPRPfFGZxEyNH XdmW7ABYm62QdI1oAVPND9UjVkV/aw59Yq55cwrFqcQt+2aM10yrssII nx0o5NX3zqhMt2gkwOnZrGBgIxD1QdJXMZtT7aPk3UgaAvFnOgOpg81Y HtdTFg==
a.ns.ga. 172800 IN A 185.21.168.49
b.ns.ga. 172800 IN A 185.21.169.49
c.ns.ga. 172800 IN A 185.21.170.49
d.ns.ga. 172800 IN A 185.21.171.49
a.ns.ga. 172800 IN AAAA 2a04:1b00:c::1
b.ns.ga. 172800 IN AAAA 2a04:1b00:d::1
c.ns.ga. 172800 IN AAAA 2a04:1b00:e::1
d.ns.ga. 172800 IN AAAA 2a04:1b00:f::1
;; Received 594 bytes from 198.41.0.4#53(a.root-servers.net) in 2 ms
chengyu.ga. 300 IN NS ns01.freenom.com.
chengyu.ga. 300 IN NS ns02.freenom.com.
chengyu.ga. 300 IN NS ns03.freenom.com.
chengyu.ga. 300 IN NS ns04.freenom.com.
;; Received 126 bytes from 185.21.168.49#53(a.ns.ga) in 2 ms
;; connection timed out; no servers could be reached
[guanshan#instance-2 ~]$ dig #185.21.171.49 chengyu.ga +trace +additional
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> #185.21.171.49 chengyu.ga +trace +additional
; (1 server found)
;; global options: +cmd
;; Received 28 bytes from 185.21.171.49#53(185.21.171.49) in 2 ms
FYI, the .freenom.com. NS servers have been changed to awsdns server a couple of days back. As you can see, the results returned by a.ns.ga are outdated.
My question is, what could cause this kind of behavior?
I have a domain (xanderflood.com) whose DNS is manged by Route 53. I'd like to delegate DNS for test.xanderflood.com to a server that'll be located at ns.test.xanderflood.com, so I added two records:
test.xanderflood.com IN NS ns.test.xanderflood.com
ns.test.xanderflood.com IN A 198.51.100.234
When I run dig +trace #75.75.75.75 media.test.xanderflood.com, I get
; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> +trace #75.75.75.75
media.test.xanderflood.com
; (1 server found)
;; global options: +cmd
. 503150 IN NS k.root-servers.net.
. 503150 IN NS l.root-servers.net.
. 503150 IN NS m.root-servers.net.
. 503150 IN NS a.root-servers.net.
. 503150 IN NS b.root-servers.net.
. 503150 IN NS c.root-servers.net.
. 503150 IN NS d.root-servers.net.
. 503150 IN NS e.root-servers.net.
. 503150 IN NS f.root-servers.net.
. 503150 IN NS g.root-servers.net.
. 503150 IN NS h.root-servers.net.
. 503150 IN NS i.root-servers.net.
. 503150 IN NS j.root-servers.net.
. 503150 IN RRSIG NS 8 0 518400 20190704170000 20190621160000 25266 . D5+HDC+b5kZ625Ac27BUxuBSBTATMWEGyjPXTJIR1WaWkb3uGBhNYV5G CC/aFJtwJZ0M5ki9mWfDMBr2TTr4ij9KViXbr7PDVDLHnqixT864P+8t KmHPL1uYIb94DkJza8gTMcJZoQlFEj+gEl2+qPBRc5oZbl4GkVva+La4 T/64g96mORdS8vZGn9aQSCZnPg8Ckt6sTIaELWLAnI3zTFrosg+zrG8D zVJFmFy55SmleFq6Gzs3BMk1DIs8FqrVjS5PPVVIGsjAMhLMeS0Sclps AFf8kjEMzXoREz4DeNYWgmf2nE3HUXSxd/XR7VAlzJmOUt8Suz0YkDr3 OGS+Ig==
;; Received 1041 bytes from 75.75.75.75#53(75.75.75.75) in 12 ms
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20190704170000 20190621160000 25266 . lc916tqVraGg10FCUk6/B5E0xeEbP4c5rnt3bPICTdHmSHgAZ/SpA8MF pIO426+YZ12p/lozYA2nUo6B7lVrjinglyNAnTBrVxYPtiC078gPU1Bq g8gEG6OZHoe/+UdYfvVtblW/ioSExKeyc9/C6KYfzZuD++T05/izeHov iiE+4ViTmaFaDgI+xSpqttRJT/nYRpn1tN9/35MV/rhXDhEGIUdLM98e wscQUzDbfkifK6NKb9Z6Vp689y2N7WV9dJKcDeNqcoRrMrWW9ioWOLqE Kxhv4O6AzL9clubwuzi+ufirwk6euOD8n6q6u51bcRhK8PdgUs2xy2Ms uVcCMQ==
;; Received 1214 bytes from 199.9.14.201#53(b.root-servers.net) in 60 ms
xanderflood.com. 172800 IN NS ns-426.awsdns-53.com.
xanderflood.com. 172800 IN NS ns-823.awsdns-38.net.
xanderflood.com. 172800 IN NS ns-1657.awsdns-15.co.uk.
xanderflood.com. 172800 IN NS ns-1471.awsdns-55.org.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190628044430 20190621033430 3800 com. E0fw9vzA0DqWNYImFXrvmV/qH2cH6hDM5E7X6/pCKrhCZp7Qb6iCkp3u PdwVPv5HIs65MaMNSGA9gXCs4JcXBjUx6cmjKUbUfGX2kQffmFm6dGfA WvtjYvzFfG1o/0SUU5awr6hes1fa/G1RxwVW8a4AAdhZ/cPpFS2RTlar i/0=
50C5NFS5N8S46COAHN2QFK40EQF0U3HS.com. 86400 IN NSEC3 1 1 0 - 50C7M61IFHEGFKLIRHD1569DD1CM9NV5 NS DS RRSIG
50C5NFS5N8S46COAHN2QFK40EQF0U3HS.com. 86400 IN RRSIG NSEC3 8 2 86400 20190626053147 20190619042147 3800 com. eYnghQKgo9br7ORy1m6Ago7kBLi6Hj5yYumps4YQNJs/CMlgLt8yuzhw SGIAyzMuRuCnW8N+rH813tURS/zaR8cOWqxqxG/sj7xDZ++kMveCA7VW MQZq8CCplfYqAMpaNqDf3Qi/21612pfQnRnVe1XNwS99rqv/wt7L/OaE 6Ek=
;; Received 693 bytes from 192.55.83.30#53(m.gtld-servers.net) in 25 ms
test.xanderflood.com. 300 IN NS ns.test.xanderflood.com.
^Ccouldn't get address for 'ns.test.xanderflood.com': not found
dig: couldn't get address for 'ns.test.xanderflood.com': no more
In the last stage, the route53 server doesn't seem to send the glue record along with the NS record. But when I check that specifically by running dig #ns-1471.awsdns-55.org test.test.xanderflood.com, it does sen the glue record:
; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> #ns-1471.awsdns-55.org test.test.xanderflood.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52944
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.test.xanderflood.com. IN A
;; AUTHORITY SECTION:
test.xanderflood.com. 300 IN NS ns.test.xanderflood.com.
;; ADDITIONAL SECTION:
ns.test.xanderflood.com. 300 IN A 198.51.100.234
;; Query time: 26 msec
;; SERVER: 205.251.197.191#53(205.251.197.191)
;; WHEN: Fri Jun 21 18:58:54 EDT 2019
;; MSG SIZE rcvd: 87
I tried all four of the listed AWS nameservers and they all included the glue record. Similarly, if I ask the AWS servers for ns.test.xanderflood.com, I get the A record, but when I use dig +trace and ask my ISPs recursive server, it gets to the NS record and can't go any further. Any ideas?
The problem is not with the +trace. Since a simple request for the nameserver name receives an error:
$ dig ns.test.xanderflood.com
; <<>> DiG 9.10.3-P4-Debian <<>> ns.test.xanderflood.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6793
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns.test.xanderflood.com. IN A
;; Query time: 4625 msec
Because the problem is that this specific nameserver does not reply at all!
The parent correctly provides the glue:
$ dig #ns-1657.awsdns-15.co.uk. ns.test.xanderflood.com | grep 'IN A '
ns.test.xanderflood.com. 5m IN A 198.51.100.234
(+short does not work because the information is in the additional section, not the answer one)
But then:
$ dig #198.51.100.234 ns.test.xanderflood.com
; <<>> DiG 9.12.0 <<>> #198.51.100.234 ns.test.xanderflood.com
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30129
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f266724ac73b2e54
;; QUESTION SECTION:
;ns.test.xanderflood.com. IN A
;; QUERY SIZE: 64
;; connection timed out; no servers could be reached
(the usual troubleshooting then involves trying +tcp/+notcp to debug UDP/TCP problems and +dnssec/+nodnssec to involve DNSSEC related problems. No options change the above result, the server does not reply)
This server does not reply. dig +trace finishes by asking this server but does not get a reply, hence the final error.
As soon as this nameserver starts to reply to DNS queries your problem will go away.
You can as well have a look at a monitoring service: http://dnsviz.net/d/ns.test.xanderflood.com/dnssec/
The popup on the name says: No response was received from server over UDP (tried 12 times.)
By the way, surely obvious, but just to be sure: it is a bad idea to delegate a domain to a single nameserver (especially if not anycasted)
As you know, www.google.com is an already registered domain name on the internet.
I'm wondering why I can create a public hosted zone with domain name as google.com without getting any error from AWS route53.
I've read the document here. It looks like that the name server for .com TLD is not affected by my route53 configuration.
What's the mechanism of the internet that prevents me from affecting www.google.com domain?
What happens is that you just create an entry on the servers provided by AWS route 53, but that doesn't mean that google.com will now use the records you just created.
The reasons for this is because google.com is using its own defined name servers, to check this give try to this command:
$ dig google.com ns +short
ns3.google.com.
ns4.google.com.
ns2.google.com.
ns1.google.com.
You indeed can query your serves and ask for the www.google.com record, for example:
dig #ns-1656.awsdns-15.co.uk www.google.com.
Based on the images you posted, it should return the IP you defined 123.123.123.123
Notice the #ns-1656.awsdns-15.co.uk the # it is specifying ns-1656.awsdns-15.co.uk as the server to query.
But by using your system resolver you should get the google's IP:
dig www.google.com
All this ends to how DNS resolution works, you indeed can do a full trace, for example, check the output of this command:
$ dig www.google.com +trace
; <<>> DiG 9.8.3-P1 <<>> www.google.com +trace
;; global options: +cmd
. 557714 IN NS a.root-servers.net.
. 557714 IN NS b.root-servers.net.
. 557714 IN NS c.root-servers.net.
. 557714 IN NS g.root-servers.net.
. 557714 IN NS j.root-servers.net.
. 557714 IN NS h.root-servers.net.
. 557714 IN NS l.root-servers.net.
. 557714 IN NS f.root-servers.net.
. 557714 IN NS m.root-servers.net.
. 557714 IN NS e.root-servers.net.
. 557714 IN NS k.root-servers.net.
. 557714 IN NS d.root-servers.net.
. 557714 IN NS i.root-servers.net.
;; Received 449 bytes from 10.10.1.21#53(10.10.1.21) in 493 ms
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.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 g.gtld-servers.net.
;; Received 492 bytes from 192.36.148.17#53(192.36.148.17) in 315 ms
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.
;; Received 168 bytes from 192.55.83.30#53(192.55.83.30) in 27 ms
www.google.com. 300 IN A 172.217.23.164
;; Received 48 bytes from 216.239.32.10#53(216.239.32.10) in 20 ms
This is how a query recursively receives a response in a typical DNS resolution scenario: (taken from: https://ns1.com/articles/using-dig-trace)
You as the DNS client (or stub resolver) query your recursive resolver for google.com.
dig google.com +trace
Your recursive resolver queries the root name server for google.com.
; <<>> DiG 9.8.3-P1 <<>> www.google.com +trace
;; global options: +cmd
. 557714 IN NS a.root-servers.net.
. 557714 IN NS b.root-servers.net.
. 557714 IN NS c.root-servers.net.
. 557714 IN NS g.root-servers.net.
. 557714 IN NS j.root-servers.net.
. 557714 IN NS h.root-servers.net.
. 557714 IN NS l.root-servers.net.
. 557714 IN NS f.root-servers.net.
. 557714 IN NS m.root-servers.net.
. 557714 IN NS e.root-servers.net.
. 557714 IN NS k.root-servers.net.
. 557714 IN NS d.root-servers.net.
. 557714 IN NS i.root-servers.net.
;; Received 449 bytes from 10.59.1.21#53(10.59.1.21) in 493 ms
The root name server refers your recursive resolver to the .com Top-Level Domain (TLD) authoritative server.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.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 g.gtld-servers.net.
;; Received 492 bytes from 192.36.148.17#53(192.36.148.17) in 315 ms
Your recursive resolver queries the .com TLD authoritative server for google.com
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.
;; Received 168 bytes from 192.55.83.30#53(192.55.83.30) in 27 ms
The .com TLD authoritative server refers your recursive server to the authoritative servers for google.com.
Your recursive resolver queries the authoritative servers for google.com, and receives 216.239.31.10 as the answer.
google.com. 300 IN A 172.217.23.164
;; Received 48 bytes from 216.239.32.10#53(216.239.32.10) in 20 ms
Your recursive resolver caches the answer for the duration of the time-to-live (TTL) specified on the record, and returns it to you.
In my ongoing experiments to understand DNS, I'm trying to understand how a nameserver does a recursive query. I get the basic idea - you start with a top level dns server, then it sends you a list of authoritative nameservers to contact, then you contact those servers, etc., until you get a authoritative response.
Sounds simple enough.
But when I try it in practice, I get stuck after the first step. I'm just doing this manually with command line tools - (I make sure to turn off recursion.)
Okay, so step 1: start with a root name server. I randomly picked 198.41.0.4 (Verisign) from the list of root name servers on Wikipedia.
I send it a request to resolve "google.com".
It sends me back the following:
+---------------------------------------------------------------------------+
| 47547 | QR: 1 | OP: 00 | AA: 0 | TC: 0 | RD: 1 | RA: 0 | Z: 0 | RCODE: 00 |
+---------------------------------------------------------------------------+
| QDCOUNT: 1, ANCOUNT: 0, NSCOUNT: 13, ARCOUNT: 15 |
+---------------------------------------------------------------------------+
ANSWERS : 0
AUTHORITIES:
NS: m.gtld-servers.net
NS: l.gtld-servers.net
NS: k.gtld-servers.net
NS: j.gtld-servers.net
NS: i.gtld-servers.net
NS: h.gtld-servers.net
NS: g.gtld-servers.net
NS: f.gtld-servers.net
NS: e.gtld-servers.net
NS: d.gtld-servers.net
NS: c.gtld-servers.net
NS: b.gtld-servers.net
NS: a.gtld-servers.net
ADDITIONAL:
A: 192.55.83.30
A: 192.41.162.30
A: 192.52.178.30
A: 192.48.79.30
A: 192.43.172.30
A: 192.54.112.30
A: 192.42.93.30
A: 192.35.51.30
A: 192.12.94.30
A: 192.31.80.30
A: 192.26.92.30
A: 192.33.14.30
AAAA: 2001:0503:231d:0000:0000:0000:0002:0030
A: 192.5.6.30
AAAA: 2001:0503:a83e:0000:0000:0000:0002:0030
Okay, so I'm not sure what the point of all those ADDITIONAL records are - they all appear to be local LAN addresses so I don't know what use they are to me. But anyway, looking at the results returned in the authority section, I see another list of name servers. Okay, so I guess the next step is I need to choose one of the name servers returned, and get it's IP. So I issue a request to resolve a.gtld-servers.net, and...
...it just returns the exact same list of nameservers.
So... I'm not sure how to proceed here. How do I ultimately get to the authoritative name server for "google.com"?
EDIT:
Okay, so it appears those 192 addresses are not LAN addresses as I wrongly assumed, but they are other nameservers. I'm assuming I can contact those nameservers to get closer to the authority. But, how am I supposed to know to use these nameservers? I thought that the ARCOUNT section was just for additional information... why are all those nameservers placed in the ADDITIONAL section instead of as answers or authorities? Is it just some convention that referrals to other nameservers go in the ADDITIONAL section?
You can use the dig +trace command : it will exactly show you each query made by a typical recursive nameserver.
If you try for example for www.google.com (if you do not specify the type, dig uses A by default, and I removed DNSSEC related information with +nodnssec to simplify the output):
$ dig +trace www.google.com +nodnssec
; <<>> DiG 9.12.0 <<>> +trace www.google.com +nodnssec
;; global options: +cmd
. 307678 IN NS f.root-servers.net.
. 307678 IN NS a.root-servers.net.
. 307678 IN NS m.root-servers.net.
. 307678 IN NS e.root-servers.net.
. 307678 IN NS i.root-servers.net.
. 307678 IN NS l.root-servers.net.
. 307678 IN NS c.root-servers.net.
. 307678 IN NS g.root-servers.net.
. 307678 IN NS b.root-servers.net.
. 307678 IN NS k.root-servers.net.
. 307678 IN NS h.root-servers.net.
. 307678 IN NS d.root-servers.net.
. 307678 IN NS j.root-servers.net.
;; Received 447 bytes from 192.168.10.229#53(192.168.10.229) in 5 ms
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
;; Received 839 bytes from 192.36.148.17#53(i.root-servers.net) in 88 ms
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.
;; Received 291 bytes from 192.5.6.30#53(a.gtld-servers.net) in 145 ms
www.google.com. 300 IN A 172.217.7.196
;; Received 48 bytes from 216.239.34.10#53(ns2.google.com) in 83 ms
Each paragraph is one query, showing the reply and who replied (who we queried).
Let us go back at first query, to redo what you did with 198.41.0.4 (aka a.root-servers.net:
$ dig A www.google.com #198.41.0.4 +nodnssec
; <<>> DiG 9.12.0 <<>> A www.google.com #198.41.0.4 +nodnssec
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b56cbe6c8ffd3856
;; QUESTION SECTION:
;www.google.com. IN A
;; QUERY SIZE: 55
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
;; Query time: 134 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Wed Aug 15 09:39:43 EST 2018
;; MSG SIZE rcvd: 839
So what is happening here:
you have no aa flag in reply, which shows that the nameserver replying is NOT authoritative for this query (it will be authoritative if you ask it for . NS for example)
it tells you in AUTHORITY SECTION who is authoritative for the next step, that is com.; this means giving you a set of nameservers (NS records)
to help you go faster in ADDITIONAL SECTION it gives you IP addresses of the above nameservers, as otherwise you will first need to resolve their name to an IP to be able to contact them.
The sections are defined in RFC1034:
The four sections are:
Question Carries the query name and other query parameters.
Answer Carries RRs which directly answer the query.
Authority Carries RRs which describe other authoritative
servers.
May optionally carry the SOA RR for the authoritative
data in the answer section.
Additional Carries RRs which may be helpful in using the RRs in
the
other sections.
So the data could not be put in the "Answer" section, since it does not answer directly the query presented, nor in the "Authority" section, since the nameserver you queried is not authoritative over gtld-servers.net
Which also explain why dig A e.gtld-servers.net. #198.41.0.4 +nodnssec will return basically the same answer, but it is mostly because .com and .net are handled by one and the same registry (VeriSign) and they share the same authoritative nameservers (and VeriSign also handles two root nameservers - a and j - but this is unrelated)
So, yes, next step would be to connect to any IP given for a gtld-servers.net nameserver to redo the query and find out if it is authoritative for www.google.com, and since it is not it will provide the next step in the "Authority" section.
Like so:
$ dig A www.google.com #a.gtld-servers.net. +norecurse +nodnssec
; <<>> DiG 9.12.0 <<>> A www.google.com #a.gtld-servers.net. +norecurse +nodnssec
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26904
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 22d54e7533355129
;; QUESTION SECTION:
;www.google.com. IN A
;; QUERY SIZE: 55
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26904
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com. IN A
;; 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: 142 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Aug 15 09:54:27 EST 2018
;; MSG SIZE rcvd: 291
And so on.
Also you are mistaken about:
they all appear to be local LAN addresses so I don't know what use they are to me.
Private addresses space is described by RFC 1918 which lists:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
None of the IP are in these blocks, thankfully.
There is something wrong in your query to Verisign servers. Try this:
dig #<VeriSign-nameserver> google.com NS. : this should get you the aUuthoritative nameservers for google.com
dig #<NS for google.com> www.google.com A. : this gets you the A records for www.google.com from google.com nameservers.
Note: if google.com nameservers are in the same zone as google.com, #1 should return you glue records, which means it would also resolve the IP address for the nameservers.