TURNING POINT 
dig はフルサービスリゾルバに対して再帰問い合わせを要求するだけではなく、「+norecurse（もしくは +norec）」オプションを引数として与えると非再帰問い合わせを実行できます。
前回 BIND で DNS の名前空間をローカルで構成する方法をまとめました。
tech.yamashiro.blog. の名前空間を作成するには以下の権威サーバが必要になります。
- ルートサーバ
- blog のネームサーバ
- yamashiro.blog のネームサーバ
dig でフルサービスリゾルバの動きを再現できると、名前空間のどこでエラーが発生しているのかが分かるようになります。例えば、「tech.yamashiro.blog.」の名前解決が失敗したとして、どこで名前解決が躓いているのか判断することが可能になります。
[root@localhost ~]# dig +norec @10.0.0.1 tech.yamashiro.blog.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62152
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; QUESTION SECTION:
;tech.yamashiro.blog. IN A
;; AUTHORITY SECTION:
blog. 3600 IN NS ns1.blog.
;; ADDITIONAL SECTION:
ns1.blog. 3600 IN A 172.16.0.1上記はルートネームサーバに問い合わせを実行している例ですが、「tech.yamashiro.blog.」の Query に対して、「blog.」のネームサーバが返ってきています。これの動きを繰り返していくことで、どこで名前解決が失敗しているかが分かります。
また、もしエラーになった場合、「HEADER」セクションの「status」フィールドを確認するとよいでしょう。以下に例を示しますが、status の値によってどのような設定に名前解決の邪魔をされているのかが判断できます。
Contents
権威サーバの named を stop した場合
以下は正常に名前解決が終了した場合の出力です。
[root@localhost ~]# dig +norec @172.16.0.1 tech.yamashiro.blog.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14976
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; QUESTION SECTION:
;tech.yamashiro.blog. IN A
;; AUTHORITY SECTION:
yamashiro.blog. 3600 IN NS ns1.yamashiro.blog.
;; ADDITIONAL SECTION:
ns1.yamashiro.blog. 3600 IN A 192.168.0.1named が停止していた場合、status 等は表示されず以下のようなエラーになります。
[root@localhost ~]# dig +norec @172.16.0.1 tech.yamashiro.blog.
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> +norec @172.16.0.1 tech.yamashiro.blog.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reachedちなみに、以下の場合でも同様のエラーになります。
- サーバの NIC が Active になっていない
- サーバの FIreawlld にブロックされている
つまり、そもそも named とお喋りが出来なかった場合は全て上記のエラーになるということです。
ヒントファイルが誤っている場合
ヒントファイル(ルートヒント)の記載に誤りがあり名前解決に失敗する場合、status は以下のように「SERVFAIL」となります。
[root@A ~]# dig tech.yamashiro.blog.
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46982
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;tech.yamashiro.blog. IN A
;; Query time: 4000 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: 火 7月 14 10:42:09 JST 2020
;; MSG SIZE rcvd: 48子ドメインの NS レコードが無い場合
「blog.」のネームサーバから見ると「yamashiro.blog.」は子ドメインです。通常、親ドメインは子ドメインの NS レコードを定義していなければなりません。親ドメインである「blog.」のネームサーバから「yamashiro.blog.」の NS レコードを削除した場合、以下のような status になります。
[root@localhost ~]# dig +norec @172.16.0.1 tech.yamashiro.blog.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30079
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;tech.yamashiro.blog. IN A
;; AUTHORITY SECTION:
blog. 3600 IN SOA ns1.blog. postmaster.blog. 2019062301 3600 900 604800 3600子ドメインのグルーレコードが無い場合
上記では親ドメインである「blog.」に子ドメイン「yamashiro.blog.」の NS レコードが無ければ status は NXDOMAIN になっていました。では、NS レコードは存在するもののグルーレコードが無い場合はどうなるでしょうか。
[root@localhost ~]# dig +norec @172.16.0.1 tech.yamashiro.blog.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38299
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;tech.yamashiro.blog. IN A
;; AUTHORITY SECTION:
yamashiro.blog. 3600 IN NS ns1.yamashiro.blog.結果は上記のように NOERROR です。グルーレコードは必ずあるわけではないので、このような結果になります。グルーレコードについて認識が間違っていた場合、以下の記事を読んでみてください。
allow-query で許可されていない場合
allow-query で拒否された場合は以下のように REFUSED となります。
[root@A ~]# dig +norec @172.16.0.1 tech.yamashiro.blog.
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 59825
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;tech.yamashiro.blog. IN A注意していただきたいのが、先述したように Firewalld でアクセスがブロックされた場合は REFUSED ではなくただのエラーとなります。
