7. 設計上の問題
7. 設計上の問題
このセクションでは、DNS UPDATEプロトコルに関連するさまざまな設計決定と明確化について説明します。
7.1. このドキュメントは意図的にすべての複雑さをサーバーに配置します。リクエスタの動作は大部分が指定されていないため、リクエスタに最大限の自由を与えることができます。
7.2. ワイルドカード所有者名(つまり、「*」ラベルを持つ名前)は、ワイルドカードが無効化される制限付きでUPDATEプロトコルでサポートされています(セクション1.1.3を参照)。これは、更新のワイルドカードが文字通りに扱われ、ワイルドカード展開または一致を実行しないことを意味します。
7.3. RRsetのTTLは、RRsetを削除してから新しいTTLで再度追加することで更新できます。ただし、CNAMEは名前の他のRRsetと共存できないため、CNAMEを含む更新は、不正な構成の作成を回避するために慎重に行う必要があります。
7.4. 重複するRRは黙って無視されます。これは、更新が、同一のRDATAでゾーンにすでに存在するRRを追加しようとする場合、更新は成功しますが、ゾーンコンテンツに影響を与えないことを意味します。
7.5. セキュアDNS更新がない場合、サーバーは、プライマリマスターゾーンのサーバーの記述で静的に構成されたソースアドレスから来る更新のみを受け入れることが期待されます。DHCPサーバーは、この静的に構成されたリストに含まれる可能性のある候補です。
7.6. このプロトコルを使用してゾーンを作成することはできません。これは、スレーブサーバーにマスターサーバーが誰であるかを通知する規定がないためです。このプロトコルは、将来このケースをカバーするために拡張されることが期待されます。したがって、この時点では、SOA RRの追加はサポートされていません。同様の理由で、SOA RRの削除もサポートされていません。
7.7. 名前が少なくとも1つのRRを所有することを指定する前提条件は、QUERYとはセマンティクスが異なります。QUERYがこの名前のRRsetに対してクエリされた場合、<NOERROR,ANCOUNT=0>ではなくNXDOMAINを返すのに対し、UPDATEの前提条件[セクション2.4.4]は満たされません。
7.8. UDP応答が転送中に失われ、タイムアウト条件のためにリクエストが再試行される可能性があります。この場合、プライマリマスターによって最初に受信されたときに成功したUPDATEは、重複したリクエストへの応答が最終的にリクエスタによって受信されたときに失敗したように見える可能性があります。(これは、更新が適用された後、元の前提条件が満たされなくなる可能性があるためです。)このため、正確な応答コードを必要とするリクエスタはTCPを使用する必要があります。
7.9. 正確な応答コードを必要とするリクエスタがTCPを使用してUPDATEトランザクションを開始するため、TCP経由でリクエストを受信する転送者は、TCPを使用してそれを転送する必要があります。
7.10. SOA SERIALの自動インクリメントの延期は、シリアル番号を節約し、2**32でのラップアラウンドを頻繁に発生しないようにするために可能になります。目に見える(DNSクライアントに対して)SOA SERIALは、ゾーンが異なる場合に異なる必要があります。QUERY応答のAuthority Section SOAは、この前提条件の目的のための可視性の形式であることに注意してください。
7.11. ゾーンのSOA SERIALは、DNSの古いが広くインストールされている実装との相互運用性の問題のため、ゼロ(0)に設定すべきではありません。SOA SERIALをインクリメントする際に、インクリメントの結果がゼロ(0)である場合(2**32の周りでラップアラウンドする場合に真になる)、再度インクリメントするか、1(1)に設定する必要があります。この主題の詳細については、[RFC1982]を参照してください。
7.12. RRsetをキャッシュする際に必要なTTLの最小化のため、RRset内のすべてのTTLを同じ値に設定することをお勧めします。DNSメッセージフォーマットは、同じRRset内にバリアントTTLが存在することを許可し、このバリアンスはゾーン内に存在する可能性がありますが、このようなバリアンスは直感に反する結果をもたらし、その使用は推奨されません。
7.13. ゾーンカット管理は、Updateセクションの追加および削除操作にいくつかの曖昧なコーナーケースを提示します。ゾーンのルートの最後のNS RRでない限り、NS RRを削除することは可能です。名前からすべてのRRを削除する場合、ゾーンのルートのSOAおよびNS RRは影響を受けません。RRsetを削除する場合、ゾーンの上部でSOAまたはNS RRsetを削除することはできません。SOAを追加しようとする試みは、SOAがすでに存在する場合は置換操作として扱われ、SOAが新しい場合は無操作として扱われます。
7.14. 新しいRRを追加する際に、プライマリマスターサーバーでセマンティックチェックは必要ありません。したがって、リクエスタは、ターゲット名が存在しない場合や、元のRRを有用にする適切なRRsetを持っていない場合でも、CNAMEまたはNSまたはその他の種類のRRを追加する可能性があります。この種のチェックを実装するプライマリマスターサーバーは、ゾーン外の依存関係(その真偽を権威的にチェックできない)を回避するために細心の注意を払い、すべてのそのようなチェックをプレスキャンフェーズ中に実装する必要があります。
7.15. 非終端またはワイルドカードCNAMEは、[RFC1035]によってよく指定されておらず、それらの使用はおそらく予測不可能な結果につながります。それらの使用は推奨されません。
7.16. 空の非終端(子を持つがそれ自体のRRを持たないノード)は、その名前の任意のタイプのクエリに対して<NOERROR,ANCOUNT=0>応答を送信します。空の終端ノードの規定はありません。したがって、終端ノードのすべてのRRが削除された場合、名前はもはや使用されず、その名前の任意のタイプのクエリはNXDOMAIN応答をもたらします。
7.17. 深いAXFR依存グラフでは、スレーブが互いに相互に依存することは歴史的にエラーではありませんでした。この構成は、すべてのスレーブがプライマリマスターへの継続的な接続を持っていない場合でも、ゾーンをプライマリマスターからすべてのスレーブに流すことを可能にするために使用されてきました。UPDATEのAXFR依存グラフの使用は、この種の依存ループを禁止します。これは、UPDATE転送には、AXFRで使用されるSOA SERIALプリテストに類似したループ検出がないためです。
7.18. 新しいゾーンカットによって隠された以前に存在する名前は、ゾーン転送の目的のために、そのような名前のクエリが新しいサブゾーンのサーバーに参照される場合でも、親ゾーンの一部と見なされます。ゾーンカットが削除された場合、それによって隠されたすべての親ゾーン名は、クエリに対して再び表示されます。(これは[RFC1034]の明確化です。)
7.19. サーバーがゾーンとその子の両方に対して権威がある場合、それらの間のゾーンカットでの名前のクエリは、子ゾーンからのデータのみを使用して権威的に回答されます。(これは[RFC1034]の明確化です。)
7.20. SOA RRを使用した更新の順序付けは問題があります。これは、ゾーンのNS RRのどれがプライマリマスターを表すかを知る方法がなく、ゾーンがプライマリマスターで最後に変更されてからSOA.REFRESHタイマーが経過していない場合、ゾーンスレーブが古い可能性があるためです。順序付けられた更新を必要とするゾーンは、NOTIFY([RFC1996]を参照)とIXFR([RFC1995]を参照)を実装するサーバーのみを使用し、順序付けられた更新を試みる際に前提条件エラーを受信するクライアントは、ゾーンが落ち着くまでランダムな遅延期間の後に再試行することをお勧めします。