+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 なしで名前解決を試行したものである。
上では、名前解決結果を取得できている。 これに対して、以下はどうか。 trace をつけて名前解決を試行してみる。
名前解決に失敗している。 ns1.sub.yokohei.com. に対する名前解決の失敗。 単体で試行してみる。
やはり NXDOMAIN になる。これはなぜか。
sub.yokohei.com. は NS レコードを持っており権限移譲されている。 つまり、*.sub.yokohei.com. のレコードは sub.yokohei.com. のゾーンで管理されているはずである。 なので、sub.yokohei.com. のゾーンに ns1.sub.yokohei.com. のレコードを登録すると解決できるようになる。 (このときのクエリは +trace でも reursive なので)
または、sub.yokohei.com. のサブドメインじゃないドメイン名にしても解決できる。