DNSサーバーとは、example.comのようなドメイン名を、通信に使うIPアドレスに変換するサーバーです。人はドメイン名でサイトを開きますが、実際の通信はIPアドレス宛に行われるため、その間を取り持つ役割が必要になります。仕組みの説明だけ読んでも実感が湧きにくいので、この記事ではUbuntu 24.04（dig 9.18）で実際に実行した出力を並べながら解説します。まずは、いま自分の環境がどのDNSサーバーに問い合わせているかを確認してみてください。
dig example.com | grep SERVER;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)この記事では、DNSサーバーの仕組みと種類、Linuxでの確認・変更方法、そして「DNSが原因かどうか」を切り分ける手順までを、コマンドの実行結果つきでまとめます。
DNSサーバーとは｜ドメイン名をIPアドレスに変換する仕組み
DNSは Domain Name System の略で、ドメイン名とIPアドレスの対応を管理する仕組み全体を指します。その仕組みを構成する個々のサーバーがDNSサーバーです。「インターネットの電話帳」と例えられることが多く、名前（ドメイン名）から番号（IPアドレス）を引く役割を担います。
ドメイン名からIPアドレスを求める処理を名前解決と呼びます。実際に何が返ってくるかは、digコマンドで直接確認できます。
dig example.com A +noall +answerexample.com. 152 IN A 172.66.147.243
example.com. 152 IN A 104.20.23.154左から順に、ドメイン名・TTL（秒）・クラス・レコード種別・値です。この例ではexample.comに2つのIPアドレスが割り当てられており、TTLは152秒。TTLは「この答えを何秒間キャッシュしてよいか」を示す寿命で、DNS変更が反映されるまでの待ち時間を左右します。
名前解決が行われる4つのステップ
ブラウザにURLを入力してからIPアドレスが判明するまでの流れは、大きく4段階です。この問い合わせは通常UDPの53番ポートで行われ、応答が大きい場合だけTCPに切り替わります（TCPとUDPの違いを実測で解説｜パケット数・ヘッダ・確認コマンドで、digがどちらを使ったか確認する方法を扱っています）。
- 端末が、設定されているDNSサーバー（多くはプロバイダやルーターのもの）に問い合わせる
- そのDNSサーバーがキャッシュを持っていれば即答する
- キャッシュが無ければ、ルートサーバー → TLDサーバー（
.comや.org）→ ドメインの権威サーバー、と順にたどる - 得られたIPアドレスを端末に返し、同時にTTLの間だけキャッシュとして保持する
この3段目の「たどる」様子は、dig +traceで実際に目視できます。後述の「階層をたどる」の節で実行結果を示します。
DNSサーバーの種類｜キャッシュDNSと権威DNSの違い
「DNSサーバー」と一括りにされますが、役割はまったく異なる2種類に分かれます。トラブル対応でどちらを疑うべきかが変わるため、ここは押さえておく価値があります。
| 種類 | 別名 | 役割 | 設定・運用する人 |
|---|---|---|---|
| キャッシュDNSサーバー | フルサービスリゾルバ／フルリゾルバ | 利用者の問い合わせを受け、代わりに階層をたどって答えを探し、結果をキャッシュする | プロバイダ、社内インフラ、公開DNS事業者 |
| 権威DNSサーバー | ネームサーバー／コンテンツサーバー | 自分が管理するドメインのゾーン情報（Aレコード等）を保持し、正式な答えを返す | ドメイン所有者、レジストラ、DNSホスティング |
権威DNSサーバーはさらに、ゾーン情報の原本を持つプライマリ（マスター）と、そのコピーを保持して冗長化するセカンダリ（スレーブ）に分かれます。ドメイン登録時に「ネームサーバーを2つ以上指定してください」と求められるのは、このセカンダリを用意させるためです。
flagsを見れば、どちらのサーバーか判別できる
digの応答ヘッダーにあるflagsを読むと、返してきたサーバーがキャッシュDNSか権威DNSかがわかります。まずGoogle Public DNS（キャッシュDNS）に問い合わせた場合です。
dig @8.8.8.8 iana.org +noall +comments | grep -E 'flags|status';; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58000
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1次に、iana.orgの権威DNSサーバーに直接問い合わせた場合です。
dig @a.iana-servers.net iana.org +noall +comments | grep -E 'flags|status';; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11009
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1違いはaaとraの有無です。
| フラグ | 意味 | 読み取れること |
|---|---|---|
aa | Authoritative Answer | 権威DNSサーバーが自分の管理するゾーンから答えた（＝正式な答え） |
ra | Recursion Available | 再帰問い合わせを受け付ける＝キャッシュDNSサーバーとして動作している |
rd | Recursion Desired | digが「代わりに調べてほしい」と要求した（送信側の希望） |
ad | Authenticated Data | DNSSECによる検証に成功している |
qr | Query Response | このパケットが応答であることを示す |
権威DNSサーバーは「自分の担当ドメイン以外は答えない」のが原則です。担当外を聞くとREFUSEDが返ります。
dig @a.iana-servers.net google.com +noall +comments | grep status;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9282自分で権威DNSサーバーを立てたとき、意図せず担当外のドメインまで再帰的に答えてしまう設定はオープンリゾルバと呼ばれ、DDoS攻撃の踏み台にされます。このREFUSEDが返る状態は、むしろ正しく閉じられている証拠です。
ルート→TLD→権威の階層をたどる
キャッシュDNSサーバーが答えを探す道筋は、dig +traceで再現できます。
dig +trace iana.org. 509274 IN NS a.root-servers.net.
. 509274 IN NS b.root-servers.net.
（中略：ルートサーバーは a〜m の13系統）
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS b2.org.afilias-nst.org.
（中略：.org を管理するTLDサーバー）
iana.org. 86400 IN NS a.iana-servers.net.
iana.org. 86400 IN NS b.iana-servers.net.
iana.org. 86400 IN NS c.iana-servers.net.
iana.org. 86400 IN NS ns.icann.org.ルート（.）が「.orgのことはこのサーバーに聞け」と教え、TLDサーバーが「iana.orgのことはこのサーバーに聞け」と教える。この受け渡しを委任と呼びます。委任だけを取り出して見ることもできます。
dig @a0.org.afilias-nst.info iana.org +noall +authorityiana.org. 3600 IN NS ns.icann.org.
iana.org. 3600 IN NS b.iana-servers.net.
iana.org. 3600 IN NS a.iana-servers.net.
iana.org. 3600 IN NS c.iana-servers.net.ここに表示されるNSレコードが、上位から見た「正しい委任先」です。ドメイン移管やDNSホスティング変更のトラブルでは、この上位側の委任と、実際に運用している権威サーバーがズレていることがよくあります。
キャッシュが効いていることを確かめる
キャッシュDNSサーバーが答えを保持している間、TTLは秒単位で減っていきます。同じ問い合わせを繰り返すとTTLの値が変わるのはそのためです。
for i in 1 2 3; do dig @1.1.1.1 iana.org +noall +answer; sleep 2; doneiana.org. 2651 IN A 192.0.43.8
iana.org. 1121 IN A 192.0.43.8
iana.org. 1947 IN A 192.0.43.8ここで注意したいのが、値が単純に減っていない点です。1.1.1.1や8.8.8.8のような公開DNSはエニーキャストで世界中に多数のサーバーが分散配置されており、問い合わせのたびに別のインスタンスへ届くことがあります。それぞれが独立したキャッシュを持つため、TTLの残りがバラつきます。「DNSレコードを変更したのに、リロードすると新旧の結果が入れ替わる」現象の一因はこれです。
DNSレコードの主な種類と確認コマンド
権威DNSサーバーが保持している情報は、レコードという単位で管理されます。よく使うものは次の通りです。
| 種別 | 内容 | 確認コマンド |
|---|---|---|
| A | ドメイン名に対応するIPv4アドレス | dig +short A example.com |
| AAAA | IPv6アドレス | dig +short AAAA iana.org |
| CNAME | 別のドメイン名への別名（エイリアス） | dig www.iana.org +noall +answer |
| MX | メール受信サーバーと優先度 | dig +short MX gmail.com |
| NS | そのドメインの権威DNSサーバー | dig +short NS iana.org |
| TXT | 任意の文字列。SPFやドメイン所有確認に使う | dig +short TXT iana.org |
| SOA | ゾーンの管理情報（シリアル、TTL既定値など） | dig +short SOA iana.org |
| PTR | IPアドレスからドメイン名を引く逆引き | dig +short -x 192.0.43.8 |
CNAMEは実務で誤解が多いレコードです。実際の応答を見ると、CNAMEが張られている場合はAレコードが「別名の先」に付いていることがわかります。
dig www.iana.org +noall +answerwww.iana.org. 2051 IN CNAME www.iana.org.cdn.cloudflare.net.
www.iana.org.cdn.cloudflare.net. 184 IN A 104.18.24.232
www.iana.org.cdn.cloudflare.net. 184 IN A 104.18.25.232この例ではwww.iana.org自身にAレコードは無く、CDNのドメインへ転送されています。TTLもCNAME側（2051秒）とA側（184秒）で別々です。「Aレコードを直したのに反映されない」というときは、まずCNAMEが挟まっていないかを疑ってください。
SOAレコードのシリアル番号は、ゾーン情報を更新した回数（多くは日付形式）を示します。プライマリとセカンダリでこの値が食い違っていれば、ゾーン転送が失敗している可能性が高いと判断できます。
dig +short SOA iana.orgsns.dns.icann.org. noc.dns.icann.org. 2026072705 7200 3600 1209600 3600digの詳しいオプションはdig – DNS情報を問い合わせるコマンドにまとめています。
自分が使っているDNSサーバーを確認する方法
Linuxで「いまどのDNSサーバーを参照しているか」を調べる方法は複数あり、環境によって正解が変わります。順に見ていきます。
/etc/resolv.confを見る（基本）
cat /etc/resolv.confnameserver 127.0.0.1nameserver行に書かれているのが問い合わせ先です。ここが127.0.0.1や127.0.0.53のようなループバックアドレスになっている場合、実際の問い合わせ先はこのファイルには書かれていません。ローカルで動くDNSサービス（systemd-resolved、dnsmasq、Unboundなど）が窓口になっていて、その先の転送先は別の設定にあります。誰が53番ポートを握っているかはssで確認できます。
sudo ss -lntup 'sport = :53'resolvectlで確認する（systemd-resolved環境）
Ubuntu 18.04以降のデスクトップや標準的なサーバー構成では、systemd-resolvedが名前解決を担っています。この場合はresolvectlが最も情報量の多い確認方法です。
resolvectl status
resolvectl dnsただし、systemd-resolvedが動いていない環境では次のように失敗します。コマンドが存在するかどうかと、サービスが動いているかどうかは別問題です。
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.このメッセージが出たら、まずサービスの状態を確認してください。
systemctl is-active systemd-resolvedinactiveinactiveなら、名前解決は/etc/resolv.confに書かれたサーバーへglibcが直接問い合わせています。systemd-resolvedを前提にした解説記事の手順（キャッシュクリアなど）はそのままでは通用しません。
digのSERVER行が最も確実
設定ファイルを読み解くより、実際に問い合わせて「どこが答えたか」を見るほうが確実です。
dig example.com | grep -E 'SERVER|Query time';; Query time: 14 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)このSERVER行が、digが実際に問い合わせた相手です。設定ファイルの記述と食い違っていたら、そちらが古い、あるいは別の仕組みで上書きされていると判断できます。
nslookup・host・getentでも確認できる
digが入っていない環境では、次のコマンドが代わりになります。それぞれ見え方が違います。
host iana.org
nslookup iana.org
getent hosts iana.orgiana.org has address 192.0.43.8
iana.org has IPv6 address 2001:500:88:200::8
iana.org mail is handled by 10 pechora1.icann.org.
（中略）
Non-authoritative answer:
Name: iana.org
Address: 192.0.43.8
Name: iana.org
Address: 2001:500:88:200::8
2001:500:88:200::8 iana.orgここには重要な違いがあります。dig・host・nslookupはDNSサーバーに直接問い合わせるのに対し、getent hostsは/etc/nsswitch.confの順序に従うため、/etc/hostsの記述を先に見ます。
grep ^hosts /etc/nsswitch.confhosts: files mdns4_minimal [NOTFOUND=return] dnsfiles（＝/etc/hosts）がdnsより前にあります。つまりアプリケーションが実際に使う名前解決の結果はgetentのほうで、digが正しい答えを返しているのにブラウザやcurlだけ古いIPに繋がる場合は、/etc/hostsに残骸が残っている可能性が高い、と切り分けられます。使い分けはnslookup – Linuxで使うDNS問い合わせコマンドの使い方とhost – シンプルなDNS問い合わせコマンドも参考にしてください。
Windows・macOSでの確認方法
| OS | コマンド |
|---|---|
| Windows | ipconfig /all（「DNSサーバー」の行を確認） |
| Windows | nslookup（起動時に表示されるServerが参照先） |
| macOS | scutil --dns／networksetup -getdnsservers Wi-Fi |
DNSサーバーを変更・設定する方法（Linux）
参照するDNSサーバーの変更は、環境によって編集すべき場所が違います。/etc/resolv.confを直接編集しても、多くの環境では再起動時に元に戻ります。実際、多くのUbuntu環境ではこのファイルはシンボリックリンクです。
ls -l /etc/resolv.conflrwxrwxrwx 1 root root 28 Aug 1 09:15 /etc/resolv.conf -> /opt/valet-linux/resolv.confリンク先を確認すれば、誰がこのファイルを生成しているかがわかります。/run/systemd/resolve/配下ならsystemd-resolved、/run/NetworkManager/配下ならNetworkManagerが管理者です。それに応じて設定場所を選びます。
| 管理している仕組み | 編集する場所 | 反映コマンド |
|---|---|---|
| netplan（Ubuntuサーバー） | /etc/netplan/*.yamlのnameservers | sudo netplan apply |
| NetworkManager（デスクトップ） | nmcliで接続設定を変更 | sudo nmcli connection up <接続名> |
| systemd-resolved | /etc/systemd/resolved.confのDNS= | sudo systemctl restart systemd-resolved |
| いずれも無い最小構成 | /etc/resolv.confを直接編集 | 不要（即時反映） |
netplanで設定する（Ubuntuサーバー）
network:
version: 2
ethernets:
eth0:
dhcp4: true
nameservers:
addresses: [8.8.8.8, 1.1.1.1]DHCPからDNSサーバーが配られる環境では、上の指定が無視されることがあります。その場合はdhcp4-overridesでuse-dns: falseを併記してください。編集後は、適用前に構文を確認するのが安全です。
sudo netplan generate # 構文チェックのみ
sudo netplan try # 120秒後に自動で元に戻る（SSH断の保険）
sudo netplan applyリモートのサーバーで作業する場合、netplan tryを使うと設定ミスで接続を失っても自動で巻き戻ります。いきなりapplyしないことをおすすめします。
nmcliで設定する（NetworkManager環境）
nmcli connection show # 接続名を確認
sudo nmcli connection modify "接続名" ipv4.dns "8.8.8.8 1.1.1.1"
sudo nmcli connection modify "接続名" ipv4.ignore-auto-dns yes
sudo nmcli connection up "接続名"ipv4.ignore-auto-dns yesを忘れると、DHCPから配られたDNSサーバーが手動指定より優先されたままになります。設定後は先ほどのdigのSERVER行で、実際に切り替わったかを必ず確認してください。
変更が反映されたか確認する
dig example.com | grep SERVER設定ファイルを書き換えただけでは反映されていないことがあるため、この1行での確認を習慣にすると事故が減ります。
DNSサーバーが原因かを切り分ける手順
「サイトが開かない」ときにDNSが原因かどうかは、応答コード（status）で判断できます。まず現状のstatusを取ります。
dig +noall +comments example.com | grep -o 'status: [A-Z]*'| status | 意味 | 次にやること |
|---|---|---|
NOERROR | 名前解決は成功している | DNS以外を疑う（経路、ポート、Webサーバー、TLS） |
NXDOMAIN | そのドメインは存在しない | 綴り、サブドメインの有無、ドメインの有効期限を確認 |
SERVFAIL | 問い合わせ先が答えを出せなかった | 権威サーバーの障害、DNSSEC検証失敗、上流の不調を疑う |
REFUSED | 問い合わせ自体を拒否された | そのサーバーが担当外か、アクセス制限をかけている |
| （応答なし） | タイムアウト | 53番ポートの遮断、DNSサーバーの停止、経路断を疑う |
SERVFAILの例として、DNSSECの署名が意図的に壊してある検証用ドメインを問い合わせるとこうなります。
dig @8.8.8.8 dnssec-failed.org +noall +comments | grep status;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54476外部DNSと比べて「自分側かサイト側か」を確定させる
切り分けで最も効くのが、いま使っているDNSサーバーと、外部の公開DNSの結果を比べることです。
dig +short example.com # いまの設定で問い合わせ
dig @8.8.8.8 +short example.com # Google Public DNS
dig @1.1.1.1 +short example.com # Cloudflare DNS| いまのDNS | 外部DNS | 判断 |
|---|---|---|
| 失敗 | 成功 | 自分側（設定・キャッシュ・ルーター・プロバイダのDNS）が原因 |
| 失敗 | 失敗 | サイト側（権威DNS、ドメイン設定）が原因 |
| 成功 | 成功 | DNSは正常。以降の通信（経路・ポート・Webサーバー）を調べる |
| 成功 | 失敗 | 古いキャッシュが残っているか、社内DNSが独自の答えを返している |
「DNSは正常」と判明したら、次は経路とポートの調査に移ります。手順は接続不良の原因を特定！ネットワークトラブルシュートの基本コマンド一覧とLinuxのtracerouteコマンド使い方にまとめています。逆にブラウザにDNS_PROBE_FINISHED_NXDOMAINが出ている場合は、DNS_PROBE_FINISHED_NXDOMAINの原因と直し方で個別に解説しています。
応答速度でDNSサーバーを選ぶ
公開DNSはどれも無料で使えますが、回線や地域によって応答速度が変わります。実測してから選ぶのが確実です。
for s in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
printf "%-16s " "$s"
dig @"$s" +noall +stats iana.org | grep -oE 'Query time: [0-9]+ msec'
done8.8.8.8 Query time: 11 msec
1.1.1.1 Query time: 15 msec
9.9.9.9 Query time: 15 msec
208.67.222.222 Query time: 113 msecこの環境では最後の1つだけ明確に遅い結果になりました。値はネットワーク環境で大きく変わるので、必ず自分の回線で測ってください。代表的な公開DNSは次の通りです。
| サービス | プライマリ | セカンダリ | 特徴 |
|---|---|---|---|
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | 広く使われ、切り分けの基準にしやすい |
| Cloudflare DNS | 1.1.1.1 | 1.0.0.1 | プライバシー重視をうたう |
| Quad9 | 9.9.9.9 | 149.112.112.112 | 悪性ドメインをブロックする |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | フィルタリング機能を持つ |
なお、Quad9やOpenDNSはフィルタリングを行うため、切り分け目的で使うと「ブロックされているだけ」を障害と誤認することがあります。純粋な切り分けには8.8.8.8や1.1.1.1を使うほうが確実です。
自前でDNSサーバーを立てる場合の選択肢
社内向けの名前解決や、自分のドメインの権威DNSを自前で運用したい場合の代表的なソフトウェアです。用途を取り違えると必要以上に複雑な構成になるため、まず役割から選びます。
| ソフトウェア | 主な役割 | 向いている用途 |
|---|---|---|
| dnsmasq | キャッシュDNS＋DHCP | 小規模LAN、開発環境、Raspberry Pi |
| Unbound | キャッシュDNS（フルリゾルバ） | 社内の共有リゾルバ、DNSSEC検証 |
| BIND 9 | 権威DNS＋キャッシュDNS | 本格的なゾーン運用、機能が最も豊富 |
| NSD | 権威DNS専用 | 権威に特化して軽量・堅牢に運用したい場合 |
| PowerDNS | 権威DNS（DB連携）／リゾルバ | レコードをRDBやAPIで管理したい場合 |
インターネット向けに権威DNSを公開する場合は、再帰問い合わせを必ず無効にしてください。前述のオープンリゾルバ状態は、DNSリフレクション攻撃の踏み台として悪用されます。設定後は、担当外ドメインを問い合わせてREFUSEDが返ることを確認するのが手軽なチェックになります。
また、権威DNSは1台構成にしないのが原則です。プライマリとセカンダリを別ネットワークに置き、SOAのシリアル番号が両者で一致しているかを定期的に確認します。
for ns in $(dig +short NS example.com); do
printf "%-30s " "$ns"
dig @"$ns" +short SOA example.com | awk '{print $3}'
donehera.ns.cloudflare.com. 2410849323
elliott.ns.cloudflare.com. 2410849323出力されたシリアル番号がすべて揃っていれば、ゾーン転送は正常です。1台だけ古い番号なら、そのセカンダリへの転送が失敗しています。
よくある質問
Q. DNSサーバーとネームサーバーは同じものですか？
ほぼ同義で使われますが、厳密には「ネームサーバー」は権威DNSサーバーを指すことが多い用語です。ドメイン登録画面で「ネームサーバーの設定」と表示されるのは、そのドメインの権威DNSサーバーを指定する操作を意味します。一方、端末側の設定で「DNSサーバー」と言えば、通常はキャッシュDNSサーバーのことです。
Q. DNSの変更が反映されるまでどれくらいかかりますか？
目安は変更前のレコードに設定されていたTTLの時間です。TTLが3600なら最大1時間、キャッシュが残っている経路では古い答えが返り続けます。計画的な変更なら、切り替えの数日前にTTLを300秒程度まで下げておき、切り替え後に戻すと影響を短くできます。
Q. DNSキャッシュをクリアしたいのですが、コマンドが失敗します
Linuxの場合、OS自体はDNSキャッシュを持ちません。キャッシュを持つのはsystemd-resolvedやdnsmasqといった常駐サービスのほうです。そのため、これらが動いていない環境でresolvectl flush-cachesを実行してもUnit dbus-org.freedesktop.resolve1.service not foundで失敗します。まずsystemctl is-active systemd-resolvedで稼働状況を確認し、動いていなければクリアすべきキャッシュ自体が存在しない、と判断してください。ブラウザは独自のキャッシュを持つため、そちらは別途クリアが必要です。
Q. digでは正しいIPが返るのに、ブラウザが古いサイトを表示します
digはDNSサーバーへ直接問い合わせますが、アプリケーションは/etc/hostsを先に参照します。getent hosts ドメイン名を実行し、digと違う結果が返るなら/etc/hostsに古い記述が残っています。それも同じ結果なら、ブラウザ自身のキャッシュかCDN側のキャッシュを疑ってください。
Q. 会社のDNSサーバーを勝手に8.8.8.8へ変えてもよいですか？
おすすめしません。社内DNSは、社内サーバーのプライベートIPを返す内部専用のレコードを持っていることが多く、外部DNSへ切り替えると社内システムに接続できなくなります。切り分けのために一時的にdig @8.8.8.8で問い合わせるのは問題ありませんが、端末の設定そのものを変えるのは避けてください。
Q. digコマンドが見つかりません
digは単体パッケージではなく、DNSユーティリティ群に含まれています。Ubuntu/Debianならsudo apt install dnsutils、RHEL系ならsudo dnf install bind-utilsでインストールできます。インストールできない環境では、標準で入っていることが多いgetent hostsやpython3のsocketモジュールで代用してください。
Q. DNSサーバーは自分で用意しないといけませんか？
一般的なWebサイト運用では不要です。ドメイン登録事業者やレンタルサーバー、クラウド事業者が権威DNSを提供しており、管理画面からレコードを追加するだけで済みます。自前で立てる価値があるのは、社内向けの独自ゾーンを持つ場合や、レコードを大量に自動生成したい場合です。
まとめ
DNSサーバーの要点を整理します。
- DNSサーバーはドメイン名とIPアドレスを対応づけるサーバーで、役割はキャッシュDNSと権威DNSの2種類に分かれる
- どちらが答えたかは、digの
flagsにあるaa（権威）とra（再帰可能）で判別できる - 自分の参照先は
dig ドメイン名 | grep SERVERで確認するのが最も確実。設定ファイルは上書きされていることがある - 設定変更はnetplan・nmcli・resolved.confのどれが管理しているかを見極めてから行う
- 障害時は
status（NOERROR / NXDOMAIN / SERVFAIL / REFUSED）と外部DNSとの比較で、自分側かサイト側かを先に確定させる
設定ファイルを読むより、まず1コマンド実行して応答を見るほうが早く正確です。困ったらdigから始めてください。
関連記事
- dig – DNS情報を問い合わせるコマンド
- nslookup – Linuxで使うDNS問い合わせコマンドの使い方
- host – シンプルなDNS問い合わせコマンド
- DNS_PROBE_FINISHED_NXDOMAINの原因と直し方｜digで切り分ける
- サイトに繋がらない時の原因調査｜IPアドレス確認とnslookup・dig活用法
- 接続不良の原因を特定！ネットワークトラブルシュートの基本コマンド一覧
- LinuxでIPアドレスを確認する方法｜ip・hostname・nmcliコマンド
- Linuxのホスト名を確認する方法まとめ
- FQDNとは？ドメイン名・ホスト名との違いと確認コマンドを実例で解説
- Linuxのtracerouteコマンド使い方｜経路調査とオプション一覧
- Linuxトラブルシューティング総合ハブ
コメント