← 研修トップ
DNSを運用する側から見る
レコードを1行足すと何が変わり、何が変わらないのか。第25週で名前解決の経路を辿ったあと、今度はその名前を置く側・直す側に立ちます。種別が決めるのは値の読み方だけであること、TTLが予定ではなく上限であること、権威が複数ある理由、偽の応答が通ってしまう理由、そしてDNSSECが何を保証しないか。「変えたのに反映されない」「切り替えたのに繋がらない」の因果を、RFCの逐語から積み上げます。
- 1約 9 分レコードは名前と値の1行 — 種別が決めるのは値の読み方DNSのレコードは「名前・TTL・クラス・種別・値」が並んだ1行です。種別(TYPE)が決めているのは**その値をどう読むか**だけで、他の行には関わりません。だからAとAAAAは同じ名前に並べられます。
- 2約 9 分頂点には別名を置けない — ALIAS/ANAME が標準に無い理由ゾーンの頂点には SOA と NS が必ず置かれます。RFC 2181 §6.1 は、その2つを「すべてのゾーンにおける必須のレコード」と呼んでいます。一方 CNAME は他のデータと同じ名前に並べません。この2つが同時に成り立たないので、頂点に CNAME は置けません。
- 3約 9 分TTLは上限であって予定ではない — 反映されない本当の理由TTL は「この秒数までは保持してよい」という**上限**であって、保持の義務でも、問い合わせの予定でもありません。RFC 2181 §8 が **"a maximum time to live, not a mandatory time to live"** と明記しています。
- 4約 9 分権威が複数ある理由 — ゾーン転送と、同じ中身を保つ仕掛け権威を1台しか置かないと、その1台が落ちた時点でゾーン全体が引けなくなります。だから複数台置き、すると「複数台が同じ中身を持つ」ことをどう成り立たせるかという問題が生まれます。
- 5約 9 分なぜ偽の応答が通るのか — キャッシュを汚す攻撃と、待っている側の弱さリゾルバは自分が出した問いへの答えを待っています。UDPに接続の概念は無く、「正しい相手から来た」と確かめる材料は宛先ポートとQuery IDだけ。本物より先にそれらしい応答が届けば、受け入れてキャッシュに入れます。
- 6約 9 分DNSSECは何を保証しないか — 署名の連鎖と、機密性の不在DNSSECが応答に付けるのは署名です。検証できるのは「このデータはその名前の権威が作ったもので、途中で書き換えられていない」という**出所と完全性**だけです。
- 7約 9 分DNSで振り分ける — 名前で分けられることと、取り消せないことDNSが配るのは接続ではなく**答えのコピー**です。配った先で保持され、権威から回収する手立てはありません。
- 8約 9 分DoHとDoT — 誰から隠すのか暗号化は区間に効きます。DoT と DoH が包むのは、スタブリゾルバとフルサービスリゾルバの間だけです。その先、リゾルバから権威への問い合わせは従来どおりです。