セカンダリDNSサーバーとは、もともとプライマリ権威DNSサーバーのバックアップとして機能するものを意味していました。プライマリサーバーのレコードに変更が加わると、ゾーン転送が行われ、セカンダリDNSサーバーがプライマリサーバーと同期されます。セカンダリサーバーはその時、プライマリサーバーであるかのようにレコードを処理できますが、変更ができるのはプライマリサーバーだけで、セカンダリサーバーではありません。これが、必要に応じて分散される異なるサーバー間で冗長性が作り出されます。
セカンダリDNSを活用する共通の方法がいくつもありますが、その中に次のような方法があります。
受動的なバックアップとしてのセカンダリDNS - セカンダリDNSサーバーがプライマリサーバーがダウンするまで、アイドリング状態でいます。フェイルオーバーが発生した時点で、セカンダリがレコードの処理を始められます。
能動的なバックアップとしてのセカンダリDNS - セカンダリDNSサーバーはプライマリサーバーと連携してレコードを処理します。
隠れプライマリを持つセカンダリDNS - セカンダリサーバーにのみ対象とするregistrarポイントでネームサーバーが記録し、基本的にセカンダリをプライマリネームサーバーとして扱います。
セカンダリDNSオーバーライドは、隠れプライマリモデルを持つセカンダリDNS上で構築されます。これは、お客様の指示通りにレコードを処理するだけでなく、お客様がCloudflareのネットワークを介して、あらゆるA/AAAA/CNAMEレコードをプロキシできるように許可することで実現します。これは、現在CloudflareがプライマリDNSプロバイダーとして機能する方法と似ています。
次の例を考えてみてください。
example.com Cloudflare IP - 192.0.2.0
example.com origin IP - 203.0.113.0
Cloudflareのセキュリティとパフォーマンスサービスをうまく活用するために、配信元IPがインターネットから隠れた状態のままであることを確認する必要があります。
図1：隠れプライマリネームサーバーがないセカンダリDNS
図1は、隠れプライマリネームサーバーがなく、リゾルバーがクエリをどちらか選択できることを示しています。これで、2つの問題が起こります。
RFC 1034とRFC 2182に違反します。これは、Cloudflareサーバーがプライマリネームサーバーとは異なる応答をするためです。
配信元IPが、インターネットに公開されてしまいます。
図2：隠れプライマリネームサーバーがあるセカンダリDNS
図2は、リゾルバーが常にCloudflareセカンダリDNSサーバーにクエリを出していることを示しています。
セカンダリDNSオーバーライドUIは、プライマリUIと類似していますが、レコードの編集ができないという違いが1つだけあります。
図3：セカンダリDNSオーバーライドダッシュボード
図3では、レコードがすべてプライマリDNSサーバーから転送されています。test-grey（テスト-グレー）とtest-mx（テスト-mx）が、通常のDNSレコードとして扱われる一方で、test-orang（テスト-オレンジ）とtest-aaaa-orange（テスト-aaaa-オレンジ）がオーバーライドされてCloudflareネットワークを経由してプロキシされます。
水面下では、ネームに基づいて転送されたレコードとペアになるオーバーライドレコードを保管します。セカンダリオーバーライドについては、レコードをオーバーライドする時の種類についてそれほど気にしていません。その理由は2つあります。
RFC1912によると、他のレコードと同じネームのCNAMEレコードを持つことはできません。（これは適用できないDNSSECレコードがあります。RFC2181を参照してください）
AレコードもAAAAレコードもアドレスタイプのレコードで、同じネームですべてプロキシされるか、すべてプロキシされないかのどちらかである必要があります。
つまり、「example.com」というネームがついたAレコードとAAAAレコードがいくつかある場合、そのうち1つがプロキシされる場合、すべてのレコードがプロキシされるということです。UIは、「オレンジ色の雲」ボタンを使って追加のオーバーライドレコードを保管するという考えを抽象化するのに役立ちます。これは、クリックされた時、そのネームが持つすべてのA/AAAAレコードまたはCNAMEレコードに適用されるオーバーライドレコードを作成します。
通常、Zone ApexにCNAMEを置くことは許可されません。例：
example.com CNAME other-domain.com
前述の通り、RFC1912に従わず、少なくとも1つ、別のSOAレコードとNSレコードが同じネームを持っているということを意味するため、これは許可されません。CloudflareはCNAME Flatteningを使用することで解決できます。CNAME FlatteningはプライマリDNSプロダクト内で一般的に用いられるテクニックです。権威サーバーにクエリが来たときに、CNAMEレコードの代わりにアドレスレコードを返すことができます。
セカンダリDNSオーバーライドUIを介したレコードの編集防止に関する前述の説明とは反対に、ApexのCNAMEはこの規則の例外です。ユーザーは、通常のセカンダリ DNSレコードに加えて、ApexでCNAMEを作成することができますが、RFC1912で定義された同じ規則も適用されます。つまり、ユーザーの決定内容に応じて、ApexレコードのCNAMEは通常のDNSレコードまたはプロキシされたレコードとして扱うことができるということです。ApexレコードのCNAMEのプロキシステータスに関わらず、プライマリDNSサーバーから転送されたその他のA/AAAレコードにオーバーライドします。
Apexレコードでセカンダリ、オーバーライド、CNAMEのマージ
レコード編集時間に、Apexレコードでセカンダリ、オーバーライド、CNAMEのマージをすべて行います。つまり、DNSリクエストがエッジの権威サーバーに送信された時、超高速時間でレコードを戻すことができます。このワークフローは、図4で示されています。
図4：レコードのマージ処理
ゾーンビルダー内でのステップは以下の通りです。
ApexにCNAMEがあるかどうかを確認し、ある場合はApexにある他のA/AAAセカンダリレコードをすべてオーバーライドします。
各セカンダリレコードについて、一致するオーバーライドレコードがあるかどうかを確認し、ある場合はオーバーライドレコードのプロキシステータスをそのネームを持つセカンダリレコードすべてに適用します。
他のセカンダリレコードをそのままに
セカンダリDNSオーバーライドは、ゾーンのすべてをプライマリプロバイダーとしてのCloudflareDNSに転送せずに、Cloudflareネットワークを活用したいユーザーにとって最適なオプションです。Cloudflare側における情報の不正な編集を心配することなく、プライマリ側でセキュリティとアクセス制御を管理できます。
セカンダリDNSオーバーライドは、現在Enterprise Planで利用できます。ご利用をお考えの場合は、アカウントチームにお知らせください。セカンダリDNSオーバーライドに関する追加の資料は、当社のサポート記事をご参照ください。