Skip to content
おるとのページ
TwitterGitHub

そんなやり方で「ゾーンが更新されない」なんて言わないでくれ

— DNS — 11 min read

研究室で DNS ゾーン更新時の外からの確認方法について質問されたので書いておきます．n 番煎じですがこのサイトも久々に動かしたかったので．たいして DNS に詳しいわけでもないので間違ってたら言ってください．Twitter でたくさんまさかり投げられそう．

なお，ここでは確認方法だけを取り扱い，ミスを確認後の修正すべき点については out of scope とさせていただきます．また，技術的厳密性は怪文書並みです．

僕ならこうする

外から確認するときと権威サーバ内部から必要な権限をもって確認するときのふたとおりをかきます．なお，委譲設定の変更でゾーンファイルを書き換えたときなどは当然これだけでは不十分で，DNS の木構造に沿って確認する必要などがあります．

外から確認する

まず外から確認するときは，このコマンドを実行します．

dig {RR_type} {RR_name} @{auth_addr} +norec

各パラメータは以下のとおりです．

RR_type: 確認したいレコードのレコードタイプ (AAAA, MX など)

RR_name: 確認したいレコードのレコード名 (FQDN など)

auth_addr: 当該レコードを返すべき権威サーバの IP アドレス (not FQDN)

※ 当該レコードを返すべき権威サーバが複数ある場合，全てに対してこの確認を行います．

例えば，「wiki.jj1lfc.dev. の AAAA レコードを 2001:19f0:7002:790:5400:2ff:fe7d:6b14 に書き換えたんだけど，正しくこれでひけるか確認したい」というときはこうです (jj1lfc.dev.ゾーンの権威サーバは ns{1,2}.jj1lfc.dev. で，それぞれの IP アドレスは 2400:6180:0:d1::776:1001, 2401:c080:1000:4c9f:5400:3ff:fe2f:a3b とします)．

dig AAAA wiki.jj1lfc.dev. @2400:6180:0:d1::776:1001 +norec
dig AAAA wiki.jj1lfc.dev. @2401:c080:1000:4c9f:5400:3ff:fe2f:a3b +norec

このときの結果として期待されるのは，例えばこのようなものです．

; <<>> DiG 9.16.1-Ubuntu <<>> AAAA wiki.jj1lfc.dev. @2400:6180:0:d1::776:1001 +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12256
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wiki.jj1lfc.dev.               IN      AAAA


;; ANSWER SECTION:
wiki.jj1lfc.dev.        3600    IN      AAAA    2001:19f0:7002:790:5400:2ff:fe7d:6b14


;; Query time: 95 msec
;; SERVER: 2400:6180:0:d1::776:1001#53(2400:6180:0:d1::776:1001)
;; WHEN: Mon Feb 08 22:49:28 JST 2021
;; MSG SIZE  rcvd: 72

このとき確認すべきは，主に以下の項目です．

  • 返答が期待したステータスになっていること．
    • レコードを追加や変更した場合は，status 欄が NOERROR となっており，answer section が存在していること (NOERROR レスポンス)．
    • レコードを削除したが，同じレコード名で別のレコードタイプなどのレコードが別に存在している場合，status 欄が NOERROR となっており，ANSWER SECTION が存在していないこと (NODATA レスポンス)．
    • レコードを削除し，同じレコード名のレコードは何も存在していない場合，status 欄が NXDOMAIN となっていること (NXDOMAIN レスポンス)．
  • フラグが以下のとおりになっていること
    • rd (Recursion Desired) フラグがたっていないこと: +norec して問合せていればつかないはず
    • aa (Authoritative Answer) フラグがたっていること: 当該ゾーンの権威をもっているサーバからの応答であることを示す
    • ANSWER SECTION が存在する場合，その内容が期待した値になっていること
    • SERVER 欄が，変更が適用されるべき (確認のためにクエリした) 権威サーバの IP アドレスであること (これは主に確認時ミスの防止)

また，ゾーン転送を行っている場合は当該ゾーンの SOA レコードを問い合わせてゾーンシリアルのアップデートを確認することも有効です．

例えば:

dig SOA jj1lfc.dev. @2400:6180:0:d1::776:1001 +norec +short

答えとしては:

ns1.jj1lfc.dev. dnsadm.m.jj1lfc.dev. 1612482141 600 600 259200 300

全部フルフルできいて回った結果を貼ると長いので +short しましたが，この例では 1612482141 がゾーンシリアルです．

プライマリ権威サーバ，セカンダリ権威サーバにそれぞれ問い合わせて，シリアルがアップデートされていること，みんな同じシリアルになっていることを確認します．

ゾーン転送を受けているセカンダリ権威サーバは，ゾーンシリアルが以前と比較して増えている場合のみ，ゾーン転送を受け入れます．これができていないと，きいた権威サーバによって正しい答えが帰ってこないロシアンルーレット状態になります．

中から確認する

ssh などで適切な権限をもって権威サーバのシェルをいじれるときは，権威サーバ内で上記と同様のことをやることもできます．特に中からはゾーンファイルが本当に書き換わっているのかどうかと，ログファイルを以下の項目について確認します．

  • 書き換えたゾーンファイルがエラーなくロードされていること (多くの実装では書き換えた後ロードするコマンドを発行しないと書き換えた内容で応答してくれません)．
  • プライマリ権威サーバの場合，新しいゾーンファイルの内容がセカンダリ権威サーバに適切に転送されていること．
  • セカンダリ権威サーバの場合，新しいゾーンファイルの内容がプライマリ権威サーバから適切に転送されてきていること．

ダメな確認方法の例

権威サーバに直接きいていない

フルサービスリゾルバやプロキシに聞いてしまっている場合が多いと思います．キャッシュを持つリゾルバの場合 (多くのフルサービスリゾルバがそうですが)，ゾーン更新前にすでにキャッシュされていた場合はキャッシュから返答しますので，当然アップデートされた内容は確認できません．

権威サーバに ssh して @localhost できいている

権威サーバは localhost について listen しているとは限りません．また，構成にもよりますが，実際に DNS クエリを投げてくる人たちは localhost からはクエリしてきません．権威サーバ内からクエリする場合でも必ず NS として登録しているホストの IP アドレスに対してクエリします．

クエリ先を FQDN で指定している

状況によっては権威サーバ自体の名前解決が期待した結果にならないことがあります．これは別の障害なので別の対処をする必要がありますが，ゾーンの更新について検証できていません．

応答ステータスをちゃんと読んでいない

権威サーバが，設定が読めていないなどで中途半端に死んでいることが往々にしてあるので，その際に気づけないかもしれません．ゾーンが更新されていないことは別の異常と関連していることも?

フラグをちゃんと読んでいない

rd フラグの有無をちゃんと読んでいないと，リゾルバ共存権威サーバなど悪い運用にあたっているときにミスリードします (そもそもそんなサーバ捨てちまえ)．

aa フラグの有無をちゃんと読んでいないと，設定異常やゾーン転送異常のときの原因推定をミスります．

ANSWER SECTION の中身をちゃんと読んでいない

あたりまえのことですが，ANSWER SECTION を読まないとわかりません．間違ってリゾルバにきいてしまっているケースは，TTL で気付ける場合もあります．

SERVER 欄をちゃんと読んでいない

意図したサーバにクエリを投げて帰ってきているのかを確認しないと，実はうまく動いているのに動いていないと勘違いしてアタフタすることがあります (僕だけ?)．

propagation checker やそれに準ずるものを使う

もう面倒なので詳細は省きます．

そもそも確認作業をしない

別の管理者が直前に不適切なゾーン編集をしたがちゃんと確認しなかったため，自分がどれだけ正しくゾーン編集しても全然正しく動かないという状況に出くわしたことがあります．毎回の確認で防げます．

以上，「最低限」と言うにはすこし多いかもしれない確認項目でした．足りないことはないと信じてる．

関連ページ

  • DNS flag day 2020
  • DNSViz

2021/05/27: 更新

rd bit の説明についてご指摘いただいたので修正しました．

詳細: https://twitter.com/OrangeMorishita/status/1397816966472036354

その他，軽微な誤字修正をしました．

© 2024 by おるとのページ. All rights reserved.
Theme by LekoArts