dig コマンドによる手動反復問い合わせ方法と status の事例

dig はフルサービスリゾルバに対して再帰問い合わせを要求するだけではなく、「+norecurse(もしくは +norec)」オプションを引数として与えると非再帰問い合わせを実行できます。

前回 BIND で DNS の名前空間をローカルで構成する方法をまとめました。

tech.yamashiro.blog. の名前空間を作成するには以下の権威サーバが必要になります。

  1. ルートサーバ
  2. blog のネームサーバ
  3. 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 の値によってどのような設定に名前解決の邪魔をされているのかが判断できます。

権威サーバの 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.1

named が停止していた場合、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 ではなくただのエラーとなります。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)