+trace Option in dig

+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. のサブドメインじゃないドメイン名にしても解決できる。