trace option
+trace オプションの挙動
$ dig yokohei.com. +trace を実行したことを想定。
1. .(root) の NS を Resolver に聞きに行く (without RD bit)
2. Resolver は .(root) の NS を Authority Section に入れて返す
[A-M].ROOT-SERVERS.NET の 13 個が返される。
通常の Recursive Query では Additional Section に入っている IP アドレスを利用するが、 trace の場合は利用しない。
代わりに、 NS を再度名前解決する。
3. [A-M].ROOT-SERVERS.NET の A レコードを Resolver に聞きに行く (with RD bit)
これで、 .(root) の NS の IP アドレスがわかる。
4. yokohei.com. の A レコードを .(root) の Name Server に聞きに行く (without RD bit)
すべての Name Server には聞きに行かず、 A を持っているもののどれかに聞きに行く。
ここでは、例として G.ROOT-SERVERS.NET に聞きに行ったとする。
5. G.ROOT-SERVERS.NET は com. の NS を Authority Section に入れて返す
[a-m].gtld-servers.net の 13 個が返される。
このときも Additional Section に入っている IP アドレスは利用されない。
6. [a-m].gtld-servers.net の A レコードを Resolver に聞きに行く (with RD bit)
これで、 com. の NS の IP アドレスがわかる。
7. yokohei.com. の A レコードを com. の Name Server に聞きに行く (without RD bit)
すべての Name Server には聞きに行かず、 A を持っているもののどれかに聞きに行く。(4. と同様の流れ)
ここでは、例として m.gtld-servers.net に聞きに行ったとする。
8. m.gtld-servers.net は yokohei.com. の NS を Authority Section に入れて返す
Route 53 で管理されている 4 つの NS が返される。
このときも Additional Section に入っている IP アドレスは利用されない。
9. Route 53 で管理されている 4 つの NS の A レコードを Resolver に聞きに行く (with RD bit)
これで、 yokohei.com. の NS の IP アドレスがわかる。
10. yokohei.com. の A レコードを yokohei.com. の Name Server に聞きに行く (without RD bit)
ついに Answer を受け取る。
+trace 有無による結果の違い
上記の通り、 trace オプションは NS に対する Glue Record (Additional で IP アドレスを返すもの) を利用しない。
そのために +trace の有無で名前解決結果が変わる場合がある。
以下は +trace なしで名前解決を試行したものである。
$ dig a.sub.yokohei.com.
; <<>> DiG 9.9.4-RedHat-9.9.4-73.amzn2.1.1 <<>> a.sub.yokohei.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8285
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;a.sub.yokohei.com. IN A
;; ANSWER SECTION:
a.sub.yokohei.com. 60 IN A 1.1.1.1
;; Query time: 26 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: 土 6月 29 18:25:19 UTC 2019
;; MSG SIZE rcvd: 62
上では、名前解決結果を取得できている。
これに対して、以下はどうか。 trace をつけて名前解決を試行してみる。
$ dig a.sub.yokohei.com. +trace +nodnssec
; <<>> DiG 9.9.4-RedHat-9.9.4-73.amzn2.1.1 <<>> a.sub.yokohei.com +trace +nodnssec
;; global options: +cmd
. 518400 IN NS A.ROOT-SERVERS.NET.
...
. 518400 IN NS M.ROOT-SERVERS.NET.
;; Received 811 bytes from 172.31.0.2#53(172.31.0.2) in 6 ms
com. 172800 IN NS a.gtld-servers.net.
...
com. 172800 IN NS m.gtld-servers.net.
;; Received 842 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 7 ms
yokohei.com. 172800 IN NS ns-159.awsdns-19.com.
yokohei.com. 172800 IN NS ns-987.awsdns-59.net.
yokohei.com. 172800 IN NS ns-1721.awsdns-23.co.uk.
yokohei.com. 172800 IN NS ns-1162.awsdns-17.org.
;; Received 199 bytes from 192.33.14.30#53(b.gtld-servers.net) in 26 ms
sub.yokohei.com. 300 IN NS ns1.sub.yokohei.com.
sub.yokohei.com. 300 IN NS ns2.sub.yokohei.com.
sub.yokohei.com. 300 IN NS ns3.sub.yokohei.com.
sub.yokohei.com. 300 IN NS ns4.sub.yokohei.com.
dig: couldn't get address for 'ns1.sub.yokohei.com': no more
名前解決に失敗している。
ns1.sub.yokohei.com. に対する名前解決の失敗。
単体で試行してみる。
$ dig ns1.sub.yokohei.com.
; <<>> DiG 9.9.4-RedHat-9.9.4-73.amzn2.1.1 <<>> ns1.sub.yokohei.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24340
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.sub.yokohei.com. IN A
;; AUTHORITY SECTION:
sub.yokohei.com. 59 IN SOA ns-1986.awsdns-56.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 1 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: 土 6月 29 18:29:16 UTC 2019
;; MSG SIZE rcvd: 132
やはり NXDOMAIN になる。これはなぜか。
sub.yokohei.com. は NS レコードを持っており権限移譲されている。
つまり、*.sub.yokohei.com. のレコードは sub.yokohei.com. のゾーンで管理されているはずである。
なので、sub.yokohei.com. のゾーンに ns1.sub.yokohei.com. のレコードを登録すると解決できるようになる。
(このときのクエリは +trace でも reursive なので)
または、sub.yokohei.com. のサブドメインじゃないドメイン名にしても解決できる。