When should a NS query terminate? - dns

Command:
dig NS +noadditional +noquestion +nocomments +nocmd +nostats +trace google.com. #8.8.4.4
Output:
. 1664 IN NS a.root-servers.net.
. 1664 IN NS b.root-servers.net.
. 1664 IN NS c.root-servers.net.
. 1664 IN NS d.root-servers.net.
. 1664 IN NS e.root-servers.net.
. 1664 IN NS f.root-servers.net.
. 1664 IN NS g.root-servers.net.
. 1664 IN NS h.root-servers.net.
. 1664 IN NS i.root-servers.net.
. 1664 IN NS j.root-servers.net.
. 1664 IN NS k.root-servers.net.
. 1664 IN NS l.root-servers.net.
. 1664 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 200 ms
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
;; Received 500 bytes from 192.33.4.12#53(192.33.4.12) in 27 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 164 bytes from 192.52.178.30#53(192.52.178.30) in 119 ms
google.com. 345600 IN NS ns4.google.com.
google.com. 345600 IN NS ns2.google.com.
google.com. 345600 IN NS ns1.google.com.
google.com. 345600 IN NS ns3.google.com.
;; Received 164 bytes from 216.239.38.10#53(216.239.38.10) in 25 ms
The resolver didn't terminate the query after receiving an answer from 192.52.178.30 (one of com's nameservers). Is this a standard behavior? Does it apply to all kinds of records?


You asked dig to give you a trace to an authoritative name server, and it gave you a trace to an authoritative name server. I fail to see why you are surprised. Or, differently put, yes, that is totally the expected behavior when you use +trace in dig.

Related

Nameserver returns different records on different machines

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?

How to capture the complete DNS recursive query name server path?

I'd like to know if there is a way to capture the entire DNS recursive query path? (i.e. When the resolver on my computer sends a UDP query to the local DNS server, the server passes the query through a series of name servers before it reaches the authoritative name server. I want to know every single server along the path.)
Tried nslookup and various DNS lookup tools, but they only gave the authoritative resource record without showing the route leading to this result.

Have a look at dns +trace.
$ dig +trace www.stackoverflow.com A
; <<>> DiG 9.12.0 <<>> +trace www.stackoverflow.com A
;; global options: +cmd
. 10h11m19s IN NS l.root-servers.net.
. 10h11m19s IN NS f.root-servers.net.
. 10h11m19s IN NS b.root-servers.net.
. 10h11m19s IN NS e.root-servers.net.
. 10h11m19s IN NS d.root-servers.net.
. 10h11m19s IN NS m.root-servers.net.
. 10h11m19s IN NS i.root-servers.net.
. 10h11m19s IN NS g.root-servers.net.
. 10h11m19s IN NS k.root-servers.net.
. 10h11m19s IN NS c.root-servers.net.
. 10h11m19s IN NS a.root-servers.net.
. 10h11m19s IN NS h.root-servers.net.
. 10h11m19s IN NS j.root-servers.net.
. 10h11m19s IN RRSIG NS 8 0 518400 (
20190731050000 20190718040000 59944 .
h37qHHCpVvZ5cw5RCHQs9FiNUc6cYO0bSxDatRwZlnza
lf7otk/DGAibKrvtmVdE7sePmdh6pA7XcaICyuWKrucG
SJdNlnwDCSXgZGNjOQL+fI3aU1kczxbvVCpMdSOk8pWS
eV9Iwz109qBcvDUJB8a8lYxa4Y9BZAONcnmr5yeIiQsy
UvwWOST6f/pSTAJKMTMFkFC/O5bmi527SglJs1oVx7Oq
MA+RYx647LF5W/nvRXlKU0FHcWy8GH2pRY3obBr6yg19
QUHYPX+oCizP65IJDoz3h1sp902lHRDFlsILAk0m6tHK
KV4QixZYl9l6KoI8QtHYSkOxwwX6FnF2Zw== )
;; Received 525 bytes from 9.9.9.9#53(9.9.9.9) in 79 ms
com. 2d IN NS a.gtld-servers.net.
com. 2d IN NS b.gtld-servers.net.
com. 2d IN NS c.gtld-servers.net.
com. 2d IN NS d.gtld-servers.net.
com. 2d IN NS e.gtld-servers.net.
com. 2d IN NS f.gtld-servers.net.
com. 2d IN NS g.gtld-servers.net.
com. 2d IN NS h.gtld-servers.net.
com. 2d IN NS i.gtld-servers.net.
com. 2d IN NS j.gtld-servers.net.
com. 2d IN NS k.gtld-servers.net.
com. 2d IN NS l.gtld-servers.net.
com. 2d IN NS m.gtld-servers.net.
com. 1d IN DS 30909 8 2 (
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459
588F4A9184CFC41A5766 )
com. 1d IN RRSIG DS 8 1 86400 (
20190731050000 20190718040000 59944 .
hmwZHci5TxM6wPVGdaDRKJ5w5554UbLN1cc/W/5Ksb1/
lZDMmVQKaGPYUP1qss6UqMqkXSbyx2sz5aQbukBQOlkK
PwG6xFdzjBWw3yNxNQM6/0npP64/EzJ0dBU0qvTfxIeE
TMSuRtbcPFMsX4PtXlZcsEsnn9xg5uwE1n5fBguGRsOL
qiMJTpHiv4iq44Ll5Z84D+MX9axzgijkUvY04NVL/CI3
yN1xtujOQZUFk35XdXN/KfKMRrdLieKp7j6iS/rPp5ph
At85ZJa0c93fDsPzyQs88qWpnpxd4iy/2e7xCCr5SLp9
ZNUtmyxyqfnZ4wSJdOZjtZovUj4GyLUy3w== )
;; Received 1181 bytes from 193.0.14.129#53(k.root-servers.net) in 141 ms
stackoverflow.com. 2d IN NS ns-358.awsdns-44.com.
stackoverflow.com. 2d IN NS ns-1033.awsdns-01.org.
stackoverflow.com. 2d IN NS ns-cloud-e1.googledomains.com.
stackoverflow.com. 2d IN NS ns-cloud-e2.googledomains.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 1d IN NSEC3 1 1 0 - (
CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A
NS SOA RRSIG DNSKEY NSEC3PARAM )
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 1d IN RRSIG NSEC3 8 2 86400 (
20190722044529 20190715033529 3800 com.
QruEtMEx3JMwz1cwK+gArQ3ZkNbCR4x+8ul54fAkec4I
eN6LvHGTo61mDq5w/D0fzhLIhwXRtbxSpDPspvqYpEys
6f69kM1U4NzGvTb8/iz7/b0Tes+n3i+Gx0S+/X7ajkvu
+J6GmVpgsZPIMxpSJjGSLZXtlEB4YyPBprWZsck= )
QJLANLBLFPUKKIO73G776E7389OP43C0.com. 1d IN NSEC3 1 1 0 - (
QJLBMGGUF1TGTFH7U479EFSNO84B6UPD
NS DS RRSIG )
QJLANLBLFPUKKIO73G776E7389OP43C0.com. 1d IN RRSIG NSEC3 8 2 86400 (
20190725050317 20190718035317 17708 com.
UrrzTGluj/zP3D4mj/D0WIv3/JkM9XbMPtnGCamyWv3Y
GQqb7fdUa9+DXzBjTR1XiS7AGtL5DeivPKCMU1FDHv28
0uFdk/IAUWTGknlAalujtZWlXUSwlCEifAJrqrDK+itv
sVtWPG1Xf4Oq0yZAcxWeiSC+SX3Tv8fR0m5jBL4= )
;; Received 771 bytes from 192.35.51.30#53(f.gtld-servers.net) in 135 ms
www.stackoverflow.com. 1h IN CNAME stackoverflow.com.
stackoverflow.com. 5m IN A 151.101.129.69
stackoverflow.com. 5m IN A 151.101.65.69
stackoverflow.com. 5m IN A 151.101.193.69
stackoverflow.com. 5m IN A 151.101.1.69
stackoverflow.com. 2d IN NS ns-1033.awsdns-01.org.
stackoverflow.com. 2d IN NS ns-358.awsdns-44.com.
stackoverflow.com. 2d IN NS ns-cloud-e1.googledomains.com.
stackoverflow.com. 2d IN NS ns-cloud-e2.googledomains.com.
;; Received 260 bytes from 205.251.193.102#53(ns-358.awsdns-44.com) in 80 ms
Then it depends what you mean exactly by capture.
You can also:
run a network sniffer and record all TCP/53 and UDP/53 packets
run a local recursive nameserver and switch its logging, and point your request to it, and see the results in the logfiles.

How does my ISP DNS server contact the root DNS server?

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

What happened when I create a public "www.google.com" record set in AWS route53?

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.

Manually doing a recursive DNS query

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.

Resources