権威が複数ある理由 — ゾーン転送と、同じ中身を保つ仕掛け

第25週『名前からアドレスへ — DNSは巨大な委任の木』で、委任によって権威が組織ごとに分かれることを見ました。その先を1台で受けると、その1台が引けなくなった時点でゾーンの名前がまとめて引けなくなります。だから権威は複数台置かれ、新しい問題が出ます。複数台が同じ中身を持つことを、どう成り立たせるか。

DNS の答えは、ゾーンに版番号を付けてその数だけを比べることです。版番号は SOA の SERIAL に入っています。RFC 1034 §4.3.5 の逐語。

To detect changes, secondaries just check the SERIAL field of the SOA for the zone. In addition to whatever other changes are made, the SERIAL field in the SOA of the zone is always advanced whenever any change is made to the zone.

中身の比較をしていません。 数を1つ比べ、進んでいれば取りに行き、同じなら何もしない。向きも重要で、RFC 9499 §6 が secondary server を定義する動詞は retrieve。転送は受け取る側が始めます。

REFRESH が 3600 秒なら、次に SERIAL を確認しに行くのは最大で1時間後です。この待ち時間を縮めるのが NOTIFY(RFC 1996)。取り違えが起きやすいので §3.11 の原文を置きます。

Upon completion of a NOTIFY transaction for QTYPE=SOA, the slave should behave as though the zone given in the QNAME had reached its REFRESH interval (see [RFC1035]), i.e., it should query its masters for the SOA of the zone given in the NOTIFY QNAME, and check the answer to see if the SOA SERIAL has been incremented since the last time the zone was fetched. If so, a zone transfer (either AXFR or IXFR) should be initiated.

受け取った側がするのは「REFRESH 間隔に達したかのように振る舞う」ことです。そのあと自分から SOA を問い合わせ、SERIAL を比べ、転送を始めます。つまり NOTIFY が運ぶのは合図だけで、ゾーンデータは運ばれません。 RFC 1996 §1.2 の言い方も「ポーリングに対する割り込み(an interrupt as opposed to poll model)」であって、配送方式の転換ではありません。