SYONテクニカル

digを使い倒そう

サイオンコミュニケーションズ株式会社
照屋 響

1.digとは?

みなさん、digというコマンドをご存知でしょうか? DNSサーバへ問い合わせをして、その結果を教えてくれるコマンドです。

このdigですが、DNSトラブル時に非常に強力に手助けを してくれます。ということでDNSトラブルを切り分けるdigの ちょっとしたコツをお伝えします。

作業環境

今回の作業はFreeBSD 4.x, 5.x 上で行いました。 digコマンドはFreeBSDには標準で付属しています。 Linuxではdigコマンドが入っているパッケージをインストールすれば使えます。

2.digコマンド

構文は以下のとおり
dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option]

この中で重要なのが[@server][query-type][+query-option]の3つです。この3つが使えれば、 DNSトラブルの切り分けはほぼ9割はできたも当然です。

@server
問い合わせを行うDNSサーバを指定。省略すると/etc/resolv.conf 内に設定されているサーバに対して問い合わせを行います。

query-type
取得したいレコードの種類を指定します。 省略するとAが設定されAレコードが返されます。

実際によく使うのが以下の5つです。

A
ホストのIPアドレス
MX
メールサーバ
NS
ネームサーバ(DNSサーバ)
SOA
ゾーン情報
PTR
IPアドレスに対するホスト名

+query-option
色々ありますが重要なのは1つだけ

+norec
再帰問い合わせを行わない

+norecはトラブル切り分け時には必須のオプションです。要するに、サーバによけいな事はしないで自分が知っている情報だけ教えろってオプションです。

その他のオプションについての紹介は今回は省略します。 興味のある方はdigのマニュアルを参照してください。

3.digの出力

以下に出力のサンプルを記述します。

> dig www.syon.co.jp

; <<>> DiG 8.3 <<>> www.syon.co.jp
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51252
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; QUERY SECTION:
;;      www.syon.co.jp, type = A, class = IN

;; ANSWER SECTION:
www.syon.co.jp.         1D IN CNAME     ns.syon.co.jp.
ns.syon.co.jp.          1D IN A         211.120.225.242

;; AUTHORITY SECTION:
syon.co.jp.             1D IN NS        ns.syon.co.jp.
syon.co.jp.             1D IN NS        syuri.ii-okinawa.ad.jp.

;; ADDITIONAL SECTION:
ns.syon.co.jp.          1D IN A         211.120.225.242
syuri.ii-okinawa.ad.jp.  1h31m20s IN A  211.120.224.10
syuri.ii-okinawa.ad.jp.  1h39m25s IN AAAA  2001:d28:0:2::224:10

;; Total query time: 22 msec
;; FROM: xxx.syon.co.jp to SERVER: 211.120.225.242
;; WHEN: Thu Jun 30 18:20:58 2005
;; MSG SIZE  sent: 32  rcvd: 173

出力結果の各項目の説明をします。

; <<>> DiG 8.3 <<>> www.syon.co.jp

<<>> DiG 8.3 <<>> の後にdigコマンドの引数として指定した内容が表示されます。 dig @ns.syon.co.jp www.syon.co.jp A +norec とコマンドを打つと、

; <<>> DiG 8.3 <<>> @ns.syon.co.jp www.syon.co.jp A +norec

と表示されます。

;; res options: init recurs defnam dnsrch

現在のクエリオプションです。今回説明は省きます。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51252

status
サーバからの応答がどのようにかえってきたのかわかります。重要です。

NOERROR
DNSサーバが正常に応答した
NXDOMAIN
問い合わせをしたドメインは存在しない
SERVFAIL
DNSサーバが正しく応答しなかった

もし、問い合わせをしたDNSサーバがSERVFAILを返すようなら そのDNSサーバは設定が間違っている可能性があります。

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

flags
以下の5つがあります。かなり重要な内容です。

qr
クエリ(問い合わせ)の回答
aa
回答は権限のある回答
tc
回答が長くて切り捨てられた
ra
サーバが再帰可能
rd
再帰希望

わかりにくいですね。1つ1つ説明します。

qrはDNSサーバへ問い合わせしたクエリの回答であることを示します。 ですので、通常は常にこのフラグが立ってかえってきます。

aaはDNSサーバの応答のANSWERセクション(回答)が問い合わせを 行ったDNSサーバのキャッシュではなく、権限のあるサーバから 回答された事を示します。逆にaaのフラグが立ってないと、返ってきた ANSWERセクション(回答)は問い合わせをしたDNSサーバのキャッシュから 返されたことを示します。

tcは回答が長くてパケットが途中で切り捨てられたことを示すようですが、 このフラグが立っている応答を私はまだ1度も見たことがありません。

raは問い合わせを行ったサーバが、あなたに対して 再帰可能であることを示しています。 もし問い合わせたサーバで名前解決できなければ、問い合わせをした DNSサーバが、名前解決できるまで再帰的に他のDNSサーバに問い合わせを 行い、正しい解答をあなたに返してくれます。DNSサーバに対して 問い合わせを行った時にこのフラグが立っていないと、 そのDNSサーバはあなたに対して自分が管理している ドメインの情報しか答えてくれません。

rdはDNSサーバに自分で扱っているドメインの情報でなければ、 権限のあるDNSサーバから回答が得られるまで再帰的に問い合わせを 行ってくださいとdigコマンドから要求していることを示します。 これは+norecオプションをつけなければこのフラグが立ちます。

QUERY:1
問い合わせた内容が1つであることを示します。
ANSWER:2
問い合わせた内容に対して回答が2つ返ってきたことを示します。
AUTHORITY:2
問い合わせを行ったドメインに対する権限のあるサーバ(ゾーン情報を持っているサーバ)が2つあることを示します
ADDITIONAL:3
その他関係のある情報が3つあることを示します。 私が知る限りここにはAUTHORITYに表示されるサーバの Aレコードの情報を表示してくれます。
;; QUERY SECTION:
;;      www.syon.co.jp, type = A, class = IN

DNSサーバに問い合わせている内容です。

;; ANSWER SECTION:
www.syon.co.jp.         1D IN CNAME     ns.syon.co.jp.
ns.syon.co.jp.          1D IN A         211.120.225.242

問い合わせた内容に対する回答になります。

;; AUTHORITY SECTION:
syon.co.jp.             1D IN NS        ns.syon.co.jp.
syon.co.jp.             1D IN NS        syuri.ii-okinawa.ad.jp.

問い合わせたドメインに対する権限のあるサーバになります。

;; ADDITIONAL SECTION:
ns.syon.co.jp.          1D IN A         211.120.225.242
syuri.ii-okinawa.ad.jp.  1h31m20s IN A  211.120.224.10
syuri.ii-okinawa.ad.jp.  1h39m25s IN AAAA  2001:d28:0:2::224:10

権限のあるサーバのAレコードになります。

;; Total query time: 22 msec

結果が返ってくるまでかかった時間です。

;; FROM: xxx.syon.co.jp to SERVER: 211.120.225.242

FROMがdigコマンドを叩いたサーバ(クライアント)になります。 SERVERが問い合わせをしたサーバになります。

;; WHEN: Thu Jun 30 18:20:58 2005

現在の日時です。

;; MSG SIZE  sent: 32  rcvd: 173

送信したデータのサイズと受け取ったデータのサイズになります。

4.digを使ってトラブルを切り分けよう

といっても、先ほどまで説明した内容を理解し、 表示される内容が理解できれば、あなたはもう トラブルの切り分けが難しくないはずです。 digで出力される内容をくまなく見てみましょう。 また別組織にあるサーバにログインが可能で、そこから digがたたけるのならば、トラブルが起きている場所と、 別の環境との結果を比較することで分かることもあると思います。

まず基本は+norecオプションです。 +norecオプションをつけて、自分が使っているサーバに 問い合わせを行います。

次にDNSのrootサーバから順番よく問い合わせを行っていきます。 (+norecオプションを忘れずに) rootサーバから追いかけていく時は関連するすべてのサーバに対して 問い合わせを行いましょう。先ほど説明した内容を理解できれば、 ほとんどのトラブルが切り分けできるはずです。

5.それでもわからない人は?トラブル時に見るべき重要なポイント

1)問い合わせたサーバからSERVFAILが返ってくる

そのサーバの設定が間違っている可能性があります。

2)以下の返答が返ってくる

> dig @xxx.xxx.jp xxx.xxx.jp A

; <<>> DiG 8.3 <<>> @xxx.xxx.jp xxx.jp
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend: Connection refused

問い合せたサーバは本当にDNSサーバですか?

もしDNSサーバならDNSサービスが動いてないか、 サービスを行うべきインターフェースでDNSが動いてないか。 パケットがどこかでブロックされている可能性があります。

3)自組織下にあるDNSサーバに問い合わせをしたらflagsにraが付いてない

普通は、自分の組織下にあるDNSサーバは再帰問い合わせを行い、 あなたの知りたい最終的な回答をしてくれるはずです。ですので、 DNSサーバの設定が間違っている可能性があります。

4)他人の組織のDNSサーバに問い合わせをしたらflagsにraが付いている

ISPじゃない限り、他組織から問い合わせがあっても再帰的に 問い合わせをする必要はないと思います。自前でDNSサーバを立てる方は、 外部からの再帰問い合わせは行わないように設定するべきと思います。

5)1回目の問い合せではaaフラグが付いていたのに同じ問い合せを2回すると
2回目からはaaフラグが付かない

1回目の問い合わせでDNSサーバはその情報をキャッシュしたと 思われます。2回目からDNSサーバはキャッシュから情報を引き出して 回答しています。また1回目からaaが付かないようなら、あなたが 問い合わせる前にすでにDNSサーバがその問い合わせを受けて キャッシュに情報を保存していることになります。

6)DNSサーバのキャッシュの保存期間はどれくらいですか?

ANSWERセクションに記述されています。同じ問い合わせを何度かすると・・・ほらね。

7)とある組織に対してたまーーーにアクセスができなくなる時がある。
またそれは時間をおいたり自組織のDNSサーバをリブートするとアクセスできるようになる

DNSサーバは一つのドメインに対して複数のDNSサーバを 設置することができます。冗長性と負荷分散というメリットがあるのですが、 設定を間違えていたりすると周りに迷惑をかけてしまいます。

例えば、とあるドメインのDNSサーバが10台あったとします。10ヶ所中 1ヶ所だけAレコードのIPアドレスが微妙に間違っているとどうなるか・・・
運悪く間違ったAレコードが登録されているDNSサーバに問い合わせを 行うと、間違ったIPアドレスを参照するわけですから、問い合わせた 場所に対してアクセスができなくなります。

またそれは自組織のDNSサーバにキャッシュされるのでキャッシュが 消えるまでは、アクセスができません。ちなみにこれをみつけるには digを10台のサーバに対して行い、10ヶ所の情報をしっかりと 見比べる必要があります。微妙にアドレスが違ってたりすると意外と 見落としがちなのでトラブル切り分け時は注意しましょう。

ちなみに私が経験した中で一番あきれたのが7台あるDNSサーバ中 6ヶ所が間違った情報が登録されており、1ヶ所だけ正しい情報が 登録されているサーバがありました・・・

8)他組織からはhttp://www.xxx.xxx.jpのページが見えるといっているのに
自分の組織からだけ見えない

flagsのaaをチェックしましょう。

  • 自分の組織からdig @ns.xxx.xxx.jp. www.xxx.xxx.jpをやったら応答がない。
  • 他組織からdig www.xxx.xxx.jpをやったら応答がある。

たぶん他組織のdigの結果のflagsにはaaが付いてないはずです。 キャッシュで答えているんですね。こういった時は ns.xxx.xxx.jpのDNSサーバが落ちている可能性があります。

5.最後に

これであなたも立派なDNSトラブルシューター。がんばってください。 でも管轄外のDNSサーバのトラブルを発見したりすると、手が出せなくて すぐに問題解決にはならないのが歯がゆいんですけどね。
ちゃんちゃん。

Copyright 1999-2008 SYON Communications, Co. All rights reserved