シリアル番号の変更編集
ゾーン転送のプリアンブル部分は、ゾーンのデータが変更されたかどうか、したがって実際のデータ転送が必要かどうかを判断するのに、シリアル番号、およびシリアル番号だけに頼っている。 いくつかのDNSサーバパッケージでは、SOAリソースレコードのシリアル番号は管理者が手作業で管理している。 データベースへのすべての編集は、変更されるレコードとゾーンシリアル番号の2つの変更を伴います。 このプロセスには正確さが要求される。管理者はシリアル番号の 変更を忘れたり、間違って変更(縮小)したりするかもしれない。 RFC 1912(セクション2.2 SOAレコード)は、番号としてYYYYMMDDnnという値を使うことを推奨している (YYYY=年、MM=月、DD=日、nn=改版番号)。 これは、4294年までオーバーフローしません。
DNS サーバー パッケージの中には、ディスク上のデータベース ファイルの最終更新タイムスタンプから自動的にシリアル番号を構築して、この問題を克服しているものがあります。 たとえば、djbdnsの場合はこれです。 オペレーティングシステムは、管理者がデータベースファイルを編集するたびに最終更新タイムスタンプが更新されるようにし、事実上自動的にシリアル番号を更新し、その結果、管理者が1つの変更のために2つの編集（2つの異なる場所）を行う必要性から解放されます。
さらに、シリアル番号チェック（および実際にゾーン転送自体）が設計されているデータベースレプリケーションのパラダイム（単一の中央DNSサーバがデータベースの主要バージョンを保持して、他のすべてのDNSサーバが単にコピーを保持しているという）は、単に多くの最新のDNSサーバパッケージに一致しないものでありました。 SQLサーバーやActive Directoryなどの高度なデータベースバックエンドを持つ最新のDNSサーバーパッケージでは、管理者が複数の場所でデータベースの更新を行い（このようなシステムはマルチマスターレプリケーションを採用）、データベースバックエンド独自のレプリケーション機構が他のすべてのサーバーへのレプリケーションを処理することができます。 このパラダイムは、単一で中央、単調に増加する番号で変更を記録するというものとは 単純に一致せず、したがってゾーン転送とは大きく相容れないものである。 高度なデータベースバックエンドを持つ最新のDNSサーバパッケージは、しばしば “シム “シリアル番号を作成し、更新が行われる単一の中央の場所の存在をシミュレートするが、 これはせいぜい不完全なものでしかない。
幸いなことに、これと後で説明するいくつかの理由のために、 一般にそのような洗練されたデータベースバックエンドを使用するDNSサーバは、 データベースレプリケーション機構としてそもそもゾーン転送をほとんど使用せず、 バックエンド自身が提供する非常に優れた分散データベースレプリケーション機構を 通常使用することにしている。 しかし、RFC1034では明確に規定されていなかったため、すべてのクライアントがプリアンブルでシリアル番号のチェックを同じように行うとは限りません。 クライアントによっては、サーバから提供されたシリアルナンバーがクライアントの知るシリアルナンバーと異なるか、ゼロでないかをチェックするだけである。 他のクライアントは、サーバーから供給されたシリアル番号が、クライアントが既に知っているシリアル番号の所定の範囲内であることをチェックする。
Multiple resource recordsEdit
本来、実際のデータ転送では、一つのドメイン名とタイプに対するリソースレコードの各セットは、サーバからクライアントへの個別の応答メッセージで転送された。 しかし、これは非効率的であり、いくつかの DNS サーバーソフトウェアは、DNS プロトコルの応答圧縮メカニズムがデータ転送の総帯域幅要件を削減できるようにすることを目的とした最適化を実装しています。
- “glue” リソースレコードセットを NS、SRV、または MX リソースレコードセットと同じ応答で含めるために “追加セクション処理” を実行する
- 1 つのドメイン名に関するすべてのリソースレコードセットを一緒に収集し、それらが適合する場合は、単一の応答で送信する
一部のクライアントがオリジナルの応答フォーマットのみを期待し、そうした最適化が使用されるとデータ転送に失敗することが書き込まれました。
Exposure of dataEdit
DNS ゾーンに含まれるデータは、運用セキュリティの観点から機密性が高い可能性があります。 これは、サーバーのホスト名などの情報が公知となり、組織の情報を発見するために利用され、さらにはより大きな攻撃対象領域を提供する可能性があるためです。 2017年6月、ロシアのトップレベルドメインを担当するレジストラが、誤ってAXFR経由のDNSゾーン転送を有効にしたため、560万件のレコードが誤って公開されました
2008年、米国ノースダコタ州の裁判所は、公的にアクセスできない情報を取得するために不正な部外者としてゾーン転送を行うことは、ノースダコタ州の法律違反に該当するとの判決を下しています
。