ほとんどのGSLBソリューションは、基本的なトラフィックルーティング用にA、AAAA、CNAMEレコードに焦点を当てています。これは単純なアプリケーションステアリングには十分かもしれませんが、実際のエンタープライズDNS運用ははるかに広い範囲をカバーします: MX、TXT、SRV、PTR、CAA、TLSA、DNSSECレコード、リバースゾーン、動的DNS更新、ゾーン転送。
そのカバレッジが欠けていると、組織は2つの別々のDNSレイヤーを運用しなければなりません。GSLB用の1つのインターフェース、高度なDNSレコード用の別の権威サーバー、DNSSEC用の別のCLI操作、ゾーンインポート用の手動転送、移行用の追加スクリプト。結果として、同じドメインに対する所有権の断片化と運用リスクの増加が生じます。
DNSSEC管理はこの断片化の最も敏感なポイントの1つです。署名済みゾーンには、DNSKEY、DS、RRSIG、NSEC、NSEC3レコードを正しく生成および公開する必要があります。これを完全にCLIコマンドや手動ファイル編集に任せると、エラーのリスクが高まります。
ゾーン移行とマルチ権威アーキテクチャは同様の問題を引き起こします。レガシーDNSソースからレコードを取り、衝突するレコードを管理し、SOAシリアル動作を正しく設定し、セカンダリサーバーへのゾーン転送を提供するすべてに、一貫したポリシーが必要です。手動のゾーンファイルコピーとリロードワークフローは、現代のGSLB運用には不十分です。
TR7 DNSレコード管理は、35のレコードタイプ、DNSSEC、AXFRプライマリ/セカンダリ、DNS UPDATE、SOA編集モード、スマートAXFR衝突ポリシーを通じて、完全なDNS管理をGTMプラットフォームのネイティブな一部とします。
TR7はDNS管理をレコード入力画面ではなく、権威DNS機能をGSLB判断エンジンと統合する運用レイヤーとして扱います。
TR7は権威DNS機能をREST APIおよび管理インターフェースと組み合わせます。運用者は単一のインターフェースからレコードタイプ、ゾーン設定、TTL値、GTM動作を管理します。
DNSSECサポートはドメインレベルで有効化できます。DNSKEY、DS、RRSIG、NSEC、NSEC3および関連レコードタイプはDNS管理モデルの一部として扱われます。
TR7はプライマリとして動作してセカンダリサーバーにゾーン転送を提供することも、セカンダリとして動作してAXFR経由で外部権威ソースからゾーンを取得することもできます。このモデルは、移行、冗長性、分散DNSアーキテクチャに使用されます。
AXFRを介して到着するレコードが既存のレコードと衝突する場合、運用者はuseNew、preserveCurrent、またはcombine動作を選択できます。ゾーン移行とマルチソース統合は決して盲目的な上書きにはなりません。
DNSレコード管理は、古典的なDNSレコードカバレッジ、DNSSEC、ゾーン転送、動的更新、GTMレコード動作を単一のモデルに統合します。
TR7はA、AAAA、CNAME、MX、TXT、SOA、NS、SRV、PTR、CAA、DNSKEY、DS、RRSIG、NSEC、NSEC3、NSEC3PARAM、ALIAS、AFSDB、CERT、CDNSKEY、CDS、DNAME、HINFO、KEY、LOC、LUA、NAPTR、OPENPGPKEY、RP、SMIMEA、SPF、SSHFP、TLSA、TKEY、TSIG、URIをカバーします。この広さは、GSLBレコードを超えた完全なDNS運用に重要です。メール、証明書セキュリティ、サービスディスカバリ、リバースDNS、DNSSECニーズはすべて同じプラットフォームで提供でき、別のDNSツールは不要です。
DNSSECはドメインレベルで有効化できます。NSEC、NSEC3、NSEC3PARAM、RRSIG、DNSKEY、DS、CDS、CDNSKEYレコードタイプがDNSSEC運用の一部としてサポートされます。これによりゾーンの検証可能性が向上し、DNSスプーフィングリスクに対するセキュリティ層が追加されます。運用者はもはやDNSSECをGSLBレコード管理外の別の手動プロセスとして扱う必要はありません。
プライマリモードでは、TR7は権威ゾーンソースとして機能し、セカンダリサーバーへのゾーン転送を提供できます。完全ゾーン転送と増分転送動作はDNSアーキテクチャに応じて使用できます。これは高可用性および複数DNSサーバー展開に必要です。単一の地点からゾーンを管理し、他のサーバーに伝搬することで運用一貫性が保証されます。
セカンダリモードでは、TR7はAXFR経由で別の権威ソースからゾーンを受け取れます。このモデルは移行、Express管理、または既存のDNSインフラを破壊することなくTR7 GTMレイヤーに移行する場合に有用です。レコードが外部ソースから取得される間、管理と判断エンジン統合をTR7側で確立できます。既存のDNS投資を一度に放棄せずに段階的な移行が可能です。
DNS NOTIFYにより、セカンダリパーティはゾーン変更後に更新が必要であることを知ることができます。TR7は受信通知統計を監視範囲内で評価できます。この可視性は、ゾーン転送動作が実際に機能しているかを理解するのに重要です。大規模DNSアーキテクチャでは、転送遅延と更新チェーンが追跡しやすくなります。
DNS UPDATEにより、アプリケーションまたはインフラコンポーネントがDNSレコードをプログラム的に更新できます。例えば、アプリケーションサーバーが自身のAレコードを動的に公開できます。この動作は自動化および弾力的なインフラシナリオで価値があります。動的更新権限は慎重に制限され、セキュリティポリシーと共に計画されるべきです。
DEFAULTモードは日付ベースのシリアルアプローチを使用でき、EPOCHモードはUnix時間、INCREASEモードは+1インクリメント、OFFモードは自動調整を無効にします。SOAシリアル動作はプライマリ/セカンダリ転送チェーンに重要です。誤ったシリアル管理はセカンダリサーバーが変更を見逃す原因になります。TR7はこの動作をドメイン設定として構成可能にします。
TTLはrecordObj.ttlを介してレコードごとに管理され、デフォルトは3600秒です。重要なGTMレコードに低いTTLは高速な切り替えとフェイルオーバーを可能にし、より静的なレコードはキャッシュ効率のために高いTTLを使用できます。TTLはDNS運用におけるパフォーマンスと変更速度の基本的なトレードオフです。TR7はこの値をレコード管理の自然な一部として提示します。
ローカルモードではTR7がゾーンを所有し、レコードは完全に編集可能になります。Expressモードでは、レコードはAXFR経由で外部DNSソースから取得され、パススルーまたは段階的移行モデルを適用できます。この区別は、DNSインフラ全体を一度に移行できない組織にとって重要です。移行プロセスはより制御され、可逆的になります。
AXFRインポート中、受信レコードは既存のレコードと衝突することがあります。useNewモードは新しいレコードを昇格させ、preserveCurrentは既存のレコードを保持し、combineは両方をマージします。これらのオプションは移行中のデータ損失や予期しない上書きのリスクを低減します。運用者は各ゾーンインポートプロセスに適切な衝突戦略を選択できます。
ドメインおよびサブドメイン検証により、レコードが正しいゾーンの下に定義されることが保証されます。IPv4およびIPv6アドレスは標準形式に正規化されます。末尾ドット動作はDNS標準と一致します。これらの制御は手動レコード入力でよく見られる入力およびフォーマットエラーを低減します。
ドメインメタデータフィールドは、ゾーン動作または外部システム統合のための追加情報を保持できます。REST APIアクセスはDNSインスタンスごとにAPIキーで管理できます。この構造は自動化、統合、マルチインスタンスDNS運用に重要です。レコード管理はUIに限定されず、API駆動のプロセスにも開かれています。
DNSレコード管理はドメイン標準化、IP正規化、AXFR動作、ポート範囲、キャッシュ、SOAシリアル管理と共に運用されます。
サブドメインチェックは、入力されたレコードが該当ドメインの下にあることを確認します。末尾ドットとドメインマッチングの両方が考慮されます。この動作により、誤ったゾーンの下にレコードを入力するリスクが低減されます。
DNSドメイン文字列は標準形式で末尾ドット付きで処理されます。欠落した末尾ドットは自動的に補完できます。これにより絶対ドメイン名の動作が一貫します。
AレコードはIPv4 correctFormロジックを使用して正規化され、AAAAレコードはIPv6 correctFormロジックを使用します。これにより、同じIPの異なる表記がレコードインベントリにノイズを生むことを防ぎます。正規化は監査と比較操作を簡素化します。
AXFR同期操作では、SOA以外のレコードタイプを同期範囲に含めることができます。SOAは別のシリアルおよび権威動作を持ち、特別に処理されます。この区別によりゾーン転送の制御が向上します。
useNew、preserveCurrent、combineオプションは、インポート中に衝突するレコードがどう処理されるかを決定します。useNewは受信データを優先し、preserveCurrentは既存データを優先し、combineは両方のレコードを保持することを目指します。移行計画に従って正しい動作を選択する必要があります。
DNSインスタンスの内部、API、フォワーダー内部、フォワーダーAPIポート範囲は個別に計画できます。この分離により、マルチインスタンスおよびフォワーダーアーキテクチャでのポート衝突が低減されます。運用チームはDNSサービスをより整理された方法で配置できます。
クエリキャッシュTTL、ネガティブクエリキャッシュTTL、最大キャッシュエントリ値はインスタンスレベルで管理できます。キャッシュはDNS応答時間と権威バックエンドの負荷に直接影響します。低TTLを必要とするGTMレコードは、全体的なキャッシュ動作と共に計画されるべきです。
SOA編集モードは、プライマリ書き込みでシリアル値がどう変わるかを決定します。セカンダリ側で低シリアル動作のために別の設定を使用できます。正しいシリアル管理は継続的なゾーン転送の基礎です。
組織は自社のドメインに対してDNSSECを有効化し、DNSKEY、DS、RRSIG、NSEC/NSEC3チェーンを管理下に置けます。ゾーンは検証可能になります。DNSセキュリティはTR7 DNS管理内で処理され、手動CLI操作に分割されることはありません。
ゾーンはレガシー権威ソースからAXFR経由で取得され、レコードはTR7側でレビューされます。衝突時にはuseNew、preserveCurrent、またはcombineポリシーが適用されます。組織はDNS全体を一度に移動させることなく制御された方法で移行できます。
複数のDCに保持されたゾーンレコードはスマートAXFRプロセスを介して収集できます。衝突するレコードは選択されたポリシーに従ってマージまたは保持されます。これは断片化されたDNSインベントリを集中化するために使用されます。
アプリケーションサーバーまたは自動化システムは、DNS UPDATE経由で自身のレコードを更新できます。弾力的なインフラでは、新しいノードがオンラインになるとDNSレコードを自動的に作成できます。更新権限はセキュリティポリシーを通じて制限されるべきです。
in-addr.arpaまたはIPv6リバースゾーン構造はTR7 DNS管理下で維持できます。PTRレコードはネットワークインベントリおよびリバース解決ニーズのために管理されます。リバースゾーンのセキュリティもDNSSECと共に強化できます。
CAAレコードを使用して、ドメインに証明書を発行できる認証局を制限できます。TLSAレコードはDANEシナリオでDNSを介して証明書バインディングコンテキストを公開します。これらのレコードはDNSセキュリティをアプリケーションおよび証明書運用と統合します。
35のレコードタイプ、DNSSEC、AXFRゾーン転送、DNS UPDATE — 単一の管理レイヤーで。ご自身のインフラ上でライブセットアップをご案内します。