Zone Transfer

RFCs

以下が該当か。 細かい話はこっから引っ張ってくる。 いつかまとめる。

RFC 1034 / DOMAIN NAMES - CONCEPTS AND FACILITIES (Section 4.3.5. Zone maintenance and transfers) https://tools.ietf.org/html/rfc1034#section-4.3.5

RFC 1995 / Incremental Zone Transfer in DNS https://tools.ietf.org/html/rfc1995

RFC 5936 / DNS Zone Transfer Protocol (AXFR) https://tools.ietf.org/html/rfc5936

転送動作

ゾーン転送が発生するトリガーとしては 2 パターンある。 この分け方が本当に正しいのかは置いといて。

notify による通知

パターン 1. Master 側での情報変更をトリガーとしたゾーン転送

  1. マスターから notify を UDP で送信

  2. スレーブはこれを受け取る

  3. スレーブはマスターの SOA レコードを確認する

  4. スレーブは Serial を確認し、自分の持っている情報が古ければ転送を開始する

  5. TCP ハンドシェイク

  6. TCP でゾーン転送を行う ( AXFR or IXFR )

具体的には、 notify を受け取った後のスレーブの動作は、 Refresh による pull と同じものとされている。

DNS and BIND https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_03.htm

Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.

Refresh 時間による更新

パターン 2. Slave 側の Refresh 時間経過をトリガーとしたゾーン転送

  1. マスターから notify を UDP で送信

  2. スレーブはこれを 受け取れなかった とする

  3. スレーブは自分の Refresh 時間をトリガーとし、ゾーン転送を開始する

  4. スレーブはマスターの SOA レコードを確認する

  5. Serial を確認

  6. TCP ハンドシェイク

  7. TCP でゾーン転送を行う ( AXFR or IXFR )

詳細

CoreDNS で AXFR を実施したときの実際の流れ。

notify を受け 3-way handshake をし、 SOA を引いた後 slave が FIN を投げて切り、再度 slave から handshake を実施しているのが気になった。 これは実装依存かもしれない。(未確認) SOA と AXFR では違うコネクションを利用していた。

SOA レコードについて

ゾーン転送において気にすべきフィールドがいくつかある。(以下は BIND のフォーマット)

@   IN SOA master.example.com. hostmaster.example.com. (
    2017030300 ; serial
    3600       ; refresh
    1800       ; retry
    604800     ; expire
    600 )      ; ttl/minimum

Serial

この番号を見て、情報が古いか新しいかを確認する。 情報が古いときのみ、ゾーン転送を行う。

Refresh

ゾーン転送がしばらくの間発生していないと、情報が古い可能性があるためリフレッシュ動作を行う。 Refresh 時間だけ更新が無い場合にゾーン転送をスレーブからイニシエート。

Retry

ゾーン転送に失敗した場合のリトライ間隔。 これは Refresh より短くないといけない。

Expire

スレーブ側の情報の有効期限。 リトライに失敗し続けたりして Expire 時間が経過すると、そのゾーンのデータは古いとみなされ、応答しなくなる。(ことが期待される) NXDOMAIN を返すのか、 REFUSED を返すのか、はたまた NOERROR を返すのかは実装次第。

セキュリティ

なりすましを防ぐため、 TSIG という仕組みが使われている。 Master と Slave で共通鍵を持ち、それにより署名を実施して完全性を保証する。 ただ、暗号化は行われない。

参考

PreviousReverse DNS (rDNS)NextEDNS0

Last updated