再帰DNSと権威DNSの役割

端末がwww.acme.exampleのIPアドレスを調べるとき、スタブリゾルバ、社内の再帰DNS、ルート側と委任先の権威DNSは同じ問い合わせを別の役割で扱います。ログのRD・RA・AA、Answer・Authority・Additional、TTL、RCODEを読み分けると、正常な名前解決、キャッシュ、設定障害、不審な応答を切り分けられます。この記事はSC科目B（午後）向けに、一件の名前解決を構成から調査・復旧まで追います。以下のacme.exampleとIPアドレス、ログは説明用の架空の構成で、実在のDNS階層には問い合わせできません。

読み順は、①各DNSの役割、②一件の再帰・反復問い合わせ、③キャッシュとレコード、④失敗応答と通信方式、⑤攻撃・運用・演習です。ログを読む際は、まず観測点と時刻、次にQNAME・QTYPE、最後にフラグと応答内容を確認してください。

1. 登場人物：端末から権威DNSまで

スタブリゾルバ：端末のOSやアプリが利用する簡易な名前解決機能。通常は設定された再帰DNSへ回答を依頼し、ルートから順に委任をたどる役割を引き受けない。端末・ブラウザが独自キャッシュを持つ場合は、OSへの問い合わせが毎回生じるとは限らない。
再帰DNS（フルサービスリゾルバ）：利用者から最終回答を求められ、キャッシュにあれば返す。なければ権威DNSをたどるか、転送先の再帰DNSへ依頼する。この記事の社内再帰DNSは10.0.0.53。
キャッシュDNS：取得したRRsetや否定応答を有効期限内に保持する機能に注目した呼び方。再帰DNSと同じサーバが兼ねることが多く、「キャッシュDNS」という別の必須ホップが増えるわけではない。
権威DNS：自分が管理するゾーンの正本データに基づいて答えるサーバ。acme.exampleの権威DNSは192.0.2.53と仮定する。利用者のために無関係なドメインを再帰解決する役割とは分ける。
親ゾーンの権威DNS：委任先をNSで示す。この記事では文書用IPの192.0.2.1を架空のルート、192.0.2.2を架空のexample側の権威DNSとする。

DNSはドメイン名の階層をたどります。www.acme.example. の末尾の点はルートを含む完全修飾名を示し、左からwwwというホスト名、acme.exampleというゾーン名、exampleという上位名へ分けて考えます。実際の設定では検索サフィックスが補われ、入力した短い名前とDNSへ送信したQNAMEが異なることもあります。

再帰DNSと権威DNSの役割

1. 最終回答を依頼
2. 委任先を調べる
3. acmeの委任先を調べる
4. wwwのAを照会

矢印は問い合わせを送る向き。端末は社内再帰DNSへ依頼し、再帰DNSが各権威DNSへ順に問い合わせる架空の階層。

図の矢印は質問を送る方向です。ルートとexampleの権威DNSは次の委任先のNSと必要なglueを再帰DNSへ返し、再帰DNSがその権威DNSへ次の質問を送ります。社内再帰DNSが外部のフォワーダへ依頼する構成なら、ルートへ直接問い合わせるのはフォワーダ側です。

2. DNSメッセージを読むための最小単位

2-1. 質問・レコード・応答欄

QNAME：調べたい名前。例はwww.acme.example.。QTYPEはA、AAAA、NSなど調べたいレコード種類。QCLASSは通常IN。QNAMEが同じでもAとAAAAは別の質問。
Question：質問内容。Answer：質問への回答に当たるRRsetやCNAMEなど。Authority：委任を示すNSや否定応答に添えるSOAなど。Additional：委任先のアドレスを示すglue等の補助情報。
RR（リソースレコード）：所有名、TTL、Class、Type、RDATAで表す。例の「www.acme.example. 300 IN A 203.0.113.80」では300がTTL、AがIPv4アドレスの型。
RRset：同じ所有名・Class・Typeのレコード集合。複数Aが返ったときは一つのRRsetとしてキャッシュ・検証する。ログの行数が常に一つとは限らない。
ID：質問と応答を結ぶ16ビットの値。UDPでは送信元・宛先IP、ポート、質問内容なども突き合わせる。IDだけで正しい相手の応答と認定しない。

2-2. RD・RA・AA・TC・RCODE

RD（Recursion Desired）：問い合わせ側が再帰処理を望むビット。端末→再帰DNSでは通常1。再帰DNS→権威DNSの反復問い合わせでは通常0。
RA（Recursion Available）：応答側がその相手へ再帰サービスを提供できることを示す。RA=1はその質問でルートまで問い合わせた証拠ではない。キャッシュだけで回答しても1になり得る。
AA（Authoritative Answer）：応答サーバが該当回答について権威を持つことを示す。再帰DNSが権威DNSから得た結果をキャッシュして端末へ返す場合、通常AA=0。AA=1だけで応答の真正性は保証されない。
TC（Truncated）：応答が途中で切られた印。大きすぎるUDP応答でTC=1ならTCPで再問い合わせする可能性がある。DNSでTCP 53番を使うことはゾーン転送だけを意味しない。
RCODE：応答結果の種類。NOERRORは必ずしも指定QTYPEの答えがある意味ではない。NXDOMAINは質問名が存在しないという否定応答。SERVFAILは処理失敗、REFUSEDは方針などによる拒否。

RD、RA、AAは違う主体・違う性質の情報です。例えば端末がRD=1で送った質問に、社内再帰DNSがRA=1、AA=0で回答すれば再帰サービスを提供するサーバからの回答です。それがキャッシュ命中か権威DNSへの問い合わせ後かは、フラグだけでは判定できません。権威DNSがAA=1で答えたとしても、端末に届いた別サーバの回答まで自動的に権威付きにはなりません。

text

端末→再帰DNS: QNAME=www.acme.example. QTYPE=A RD=1
権威DNS→再帰DNS: RCODE=NOERROR AA=1 RA=0
再帰DNS→端末: RCODE=NOERROR RD=1 RA=1 AA=0
  Answer: www.acme.example. 300 IN A 203.0.113.80

最後のRD=1は元の質問で再帰を要求したことを示す応答上の値です。RA=1は再帰提供の可否、AA=0は回答元の再帰DNS自身がそのゾーンの権威ではないことを表します。製品の表示形式や権威・再帰を同じサーバに載せる構成では確認すべき条件が増えるので、送信先アドレスとゾーン設定も併せて見ます。

3. 一件の名前解決：再帰依頼と反復問い合わせ

ここでは社内再帰DNSのキャッシュが空で、フォワーダを使わず、ルート→example→acme.exampleの権威をたどると仮定します。実インターネットの.exampleはこの通りに委任されていません。実装がQNAME minimisationを使うと親へ送るQNAMEは段階ごとに短くなるため、次のログは考え方を示す簡略化例です。

再帰依頼と権威DNSへの反復問い合わせ

キャッシュ不在の架空例。親の権威DNSは最終Aではなく次のNSを返し、再帰DNSが次の相手を選ぶ。

図の各応答は同じクライアントに順送りされるわけではありません。ルートと親は次の権威DNSを紹介し、再帰DNSがその情報を使って次の質問を送ります。端末は最終結果かエラーを待ちます。再帰とは「質問を受けたサーバが答えを得るまで処理する」方式、反復とは「紹介された次のサーバへ問い合わせ側が進む」方式です。

text

10:00:00.000 [端末→10.0.0.53] id=0x4a2b RD=1
  www.acme.example. IN A
10:00:00.005 [10.0.0.53→192.0.2.1] RD=0
  www.acme.example. IN A
10:00:00.012 [root→10.0.0.53] referral
  Authority: example. NS ns1.example.
  Additional: ns1.example. A 192.0.2.2
10:00:00.018 [10.0.0.53→192.0.2.2] RD=0
  www.acme.example. IN A
10:00:00.026 [example→10.0.0.53] referral
  Authority: acme.example. NS ns1.acme.example.
  Additional: ns1.acme.example. A 192.0.2.53
10:00:00.031 [10.0.0.53→192.0.2.53] RD=0
  www.acme.example. IN A
10:00:00.041 [acme→10.0.0.53] AA=1 RCODE=NOERROR
  Answer: www.acme.example. 300 IN A 203.0.113.80
10:00:00.043 [10.0.0.53→端末] RD=1 RA=1 AA=0
  Answer: www.acme.example. 300 IN A 203.0.113.80

端末が10.0.0.53へ最終回答を依頼する。ログの送信元は端末で、質問はAレコード。端末のアプリがホスト名をIPへ変換したいからといって、端末自身がルートへ直接問い合わせるとは限らない。
社内再帰DNSがキャッシュを調べ、なければ架空のルート権威へ照会する。rootのreferralはexample.の権威NSを紹介し、wwwのAを回答していない。
再帰DNSがexample側へ進むと、acme.example.のNSと、そのNS名を解決するためのglueが返る。glueは親が委任先へ到達させるための補助情報で、子ゾーンのAレコードの正本と同じ意味ではない。
再帰DNSがacme.exampleの権威へAを問い、AA=1の回答を得る。端末へは社内再帰DNSがRA=1、通常AA=0で最終Aを返す。

このログはA質問だけを抜き出しています。ブラウザやOSはAAAAも別に調べたり、別のキャッシュや転送先を使ったりします。キャッシュに親ゾーンのNSが既にあればルート照会は省略されます。したがって、ログにルート照会がないことだけで「再帰していない」と判断しません。

3-1. 社内名だけ失敗するとき：条件付き転送と内部向けゾーン

企業では社内向けの名前だけ特定のDNSへ転送する場合があります。次の別構成では、社内再帰DNS 10.0.0.53がinternal.acme.example宛ての質問を、内部向けゾーンの権威DNS 10.0.0.54へ送ります。外部向けacme.example権威DNS 192.0.2.53にはinternalの名前がありません。このように問い合わせ元や転送経路で見える名前が違う構成を、内部向けビューまたは分割DNSとして扱います。

text

社内再帰DNS 10.0.0.53 の条件付き転送（概念例）
  internal.acme.example. → 10.0.0.54
内部権威DNS 10.0.0.54 のゾーン
  intranet.internal.acme.example. 300 IN A 10.0.1.80

13:00 端末→10.0.0.53: intranet.internal.acme.example. IN A
13:00 10.0.0.53→10.0.0.54: 同じQNAME・QTYPE
13:00 10.0.0.54→10.0.0.53: AA=1 A=10.0.1.80
13:00 10.0.0.53→端末: AA=0 A=10.0.1.80 TTL=300

13:10 条件付き転送設定を誤って削除。上のキャッシュは期限切れ。
13:10 10.0.0.53→公開階層をたどり192.0.2.53へ照会
  QNAME=intranet.internal.acme.example. QTYPE=A
13:10 公開権威→10.0.0.53: NXDOMAIN
13:10 10.0.0.53→端末: NXDOMAIN

13:10のNXDOMAINだけを見ても、内部向けレコードが消えたとは言えません。10.0.0.53の条件付き転送設定と転送先への到達性、10.0.0.54の権威回答、公開権威への誤った上流照会を突き合わせます。設定を戻した後も誤ったNXDOMAINの否定キャッシュが残り得るので、キャッシュの期限または管理下の消去を確認し、社内端末からの名前解決と接続を再検証します。

4. キャッシュとTTL：更新がすぐ見えない理由

TTLはRRsetをキャッシュしてよい残り時間を示す秒数です。権威DNSが300秒で返したAを再帰DNSが保存し、60秒後に同じQNAME・QTYPEが来れば、概念上は残り240秒のAをキャッシュから返せます。実際の表示値は取得時刻、経過時間の丸め、再帰DNSのキャッシュ上限・下限、プリフェッチ、serve-staleなどの設定で異なります。

text

10:00:00 権威DNS A=203.0.113.80 TTL=300
10:00:00 再帰DNSがAを保存、有効期限は概念上10:05:00
10:01:00 端末→再帰DNS 同じAを質問
10:01:00 再帰DNS→端末 A=203.0.113.80 TTL≈240
10:01:00 権威DNSへの問い合わせは発生しない

TTLを新たに60へ変更しても、変更前に300秒で保存されたキャッシュが自動的に短縮されるわけではありません。切替前に古いTTL分の待機を見込むか、管理下の再帰DNSで適切にキャッシュを消去します。端末・ブラウザ・プロキシに別のキャッシュがあれば、それぞれの保持条件を確認します。TTL=0なら通常のキャッシュ保持を抑えられますが、全ての中間機器の挙動やアプリの独自キャッシュまで保証しません。

複数のAやAAAAを返すサービスでは、同じ名前から複数の宛先候補が得られます。DNSの応答順だけで最終接続先を確定せず、端末の接続ログを確認してください。CDN、内部向けビュー、地理条件、DNS転送先の差があると、異なる観測点に異なるAが正規に返る場合もあります。

5. NS・SOA・A/AAAA・CNAMEをゾーンで読む

ゾーンは、権威DNSが管理する名前の範囲です。ドメイン名の文字列が長いことと、その名前のレコードをどのゾーンが管理するかは同じ話ではありません。親のexampleゾーンがacme.exampleを委任したなら、親には委任のNSがあり、acme.exampleの権威DNSにはゾーン頂点のSOA・NSとホストのA等があります。

dns

; 親ゾーン example. にある委任情報（架空）
acme.example.          600 IN NS   ns1.acme.example.
ns1.acme.example.      600 IN A    192.0.2.53   ; glue

; 子ゾーン acme.example. の権威データ（架空）
acme.example.          600 IN SOA  ns1.acme.example. hostmaster.acme.example. (
  2026092401 3600 900 1209600 300 )
acme.example.          600 IN NS   ns1.acme.example.
ns1.acme.example.      600 IN A    192.0.2.53
www.acme.example.      300 IN A    203.0.113.80
www.acme.example.      300 IN AAAA 2001:db8::80
onlyv6.acme.example.   300 IN AAAA 2001:db8::81
portal.acme.example.   300 IN CNAME www.acme.example.
broken.acme.example.   300 IN CNAME missing.acme.example.

5-1. NSとglue：誰へ聞きに行くか

NSはそのゾーンに権威を持つサーバ名を示します。親ゾーンのNSは委任先を再帰DNSへ紹介するために使われ、子ゾーンの頂点にもNSがあります。両方の設定が食い違うと名前解決が不安定になり得ます。上のns1.acme.exampleは委任される子ゾーン内の名前なので、そのIPを知らないとNSへ到達するために同じゾーンを引く循環が起きます。親がAdditional欄にA=192.0.2.53をglueとして添えるのはこのためです。

glueは到達のための補助レコードで、子ゾーンの権威A/AAAAと同じ信頼度として扱いません。親のNSが指す外部名の場合はglueが不要な場合もあります。古いglue、委任先の障害、到達できない権威DNSがあれば、再帰DNSが候補を替えたりタイムアウトしたりします。

5-2. SOA：ゾーンの管理情報

MNAME：SOAに記された主たる権威サーバ名。ゾーンの他のNS候補や実際の更新元と必ず一対一ではない。
RNAME：管理連絡先をDNS名の形式で表す。例のhostmaster.acme.example.はメールのhostmaster@acme.exampleに相当する。ゾーンファイルには@を書かず、最初のエスケープされていない点を@として読む。
SERIAL：ゾーンデータの版番号。セカンダリが更新の要否を判断する材料になる。日付風の数値でも、単純な大小比較ではなくDNSのシリアル番号演算を考慮する。
REFRESH=3600秒：セカンダリがプライマリのSOA SERIALを確認する間隔。この例では1時間ごとに更新の有無を調べる。
RETRY=900秒：更新確認に失敗した後の再試行間隔。この例では15分後に再試行する。
EXPIRE=1209600秒：最後に正常に更新・確認できてから、セカンダリが古いゾーンを権威データとして保持できる期限。この例では14日。期限超過時は古い情報を権威回答し続けず、同期障害の原因と利用者影響を調べる。
MINIMUM：現在の否定応答キャッシュのTTL算出に用いる。ゾーン内の全てのAやNSの最小TTLを意味するものではない。

ゾーン頂点のSOA RR自身にもTTLがあります。たとえばSOAのTTLが600秒、SOA MINIMUMが300秒なら、NXDOMAINなどの否定応答のキャッシュ寿命は原則として小さい方の300秒を上限として扱います。権威DNSが応答に入れたSOAのTTLは、この否定キャッシュ時間に合わせて調整されます。

このSOA例で10:00にセカンダリがSERIAL=2026092401を正常確認し、その後プライマリに到達できなくなったとします。11:00のREFRESH失敗後は15分間隔で再試行します。復旧せず14日が過ぎればEXPIREに達するため、セカンダリの同期状態と権威回答の可否を確認します。SOAの600秒やMINIMUMの300秒は、この14日間の同期期限とは別の値です。

5-3. A/AAAAとCNAME：答えの種類

Aは名前からIPv4、AAAAは名前からIPv6を得るレコードです。CNAMEは名前を別の正規名へ向ける別名で、IPそのものを直接書くレコードではありません。例でportal.acme.exampleのAを問うと、portalのCNAMEとwww.acme.exampleのAを追う必要があります。権威DNSが両方のRRsetを回答に含める場合も、再帰DNSが後続の名前を別途解決する場合もあります。

dns

質問: portal.acme.example. IN A
Answer: portal.acme.example. 300 IN CNAME www.acme.example.
Answer: www.acme.example.    300 IN A     203.0.113.80

CNAMEを持つ同じ所有名に通常のA・AAAA・MXなど別のデータを併置しません。ゾーン頂点にはSOAとNSが必要なので、同じ頂点を一般的なCNAMEとして置けません。「CNAMEがあるから接続先のIPが一生同じ」とも言えず、別名の先にあるA/AAAAとそのTTLを別に調べます。長いCNAME鎖や循環は遅延や解決失敗につながるので、経路を一段ずつ追います。

6. NXDOMAIN・NODATA・SERVFAIL・REFUSEDを区別する

「IPが返らなかった」だけでは原因を判断できません。名前そのものが存在しない場合、名前は存在するが質問した型がない場合、サーバが解決できなかった場合、方針で拒否した場合を分けます。いずれも問い合わせ先と時刻、QNAME、QTYPE、RCODE、Authority欄をセットで読みます。

回答がない四つの理由

質問がAの場合。RCODEと存在判定を分け、Authority欄のSOAや追加ログで確認する。

次はacme.exampleゾーンの権威DNSが正しく応答し、nohost.acme.exampleは存在しない一方、www.acme.exampleにはAとAAAAがあり、別のonlyv6.acme.exampleにはAAAAだけがある架空例です。onlyv6のAへのNOERROR/AnswerなしはNODATAで、名前が存在しないNXDOMAINとは異なります。

text

QNAME=nohost.acme.example. QTYPE=A
  RCODE=NXDOMAIN Answer=なし
  Authority: acme.example. SOA ... MINIMUM=300

QNAME=onlyv6.acme.example. QTYPE=A
  RCODE=NOERROR Answer=なし
  Authority: acme.example. SOA ... MINIMUM=300

QNAME=onlyv6.acme.example. QTYPE=AAAA
  RCODE=NOERROR Answer=2001:db8::81

上のnohostへの直接質問では、NXDOMAINは質問名自体が存在しないことを示します。同じ名前の別QTYPEにも通常は回答がありません。NODATAは名前が存在しても質問した型のRRsetがない状態で、別の型は存在し得ます。権威DNSから来たSOAとTTLに基づき、再帰DNSは否定結果もキャッシュできます。上のSOA TTL=600・MINIMUM=300なら否定キャッシュ時間の目安は300秒です。

6-1. Answerが空でもNODATAとは限らない

次は同じA質問を、委任元のexample権威DNSと委任先のacme権威DNSへ直接送る架空例です。どちらもRCODE=NOERROR、Answerは空ですが、前者は次に聞くべき権威を紹介するreferralです。後者は、その名前にはAAAAがあってもAがないことを示すNODATAです。

text

質問: onlyv6.acme.example. IN A
example権威DNSの応答: RCODE=NOERROR Answer=なし
  Authority: acme.example. NS ns1.acme.example.
  Additional: ns1.acme.example. A 192.0.2.53
  判定: 委任先への紹介。再帰DNSは次の権威へ質問する。

acme権威DNSの応答: RCODE=NOERROR AA=1 Answer=なし
  Authority: acme.example. SOA ... MINIMUM=300
  判定: AのNODATA。AAAAなど別の型は存在し得る。

NOERRORと空のAnswerだけでNODATAとせず、Authorityの委任NSとSOA、AA、問い合わせ先のゾーンを合わせて読みます。再帰DNSから端末への最終応答ではAuthority欄を省く実装もあるため、欄が空なら権威DNSへの直接質問や再帰DNSの上流ログで裏付けます。

6-2. CNAMEを経由したNXDOMAINはどの名前か

ゾーン例のbroken.acme.exampleはCNAMEとして存在します。しかし参照先のmissing.acme.exampleは存在しません。brokenのAを質問すると、CNAMEをたどった最後の質問がNXDOMAINになり、最終応答のRCODEもNXDOMAINになります。元のQNAMEだけを見てbrokenを削除済みと判断してはいけません。

text

質問: broken.acme.example. IN A
  RCODE=NXDOMAIN
  Answer: broken.acme.example. 300 IN CNAME missing.acme.example.
  Authority: acme.example. SOA ... MINIMUM=300
判定: brokenは存在する。存在しないのはCNAMEの参照先missing。

CNAMEが複数段なら、Answerの別名を順に追い、最後の参照先に対する否定応答かを確認します。復旧時は元の別名を消す前に、参照先の登録・権威ゾーン・否定キャッシュの期限を調べます。

SERVFAILはDNSSEC検証失敗、上流タイムアウト、設定不整合など複数原因で発生します。REFUSEDは問い合わせ元の許可設定、ゾーン転送制限、ビュー選択などの方針で返ることがあります。いずれも「存在しない」を意味しません。上流の一時失敗も実装・仕様に応じて短時間キャッシュされ得るため、失敗応答の繰返しだけで権威DNSが毎回問い合わせられたと考えないでください。

6-3. 否定キャッシュとレコード追加後の見え方

text

10:30:00 権威DNS: nohost.acme.example. -> NXDOMAIN
10:30:00 再帰DNS: NXDOMAINを否定キャッシュへ保存
10:31:00 権威DNS: nohost.acme.example. Aを追加
10:32:00 同じ再帰DNS: 古いNXDOMAINを返す場合がある
10:35:00 否定キャッシュ期限後: 新しいAを取得し得る

ゾーンへAを追加しても、既に取得したNXDOMAINが残る間は利用者から見えないことがあります。問い合わせ先を変えると結果が違う場合、どちらの再帰DNSにどの時刻から何が残ったか調べます。ブラウザやOSの別キャッシュ、DNSSECで署名した否定応答の扱い、実装のserve-stale設定も考慮します。急な切替では権威DNSだけを直して終わらず、利用者側の有効期限と業務影響を確認します。

7. DNSはUDPだけで完結しない

通常のDNS質問にはUDP 53番を使うことが多いですが、TCP 53番も通常の名前解決に使えます。大きいUDP応答が切り詰められてTC=1なら、問い合わせ側はTCPで再試行できます。DNSSECの追加データや多数のレコードで応答が大きくなると、UDPの断片化やTCが問題になります。一般的なDNS実装にはUDPとTCPの両方のサポートが求められます。

次のログだけは、前のゾーン抜粋に載せていないlarge.acme.exampleの長いTXT RRsetを別に問い合わせ、UDPで許容される応答サイズを超えたと仮定します。単一の短いAレコードで必ずTC=1になるという例ではありません。

text

11:00:00.000 UDP 10.0.0.53:53000 -> 192.0.2.53:53
  QNAME=large.acme.example. QTYPE=TXT
11:00:00.020 UDP 192.0.2.53:53 -> 10.0.0.53:53000 TC=1
11:00:00.025 TCP 10.0.0.53:53001 -> 192.0.2.53:53
  同じQNAME・QTYPEを再問い合わせ
11:00:00.045 TCP 192.0.2.53:53 -> 10.0.0.53:53001
  完全なDNS応答

このTCP 53番の通信は、TC=1を受けた普通の名前解決の再試行です。TCPを見ただけでAXFRや攻撃と決めません。UDP 53番しか境界で許さないと、大きい回答だけ解決できない障害になり得ます。UDPの応答なしも、サーバ停止、経路・ACL、断片化、EDNSの扱いを分けて調べます。

EDNS(0)：従来のDNSメッセージを拡張し、問い合わせ側が受け取れるUDP応答サイズなどを相手に伝える仕組み。追加データが大きい応答をUDPで返しやすくなるが、経路上の装置がそのサイズを通す保証はない。応答が届かないときは広告サイズ、断片化、TC=1後のTCP再試行を確認する。
DoT（DNS over TLS）：DNSをTLSで保護して送る方式。通常はTCP 853番。端末が社内再帰DNSを経由せず外部DoTへ送る構成なら、社内の53番の問い合わせログにはその質問が残らない。端末の接続先と許可方針を調べる。
DoH（DNS over HTTPS）：DNSをHTTPSで送る方式。通常のHTTPSと同じ443番を使う構成がある。53番ログに端末の質問がなければ、ブラウザやアプリのDoH設定とHTTPSの接続先を確認する。443番通信だけで個々のDNS質問内容まで読めるとは限らない。

8. ゾーン転送は利用者の再帰問い合わせと別の通信

権威DNSを複数台で運用するとき、セカンダリはゾーンデータをプライマリから取得します。AXFRはゾーン全体の転送、IXFRは差分転送です。SOAのSERIALを比較して更新の要否を判断する構成では、SERIALを増やさない変更がセカンダリへ伝わらない原因になります。ゾーン転送はDNSの一種ですが、端末がwwwのAを引く再帰問い合わせとは目的も許可する相手も異なります。

text

11:30:00 [secondary 192.0.2.60 → primary 192.0.2.53]
  TCP/53 QNAME=acme.example. QTYPE=AXFR
  result=success SOA serial=2026092401
11:31:00 [external 198.51.100.20 → primary 192.0.2.53]
  TCP/53 QNAME=acme.example. QTYPE=AXFR
  RCODE=REFUSED rule=transfer-secondary-only

この架空の運用では192.0.2.60だけが転送を受けられ、外部からのAXFRは拒否されます。AXFRを誰に許すかは権威DNSの転送設定で決めます。IPによる許可範囲に加え、TSIGで転送相手とメッセージを認証する方法があります。TSIGは転送内容を暗号化する仕組みではないため、転送経路の秘匿が必要なら別途設計します。

AXFRが全ての外部から成功すると、ゾーン内に公開した名前・構成の棚卸しを第三者に容易にされる可能性があります。ただし、AXFR成功だけで侵害や情報流出の範囲を断定せず、取得されたゾーンの内容、誰からいつ要求されたか、公開情報との差を確認します。反対に転送を厳しく止めすぎるとセカンダリが更新できず、SOA EXPIREに至れば権威回答に影響し得ます。セカンダリのシリアル、同期状況、権威回答を確認してください。

9. 不審な回答をどう調べるか

9-1. キャッシュのAと権威DNSのAが違う

次は、同じQNAME・QTYPE・Classを同じ時間帯に調べた架空の異常例です。社内再帰DNSだけが198.51.100.77を返し、acme.exampleの権威DNSから直接得た回答は203.0.113.80です。すぐに「キャッシュポイズニング成功」と決めず、観測点と設定を照合します。

text

12:00:00 terminal→10.0.0.53:53 www.acme.example. IN A
12:00:00 10.0.0.53→terminal: NOERROR RA=1 AA=0
  Answer: www.acme.example. 180 IN A 198.51.100.77
12:00:02 investigator→192.0.2.53:53 同じQNAME/QTYPE
12:00:02 192.0.2.53→investigator: NOERROR AA=1
  Answer: www.acme.example. 300 IN A 203.0.113.80

端末が実際に使った再帰DNSのIPと回答時刻を確定する。同じ名前でもA/AAAA、検索サフィックス、ビュー、フォワーダ、CDNの条件が異なれば比較できない。
権威DNSのゾーン・SOAシリアルと各権威サーバの回答を比較する。権威サーバ間の同期遅れや正規の切替も候補にする。
10.0.0.53のキャッシュ挿入時刻、転送先、設定変更、問い合わせ先、受信した応答の送信元・ID・ポート・QNAMEを確認する。キャッシュへの手動登録や内部ビューも調べる。
端末の実接続先IPとHTTP/TLS・プロキシ・EDRの記録を調べる。異なるDNS回答だけで利用者が198.51.100.77へ接続したとは言えない。

不正な回答を外部から注入するには、再帰DNSがその応答を受け入れる条件を満たす必要があります。問い合わせ中のQNAME・QTYPE・ID・ポートや送信元、委任された範囲のレコードかを検証する実装・設定により成立条件は変わります。攻撃者が通信経路上にいる、再帰DNSやフォワーダを侵害した、管理者権限でローカルデータを変えた、といった仮説を証跡で分けます。単にAA=1の応答を見たことは、DNSの暗号学的な真正性の証明にはなりません。

9-2. DNSSECとログから言えること

DNSSECは署名されたDNSデータの出所と完全性を検証する仕組みで、適切に設定された検証リゾルバは不正な署名や信頼連鎖の不整合を検出できます。DNSSECは回答先サイトの善悪や通信内容を保証しません。ゾーンが署名されていない、端末が検証しない、再帰DNSとの経路を信用できないなどの条件では「AD=1だから絶対安全」と言えません。

ADは検証した再帰DNSが応答データを認証済みと判断したことを示すビットです。CDはクライアントが再帰DNS側の検証を無効化してデータを受け取りたい場合に使えます。ADやCDの意味を調べる際は、端末と再帰DNSの間が信頼できるか、再帰DNSが検証を有効にしているか、対象ゾーンが署名されているかを確認します。DNSSECの詳しい鍵・署名の仕組みは別の教材で扱うとして、ここではログ上の信頼境界に集中します。

9-3. 開放再帰DNSと増幅の成立条件

外部の誰でも自社の再帰DNSを利用できると、権威DNSを探す処理やキャッシュを第三者に提供してしまいます。送信元IPを偽装できる攻撃者が、小さいDNS質問を被害者IPを名乗って送り、再帰DNSが大きい応答を被害者へ返すなら、DNS増幅・反射に悪用され得ます。成立には外部から再帰サービスへ到達できること、送信元偽装が通る経路、応答サイズや要求数などが関係します。

開放再帰DNSが悪用される経路

1. 再帰を開放：証跡外部IPからRD=1へ回答／防御・対処利用元を社内・承認先に限定
2. 送信元を偽装：証跡上流の送信元検査と流量／防御・対処出口で送信元を検査
3. 大きな応答：証跡宛先IPと応答サイズ・回数／防御・対処再帰制限と異常流量監視
4. 被害先へ集中：証跡被害先・上流の通信量／防御・対処遮断と上流連携で緩和

送信元偽装が可能な場合の概略。設定とログを確認せずに利用者IPを攻撃主体と決めない。

権威DNSは正規の外部利用者から自ゾーンの質問を受ける必要がある一方、再帰DNSは利用者を制限する設計が基本です。単一サーバに権威と再帰の両方を載せる場合でも、外部へ再帰を開放しないアクセス制御が必要です。既存の再帰利用者を棚卸しせず一律停止すると社内業務を止めるため、利用元と転送経路を確認してから制限します。

10. 運用変更・障害対応・復旧の確認

10-1. 何をどこで制御するか

端末のDNS設定：承認した再帰DNSを利用させ、DHCP、VPN、DoT/DoH、アプリ内設定を含めて実際の送信先を確認する。端末に設定が見えても、その通りに全アプリが問い合わせるとは限らない。
再帰DNSのアクセス制御：社内や承認先の利用者だけに再帰を提供する。外部の権威DNSへ反復照会する送信通信は別に設計し、UDP/TCP 53番とログを整える。
権威DNSの冗長化：親のNS委任、glue、子ゾーンのNS、A/AAAA、SOAシリアル、セカンダリ同期を点検する。複数の権威の回答が食い違うと利用者ごとに結果が変わる。
ゾーン転送制限：承認したセカンダリだけにAXFR/IXFRを許す。必要に応じTSIGで認証し、拒否ログとセカンダリの更新成功を両方監視する。
ログと時刻：QNAME、QTYPE、RCODE、回答先、TTL、観測点、委任先、設定変更、キャッシュ操作を保全する。問い合わせログを長期保存する場合は利用者名や内部ホスト名の扱いも設計する。

10-2. 移行・障害・侵害時の分岐

IP移行では、新しい権威データを準備し、旧TTLと否定キャッシュの期限を見込み、旧・新宛先の到達性を重ねて監視します。NSやglueを変更するなら親と子の両方が整合するか確認します。SOAシリアルを更新し、全ての権威DNSと社内外の再帰DNSから同じ時点の回答を採取します。DNSが新しいIPを返すことと、アプリの接続・認証が成功することを別々に確認します。

SERVFAILが増えた場合は、再帰DNSから見た上流の到達性、権威DNSの応答、転送先、DNSSEC検証エラー、TC後のTCP再試行、時計や設定変更を順に調べます。NXDOMAINが増えたなら、実際のQNAME、検索サフィックス、親の委任、権威データ、否定キャッシュの期限を調べます。解決障害を直すために検証を恒久的に無効化する対応は、原因を残す可能性があります。

不審なキャッシュ内容が疑われるときは、端末・再帰DNS・権威DNSの応答と設定、キャッシュ挿入時刻、アクセス権の変更履歴を保全します。必要なら影響を受けた再帰DNSを切り離し、正本ゾーンと委任先を確認してからキャッシュを消去・再取得します。再接続前に不正な転送先・権威NS・管理アカウントが残っていないことを確認し、複数の利用者地点で正しい回答と実際の業務接続を再検証します。

11. 科目B（午後）の記述演習

演習1：どのサーバが権威を持つか

条件：端末→10.0.0.53の質問はRD=1。10.0.0.53→端末の応答はRA=1、AA=0、A=203.0.113.80。192.0.2.53→10.0.0.53の応答はAA=1で同じA。問い：再帰を担当したサーバ、権威を持つサーバ、端末へ送られたAA=0の意味を答える。

解答：10.0.0.53が端末の再帰依頼に答え、192.0.2.53がacme.exampleの権威回答を返しました。端末へ送られたAA=0は10.0.0.53自身がこのゾーンの権威として回答していないことを示します。再帰DNSがキャッシュだけで返したか、この回に権威まで照会したかはフラグだけでは分からず、10.0.0.53の上流ログが必要です。

誤答の理由：「RA=1だから10.0.0.53が権威DNS」は再帰提供と権威の意味を混同しています。「AA=0だからAは無効」も、再帰DNSの通常の最終回答を誤読しています。

演習2：TTLを変更した直後の古いA

条件：10:00に再帰DNSがTTL=300でA=203.0.113.80を保存した。10:01に権威DNSのAを203.0.113.81へ変更し、新TTLを60にした。10:02に同じ再帰DNSを使う端末が旧IPを得た。問い：原因と、復旧をどう確認するか。

解答：10:00に保存したRRsetは概念上10:05まで有効なので、権威側のTTLを後から60へ変えても既存キャッシュの寿命は短縮されません。再帰DNSの回答TTLとキャッシュ記録、端末・ブラウザのキャッシュを確認し、有効期限後または管理下の適切なキャッシュ消去後に新IPが返るか調べます。実際の業務接続が新旧の切替計画どおりに成功することまで確認します。

誤答の理由：「権威DNSの現在のTTLが60だから10:02には必ず新IP」は、変更前に保存されたTTLを無視しています。

演習3：NXDOMAINとNODATA

条件：onlyv6.acme.exampleのA質問はRCODE=NOERROR、Answerなし、AuthorityにSOA。AAAA質問では2001:db8::81が返った。nohost.acme.exampleのA質問はRCODE=NXDOMAIN。問い：前者と後者の違い、追加で調べる情報を答える。

解答：前者は名前が存在するがAのRRsetがないNODATAで、AAAAは利用できます。後者は質問名そのものが存在しないNXDOMAINです。端末が実際に送ったQNAME・QTYPE、問い合わせ先、SOAと否定キャッシュTTL、権威ゾーンを確認します。

誤答の理由：「Aがないので両方ともNXDOMAIN」は、名前の存在とレコード型の存在を混同しています。

演習4：委任後に名前解決できない

条件：acme.exampleの権威DNSを192.0.2.53から192.0.2.54へ移した。子ゾーンのns1.acme.exampleのAは.54になったが、親ゾーンの委任に添えるglueは.53のままで、旧.53は停止した。問い：再帰DNSはどこで止まり、どの設定を直すか。

解答：親がns1.acme.exampleというNSを紹介しても、同じ子ゾーン内にあるNS名の到達先として古いglue 192.0.2.53を使う再帰DNSは、停止した権威へ照会して失敗し得ます。親のglueを192.0.2.54へ更新し、親の委任NS、子ゾーンのNS・A/AAAA、実際の権威応答、各キャッシュの期限を照合します。複数NSがあれば他の権威経由で成功する利用者もいるので、全候補を調べます。

誤答の理由：「子ゾーンのAを直したから親のglueは不要」は、子ゾーンへ到達するための情報が古いままという条件を見落としています。

演習5：不審なキャッシュ回答

条件：12:00に端末が社内再帰DNSから198.51.100.77を得た。12:02にacme.exampleの権威DNSへ直接同じAを問うと203.0.113.80が返る。端末の接続ログはまだない。問い：どこまで分かり、原因調査・初動・再開条件は何か。

解答：二つの観測点で同じQNAME・QTYPEに異なるAが返ったことまでは確認できます。正規のビュー・移行・権威間同期差・古いキャッシュ・フォワーダ・不正な挿入を順に調べます。端末と再帰DNSのログ、キャッシュ投入、転送先、管理操作、権威のSOAシリアルと各NSの回答を保全し、必要なら影響リゾルバを切り離します。正本と委任を確認してからキャッシュを再構築し、複数端末で正しい解決とアプリ接続が続くことを確かめて再開します。

誤答の理由：「Aが違うのでDNSキャッシュポイズニング確定」は、正規の分岐条件と実際の端末接続先を確認していません。

演習6：TCP 53番の意味

条件：再帰DNSが権威DNSへUDP 53番でlarge.acme.exampleの長いTXT RRsetを質問し、権威からTC=1の応答を受けた直後、同じQNAME・QTYPEをTCP 53番で問い合わせた。別時刻にはセカンダリがQTYPE=AXFRをTCP 53番で要求し、外部端末の同じAXFRはREFUSEDだった。問い：各TCP通信の目的を答える。

解答：最初のTCPは切り詰められた通常の名前解決を完全な応答で取り直すためです。セカンダリのTCPはゾーン転送です。外部端末へのREFUSEDはゾーン転送の許可条件に合わなかったことを示します。成功したセカンダリの転送後はSOAシリアルと権威回答が更新されたか確認します。

誤答の理由：「TCP 53番は全てゾーン転送」「REFUSEDなのでゾーンが存在しない」は、QTYPE・TC・許可方針を読んでいません。

演習7：外部から再帰できるサーバ

条件：公開権威DNSを兼ねるサーバ192.0.2.53へ外部IPから無関係なother.exampleのAをRD=1で問い合わせると、RA=1で最終回答が返った。通常はacme.exampleの権威として利用される。問い：何が問題で、どこをどう直すか。

解答：自ゾーン以外の再帰サービスを外部IPへ提供しており、開放再帰として第三者に悪用され得ます。外部からの再帰許可を制限し、承認した内部利用者だけに再帰を提供します。権威DNSとしてのacme.exampleへの通常質問は維持し、設定変更前後に正規利用者の名前解決と外部からの再帰拒否を両方確認します。送信元偽装ができる経路では反射・増幅にも悪用され得るため、上流での送信元検査と流量も調べます。

誤答の理由：「公開権威DNSなので全ての再帰質問にも答える必要がある」は、権威回答と利用者向け再帰サービスを混同しています。