こんにちは、フルスタックエンジニアのryuです。
今回の記事では、Non-authoritative answerについて解説したいと思います。結論から言うと、これはエラーではなく、名前解決自体は成功しています。
nslookupコマンドを実行すると表示される「Non-authoritative answer」とは一体なんなのでしょうか?直訳すると、”権威のない回答”となります。
この表示の意味を理解するには、権威あるDNSサーバーとキャッシュDNSサーバーの関係を知ることが近道です。これは名前解決ができているのかどうかも含めて、詳しく解説します。
Non-authoritative answerとはなんなのか?¶
Non-authoritative answerとは、nslookupコマンドを実行した際に表示されるものです。Windowsの日本語環境では、権限のない回答という表示になります。
例えば、以下のようにnslookupコマンドを実行した場合に表示されます。

これは、DNSクエリに対する応答が、そのドメインの権威あるDNSサーバーから直接提供されたものではないことを示す用語です。
ここで、権威あるDNSサーバーという単語が出てきました。権威あるDNSサーバーとはなんなのでしょうか?
権威あるDNSサーバーとは?¶
権威あるDNSサーバーとは、特定のドメイン名に対する公式な情報を持っているDNSサーバーのことです。つまり、そのドメイン名のゾーンファイルを管理しているDNSサーバーのことです。
例えば、www.test.comの名前解決ができるDNSサーバーは、test.comドメインに対して権威あるDNSサーバーとなります。
ドメインの管理者が登録した大元の情報を持っているため、その回答には権威がある、という言い方をします。DNSサーバーの役割を基礎から復習したい方は、DNSサーバーの用途と仕組みを解説した記事もあわせてご覧ください。
権威のないDNSサーバーとは?¶
Non-authoritative answerとは、権威あるDNSサーバーからの応答ではないことをさします。つまり権威がないDNSサーバーからの応答となります。
ここで、権威のないDNSサーバーとは何を指すのでしょうか?
これは、キャッシュDNSサーバーやリゾルバのことです。以前に他のクエリで取得した情報をキャッシュに保存し、そのキャッシュされた情報を基に応答を返しています。
身近な例では、自宅のルーターやプロバイダーのDNSサーバー、GoogleのパブリックDNSである8.8.8.8などが該当します。普段の名前解決は、ほとんどがこうしたキャッシュDNSサーバー経由で行われています。
キャッシュされた情報は一時的なものであり、元の権威あるDNSサーバーからの最新情報ではない可能性があります。
2種類のサーバーの違いを、表で整理しておきましょう。
| 比較項目 | 権威あるDNSサーバー | キャッシュDNSサーバー |
|---|---|---|
| 持っている情報 | ゾーンファイルの大元の情報 | 過去の問い合わせで得たコピー |
| 応答の表示 | Authoritative answer | Non-authoritative answer |
| 情報の鮮度 | 常に最新 | TTLが切れるまで古い場合がある |
| 代表例 | ドメインごとのネームサーバー | プロバイダーのDNSや8.8.8.8 |
この関係をおさえておくと、nslookupの表示がぐっと読み解きやすくなりますよ。
名前解決の流れとDNSサーバーの種類¶
Non-authoritative answerをより深く理解するために、名前解決の流れも簡単におさらいしておきましょう。
私たちがブラウザにURLを入力すると、PCはまずキャッシュDNSサーバーへ問い合わせます。このとき、キャッシュに答えが残っていれば、その内容がそのまま返されます。
キャッシュに答えがない場合は、キャッシュDNSサーバーが利用者の代わりに調査を始めます。ルートDNSサーバーから順にたどっていき、最終的に権威あるDNSサーバーへ行き着いて答えを手に入れる流れです。
名前解決に登場するサーバーの種類を、表でまとめておきます。
| サーバーの種類 | 役割 |
|---|---|
| ルートDNSサーバー | 名前解決の起点となり、TLDのDNSサーバーを案内する |
| TLDのDNSサーバー | .comや.jpなどを管理し、権威あるDNSサーバーを案内する |
| 権威あるDNSサーバー | ドメインの公式な情報を回答する |
| キャッシュDNSサーバー | 利用者の代わりに調査し、結果を一定期間記憶する |
こうして取得された答えは、キャッシュDNSサーバーの中にTTLの期間だけ保存されます。次に同じ問い合わせが来たとき、キャッシュから返される答えがNon-authoritative answerというわけです。
もともとは権威サーバーから取得した正しい答えでも、キャッシュとして再利用された時点で権威のない回答になります。この流れをイメージできると、nslookupの表示の意味がすっと腹落ちするのではないでしょうか。
Non-authoritative answerと表示されても名前解決はできているのか?¶
Non-authoritative answerと表示されると、名前解決ができているかどうか不安になる方もいるかもしれません。トラブルシューティングの最中なら、なおさら気になりますよね。
しかし、これはエラー文ではないので、名前解決自体はできています。
nslookupの結果にIPアドレスが表示されていれば、DNSは正しく機能しています。Non-authoritative answerは失敗の通知ではなく、回答の出どころを教えてくれているだけです。
しかし、さきほども記述したとおり、以前に他のクエリで取得し、保存されたキャッシュ情報を応答しているため、過去の情報の場合があります。
情報の新しさが重要になる場面では、後述する方法で権威あるDNSサーバーに直接問い合わせて確認しましょう。逆に言えば、普段の疎通確認であればNon-authoritative answerのままでまったく問題ありません。
なぜ権威のないDNSサーバーが応答するのか?¶
そもそも、なぜ毎回権威あるDNSサーバーが直接答えてくれないのでしょうか。疑問に思った方もいるのではないでしょうか。
実は、キャッシュDNSサーバーが間に入る仕組みには、ちゃんとした理由があります。
1つ目の理由は、応答の高速化です。権威あるDNSサーバーはインターネット上の遠い場所にあることが多く、毎回問い合わせていては時間がかかってしまいます。
手元に近いキャッシュDNSサーバーが記憶している答えを返せば、名前解決は一瞬で終わります。Webページの表示が速いのは、このキャッシュのおかげでもあるのです。
2つ目の理由は、権威あるDNSサーバーの負荷軽減です。世界中の利用者からのクエリがすべて権威サーバーへ集中すると、サーバーの負荷が大きくなりすぎてしまいます。
キャッシュDNSサーバーが各地で応答を肩代わりすることで、DNS全体が安定して動き続けられます。つまりNon-authoritative answerは、DNSがうまく分業できている証拠とも言えるわけです。
キャッシュがあるからこそ、インターネットは快適に使えています。権威のない回答という言葉の響きほど、悪いものではないのですね。
権威のある回答(Authoritative answer)を得る方法¶
ここからは、権威あるDNSサーバーから直接回答をもらう方法を解説します。レコードの変更が反映されたかを確認したいときなどに役立つ手順です。
流れはシンプルで、権威あるDNSサーバーを調べてから、そのサーバーを指定して問い合わせるだけです。
| 手順 | コマンド例 | 確認するポイント |
|---|---|---|
| 権威サーバーを調べる | nslookup -type=ns ドメイン名 |
NSレコードに載るサーバー名 |
| 直接問い合わせる | nslookup ドメイン名 権威サーバー名 |
Non-authoritative answerが消える |
| digで確かめる | dig @権威サーバー名 ドメイン名 |
フラグにaaが付く |
それでは、順番に見ていきましょう。
手順1: 権威あるDNSサーバーを調べる¶
まずは、対象ドメインの権威あるDNSサーバーを特定します。-type=nsオプションを付けて、NSレコードを問い合わせましょう。
$ nslookup -type=ns example.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
example.com nameserver = a.iana-servers.net.
example.com nameserver = b.iana-servers.net.
この例では、example.comの権威あるDNSサーバーがa.iana-servers.netとb.iana-servers.netだと分かります。NSレコードをはじめとしたレコードの種類は、DNSレコードの種類と設定方法の解説記事で詳しく紹介しています。
手順2: 権威あるDNSサーバーに直接問い合わせる¶
次に、調べた権威サーバーを指定して、同じドメインを問い合わせます。nslookupでは、ドメイン名の後ろに問い合わせ先のサーバーを指定できます。
$ nslookup example.com a.iana-servers.net
Server: a.iana-servers.net
Address: 199.43.135.53#53
Name: example.com
Address: 93.184.215.14
注目してほしいのは、出力からNon-authoritative answerの行が消えている点です。権威あるDNSサーバーから直接回答をもらえたため、この表示が付かなくなりました。
なお、表示されるIPアドレスは実行する時期や環境によって変わる可能性があります。手元で試すときは、確認したいドメインに読み替えて実行してみてください。
digコマンドで権威のある回答を確認する方法¶
nslookupだけでなく、digコマンドでも同じ確認ができます。Linuxの現場では、より詳細な情報が得られるdigの利用が推奨される場面も多いです。
digでは、@の後ろに問い合わせ先のサーバーを指定します。権威あるDNSサーバーを指定して実行してみましょう。
$ dig @a.iana-servers.net example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
注目するのは、flagsの部分に表示されるaaです。これはAuthoritative Answerの略で、権威あるDNSサーバーからの回答であることを示しています。
逆に、キャッシュDNSサーバー経由で問い合わせたときは、aaフラグは付きません。nslookupのNon-authoritative answerと同じことを、digはフラグで表現しているわけですね。
また、dig ドメイン名 +traceを使うと、ルートサーバーから権威サーバーまで、問い合わせの経路をたどって表示できます。名前解決の流れを目で追える教材としても優秀なので、ぜひ一度試してみてください。
もしコマンドを実行してnslookup: command not foundと表示された場合は、パッケージの追加が必要です。対処方法はnslookupコマンドが無い場合の対処方法にまとめています。
TTLとレコード変更時の注意点¶
Non-authoritative answerで注意が必要になるのは、DNSレコードを変更した直後です。キャッシュには有効期限があり、その期限をTTLと呼びます。
たとえば、Aレコードを変更したとしても、キャッシュが10分間ある場合を想定してみましょう。この場合、直接権威あるDNSサーバーに問い合わせを行なうと、変更後のIPアドレスが返されます。
しかし、権威のないDNSサーバーに問い合わせを行なうと、キャッシュが残っている10分間は変更前のIPアドレスが返されてしまいます。問い合わせる相手によって、返ってくる答えが変わるわけです。
このように、動作の違いが発生する場合があるので、Non-authoritative answerと表示された場合は、すこし注意しておきましょう。サーバー移転の直後に古いサーバーへアクセスが流れてしまうのも、このキャッシュが原因です。
また、DNSを運用する方で、レコードの変更をする際は、キャッシュの時間(TTL)を意識して設定しましょう。よく使われるのは、変更の前にあらかじめTTLを短くしておく方法です。
| タイミング | やっておくこと |
|---|---|
| 変更の数日前 | TTLを短い値に下げておく |
| 変更当日 | レコードを書き換えて反映を確認する |
| 反映の確認後 | TTLを元の値に戻す |
TTLを短くしておけば古いキャッシュが早く消えるため、切り替えの影響を最小限にできます。反映の確認には、先ほど紹介した権威サーバーへの直接問い合わせが活躍しますよ。
Non-authoritative answerに関するよくある疑問¶
最後に、Non-authoritative answerについてよく聞かれる疑問をまとめておきます。気になるところから読んでみてください。
Windowsで権限のない回答と表示されるのはなぜ?¶
Windowsのnslookupでは、Non-authoritative answerが日本語で権限のない回答と表示されます。英語表示と日本語表示の違いだけで、意味はまったく同じです。
権限のない回答と出ても、名前解決は成功しています。エラーだと勘違いして設定を見直し始める前に、まずはIPアドレスが返っているかを確認しましょう。
Non-authoritative answerを消す方法はある?¶
表示そのものを消す設定は、nslookupにはありません。権威あるDNSサーバーへ直接問い合わせれば、結果的にこの表示は付かなくなります。
そもそもこの表示は異常ではないため、無理に消す必要もありません。回答の出どころを示すただの情報として、落ち着いて受け止めれば大丈夫です。
nslookupとdigはどちらを使えばいい?¶
Windowsで手軽に確認するならnslookup、Linuxで詳しく調べるならdigがおすすめです。digはフラグやTTLなど、応答の詳細な情報まで表示してくれます。
Linux界隈ではdigの利用が推奨されることも多いですが、nslookupも現在まで広く使われている標準的なツールです。両方の基本操作を覚えておくと、どの環境でも困りません。
権威あるDNSサーバーは自分で構築できる?¶
はい、Linuxとbindを使えば自分でも構築できます。自分で建てた権威サーバーに直接問い合わせると、権威のある回答が返ってくる様子を体験できます。
構築手順はbindでDNSサーバーを構築する手順の解説で紹介しています。キャッシュ経由の応答との違いを見比べると、この記事の内容が一気に実感へ変わりますよ。
資格試験でも出題される?¶
DNSサーバーの役割は、基本情報技術者試験でも定番の出題テーマです。権威サーバーとキャッシュサーバーの違いを理解しておくと、得点源にできます。
過去問を使った解説はDNSサーバが果たす役割を扱った基本情報の過去問講座をご覧ください。LPICを目指す方も、nslookupやdigの操作は必ずおさえておきましょう。
まとめ¶
今回は、DNSで名前解決をする際に表示されるNon-authoritative answerについて解説しました。
Non-authoritative answerは、キャッシュDNSサーバーからの応答という意味で、エラーではありませんでしたね。名前解決はできていますが、TTLが切れるまでは古い情報が返る可能性がある点だけ注意が必要でした。
権威のある回答を確かめたいときは、nslookup -type=nsで権威サーバーを調べて、直接問い合わせてみてください。digのaaフラグでの確認方法も、あわせて覚えておくと現場で役立ちます。
ちょっとした文章でも、調べてみると、動作が違うことが分かります。Linuxコマンドを実行した後に表示される内容は注意深くみておきましょう。
DNSをさらに深く学びたい方は、DNS入門講座のまとめ記事から順番に読み進めるのがおすすめです。
当ブログでは、このようなLinuxやネットワークなどのインフラエンジニアにためになる知識を発信しているので興味のある方は引き続きご覧ください。Linux入門講座(全8回)やLinux中級講座(全8回)も用意しているので、手を動かしながら学びたい方はぜひ挑戦してみてください。