「Foundation DNS」の公式リリースで権威DNSを改善

Foundation DNSの公式リリースを発表できることを嬉しく思います。このリリースは、新しい高度なネームサーバー、さらなる耐障害性、高度な分析を備え、企業のお客様の複雑な要件に対応できます。Foundation DNSは、2010年の発売以来、Cloudflareの権威DNSサービスにおいて最大の飛躍を遂げたサービスのひとつです。当社のお客様が、最高レベルのパフォーマンス、信頼性、セキュリティ、柔軟性、高度な分析を備えたエンタープライズ対応の権威DNSサービスに関心をお持ちでいることは承知しています。

本日より、権威DNSを含むすべての新規契約をされる企業のお客様は、Foundation DNS機能セットを利用できるようになり、既存の企業のお客様につきましたは、今年中にFoundation DNS機能を利用いただけるようになります。すでに当社の権威DNSサービスをご利用いただいている企業のお客様で、Foundation DNSの早期導入にご興味をお持ちの方は、担当のアカウントチームにご連絡いただければすぐに有効化させていただきます。さあ、始めましょう...

なぜDNSが重要なのか？

エンドユーザーの観点から見ると、DNSはインターネットを使用可能なものにするものです。DNSはインターネットの電話帳のようなもので、www.cloudflare.comなどのホスト名をIPアドレスに変換してブラウザ、アプリ、デバイスでサービスに接続できるようにするです。DNSがなければ、ユーザーはモバイルデバイスやデスクトップでWebサイトにアクセスするたびに、「108.162.193.147」や「2606:4700:58::adf5:3b93」のようなIPアドレスを覚えていないといけません。www.cloudflare.comのかわりにそのようなIPアドレスを覚えなければならないことを想像してみてください。DNSは、ソーシャルメディアから銀行取引、医療ポータルまで、インターネット上のあらゆるエンドユーザー向けアプリで使用されています。人々のインターネット利用は、完全にDNSに依存しています。

ビジネスの観点から考えると、DNSはWebサイトへのアクセスやアプリケーションへの接続の最初のステップとなります。デバイスがサービスにアクセスし、ユーザーを認証し、要求された情報を提供するためには、まず接続先を知る必要があります。DNSクエリを迅速に解決することは、Webサイトやアプリの応答速度の差につながり、ユーザーエクスペリエンスに大きな影響を与える可能性があります。

DNS障害が発生した場合、その影響は明らかです。2016年にDynが経験した障害と同じように、複数の利用者の多いeコマースサイトが読み込まれない場合を想像してみて下さい。あるいは、あなたが勤める会社で、自社の運営するWebサイトにお客様がログインできず、販売する商品やサービスを購入することができない場合、DNSの停止は、文字通り収益の機会を失うことになります。DNSは当然のように思われがちですが、正しく動作しなくなって初めてその存在に気づくことになりますが、幸いなことに、Cloudflareの権威DNSを使用している場合、このような事態はあまり心配する必要のない問題です。

常に改善の余地があります

Cloudflareは10年以上にわたり権威DNSサービスを提供してきました。当社の権威DNSサービスは、数多くの異なるトップレベルドメインTLDにわたる数百万のドメインをホストしています。レコード数がわずか数個の単一ドメインから、複数のドメインにまたがる数千万レコードのお客様まで、あらゆる規模のお客様にご利用いただいています。企業のお客様は、当然のことながら、当社のDNSサービスに最高レベルのパフォーマンス、信頼性、セキュリティ、柔軟性、そして詳細な分析を求めています。当社の権威DNSはお客様に好まれますが、こうしたカテゴリーでは常に改善の余地があることを私たちは認識しています。そのため、新しい機能と構造的な変更を加えて、DNSアーキテクチャにいくつかの大幅な改善を加えました。その名を「Foundation DNS」とし、私たちはこの改善されたサービスを自信を持って提供します。

Foundation DNSのご紹介

Foundation DNSは、企業向けの新たな権威DNSサービスとして、既存の権威DNSサービスの信頼性、セキュリティ、柔軟性、分析を強化するよう設計されました。Foundation DNSの詳細をご紹介する前に、まずFoundation DNSが当社の権威DNSサービスにもたらすものを簡単にまとめます。

高度なネームサーバーは、DNSの信頼性を次のレベルに引き上げます。
新しいゾーンレベルのDNS設定は、DNS固有の設定のより柔軟な構成を実現します。
アカウントおよびゾーンごとに一意のDNSSECキーは、DNSSECのセキュリティと柔軟性を強化します。
GraphQLベースのDNS分析は、DNSクエリについてさらに詳細な知見を提供します。
新しいリリースプロセスにより、企業のお客様に最大限の安定性と信頼性を提供します。
シンプルなDNS価格設定に加え、DNS専用ゾーンとDNSレコードに対してより寛大なクォータを設定しています。

ここからは、これらの新しい「Foundation DNS」の機能について深堀していきましょう。

高度なネームサーバー

Foundation DNSでは、お客様の企業の信頼性向上に特に重点を置いた高度なネームサーバーを導入します。Cloudflareの標準権威ネームサーバーは、ゾーンごとに一対であり、cloudflare.comドメイン内で名前を使用します。以下にその例を示します：

次に、Foundation DNSの高度なネームサーバーを使用して同じゾーンを見てみましょう

$ dig mycoolwebpage.xyz ns +noall +answer 
mycoolwebpage.xyz.	86400	IN	NS	kelly.ns.cloudflare.com.
mycoolwebpage.xyz.	86400	IN	NS	christian.ns.cloudflare.com.

高度なネームサーバーは、いくつかの方法で信頼性を向上しています。最初の改善点は、Foundation DNSの権威サーバーが複数のTLDに分散されていることです。分散により、TLDネームサーバーなど、DNSインフラストラクチャに影響を与える可能性がある大規模なDNS障害とDDoS攻撃から保護します。Foundation DNS権威ネームサーバーは現在、グローバルDNSツリー構造の複数のブランチに配置されており、お客様をさらに潜在的な障害や攻撃から保護します。

$ dig mycoolwebpage.xyz ns +noall +answer 
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.com.
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.net.
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.org.

また、上記のFoundation DNSで返されたNSがもう一つあることにもお気づきかもしれません。これも改善点ではありますが、皆様が考えているような理由ではありません。これらのネームサーバーの1つをそれぞれのIPアドレスに解決すると、これをもう少し理解しやすくなります。まずは標準的なネームサーバーからやってみましょう：

2つのネームサーバーに対して合計6つのIPアドレスが存在します。実を言うと、権威ネームサーバーを照会する際にDNSリゾルバーが実際に関心を持っているのは、これだけです。DNSリゾルバーは通常、権威サーバーの実際のドメイン名を追跡しません。特定のドメインに対するクエリを解決するために使用できるIPアドレスの順不同リストを維持するのみとなります。そのため、標準の権威ネームサーバーでは、DNSクエリの解決に使用する6つのIPアドレスをリゾルバーに割り当てました。次に、Foundation DNSの高度なネームサーバーのIPアドレスを見てみましょう：

$ dig kelly.ns.cloudflare.com. +noall +answer
kelly.ns.cloudflare.com. 86353  IN      A       108.162.194.91
kelly.ns.cloudflare.com. 86353  IN      A       162.159.38.91
kelly.ns.cloudflare.com. 86353  IN      A       172.64.34.91

$ dig christian.ns.cloudflare.com. +noall +answer
christian.ns.cloudflare.com. 86353 IN   A       108.162.195.247
christian.ns.cloudflare.com. 86353 IN   A       162.159.44.247
christian.ns.cloudflare.com. 86353 IN   A       172.64.35.247

ご覧いただけましたでしょうか。Foundation DNSは、ゾーンに提供するのと同じIPアドレスを各権威ネームサーバーに提供します。この例では、DNSクエリの解決に使用するリゾルバーには、3つのIPアドレスを提供しただけです。「3つより6つの方がいいのではないか、これはダウングレードではないのか」と考える方もいるかと思います。多いほど良いというわけではありません。その理由をお話しします。

$ dig blue.foundationdns.com. +noall +answer
blue.foundationdns.com. 300     IN      A       108.162.198.1
blue.foundationdns.com. 300     IN      A       162.159.60.1
blue.foundationdns.com. 300     IN      A       172.64.40.1

$ dig blue.foundationdns.net. +noall +answer
blue.foundationdns.net. 300     IN      A       108.162.198.1
blue.foundationdns.net. 300     IN      A       162.159.60.1
blue.foundationdns.net. 300     IN      A       172.64.40.1

$ dig blue.foundationdns.org. +noall +answer
blue.foundationdns.org. 300     IN      A       108.162.198.1
blue.foundationdns.org. 300     IN      A       162.159.60.1
blue.foundationdns.org. 300     IN      A       172.64.40.1

CloudflareがAnycastを使用している事はご存知かと思います。ご想像の通り、当社のDNSサービスはAnycastを活用し、当社の権威DNSサーバーをグローバルに、そしてインターネット上のユーザーやリゾルバーにできるだけ近いところで利用できるようにしています。標準ネームサーバーは、単一のCloudflare Anycastグループによって、すべてのデータセンターからアドバタイズされます。ヨーロッパに焦点を当てると、標準的なNSのデプロイメントでは、両方のネームサーバーがすべてのデータセンターからアドバタイズされていることがわかります。

上記の標準ネームサーバからこれら6つのIPアドレスを取得し、「hostname.bind」を検索します。TXTレコードは、DNSクエリーの解決場所として最も近いデータセンターの空港コードまたは物理的な場所を示しています。この出力を見ると、多い方が必ずしも良いとは限らない理由がお分かりいただけるかと思います。

ご覧のように、ロンドン近くからクエリされた場合、これらの6つのIPアドレスすべてが同じロンドン (LHR) のデータセンターにルーティングされます。つまり、ロンドンのリゾルバがCloudflareの標準的な権威DNS を使用してドメインのDNSクエリを解決する場合、どのNSのIPアドレスがクエリされようと、常に同じ物理的な場所に接続されます。

$ dig @108.162.194.91 ch txt hostname.bind +short
"LHR"

$ dig @162.159.38.91 ch txt hostname.bind +short
"LHR"

$ dig @172.64.34.91 ch txt hostname.bind +short
"LHR"

$ dig @108.162.195.247 ch txt hostname.bind +short
"LHR"

$ dig @162.159.44.247 ch txt hostname.bind +short
"LHR"

$ dig @172.64.35.247 ch txt hostname.bind +short
"LHR"

「これが意味するものは何か、自分との関係性は？」と疑問に思われるかもしれません。一例を見てみましょう。ロンドンのCloudflare標準ネームサーバーを使用してドメインを解決する必要があり、ロンドンにあるパブリックリゾルバーを使用している場合、リゾルバーは、到達しようとしているNSに関係なく、常にCloudflare LHRデータセンターに接続します。Anycastであるため、他の選択肢はありません。

Anycastのため、LHRデータセンターが完全にオフラインになった場合、LHR向けのトラフィックはすべて他の近くのデータセンターにルーティングされ、リゾルバーは正常に機能し続けます。ただし、LHRデータセンターはオンラインであったが、DNSサービスがDNSクエリに応答できないという万が一のシナリオでは、リゾルバは他のデータに到達できないため、これらのDNSクエリを解決する方法がありません。仮にIPアドレスが100個あったとしても、このシナリオでは役に立ちません。最終的に、キャッシュされた応答は期限切れとなり、ドメインは最終的に解決できなくなります。

Foundation DNSの高度なネームサーバーは、Anycastの活用方法を変えるため2つのAnycastグループを使用しています。これは、すべてのデータセンターからすべての権威ネームサーバのIPアドレスがアドバタイズされるという従来のパラダイムを打破する方法です。2つのAnycastグループを使用するということは、Foundation DNSの権威ネームサーバーが各データセンターからアドバタイズされるのではなく、実際には互いに異なる物理的な場所を持つことを意味します。下の図は、同じリージョンで2つのAnycastグループを使用した場合の例です：

Foundation DNSがネームサーバのアドバタイズに2つのAnycastグループを使用していることがわかったので、標準的な権威DNSの6つの権威IPアドレスとFoundation DNSの3つのIPアドレスの比較に戻りましょう。この例では、Foundation DNSサーバーがどこからアドバタイズされているかを見てみましょう：

ご覧ください。3つのNSのIPアドレスのうち1つがマンチェスター（MAN）の別のデータセンターからアドバタイズされているため、前述の障害シナリオに対してFoundation DNSの信頼性と障害復旧能力が向上します。一部の都市ではCloudflareは複数のデータセンターで運用されているため、3つのクエリーすべてが同じ空港コードを返すことになります。少なくともこれらのIPアドレスの1つが別のデータセンターからアドバタイズされることは保証しますが、ご自身でテストしたいというお客様もいることは承知しています。このような場合、追加のクエリーを使用することで、IPアドレスが異なるデータセンターからアドバタイズされていることを知ることができます。

$ dig @108.162.198.1 ch txt hostname.bind +short
"LHR"

$ dig @162.159.60.1 ch txt hostname.bind +short
"LHR"

$ dig @172.64.40.1 ch txt hostname.bind +short
"MAN"

太字のテキストの「m」の前の数字は、クエリに応答したデータセンターを表しています。3つの応答のいずれかでその数字が異なる場合、Foundation DNS権威ネームサーバーの1つが、異なる物理的な場所からアドバタイズされているということがわかります。

$ dig @108.162.198.1 +nsid | grep NSID:
; NSID: 39 34 6d 33 39 ("94m39")

Foundation DNSは2つのAnycastグループを活用することで、従来の障害シナリオもシームレスに処理することができます。DNSリゾルバーは、特定のドメインに対して返されたすべての権威ネームサーバーへのリクエストを監視しますが、最も高速な応答を提供しているNSを主に使用します。

この構成では、DNSリゾルバーは2つの異なるCloudflareデータセンターにリクエストを送信できるため、1つの物理的な場所で障害が発生した場合も、クエリは2番目のデータセンターに自動的に送信され、そこで適切に解決することができます。

Foundation DNSの高度なネームサーバーは、企業のお客様にとって信頼性を大きく向上させるものです。私たちは、今すぐにでも既存ゾーンの高度なネームサーバーを有効にしたいという企業のお客様を歓迎します。ゾーンに対してFoundation DNSの高度なネームサーバーを有効にした後も、以前の標準的な権威DNSネームサーバーは引き続き機能し、ゾーンに対するクエリに応答するため、Foundation DNSへの移行にダウンタイムは発生しません。お客様はFoundation DNSの高度なネームサーバーに移行する際のカットオーバーやその他のサービスに影響を与えるイベントを計画する必要はありません。

新しいゾーンレベルのDNS設定

これまで、企業のお客様からセカンダリDNSオーバーライドを有効にするなど、APIやダッシュボードを介して公開されていない特定のDNS設定を調整してほしいという要請を定期的に受けていました。お客様がこれらの設定の調整を希望する場合、アカウントチームに連絡して設定を変更する必要がありました。Foundation DNSでは、最も一般的に要求される設定をAPIとダッシュボード経由で公開し、Cloudflareの権威DNSソリューションをより柔軟に活用できるようにしています。

企業のお客様は、ゾーンについて以下のDNS設定値を構成できるようになりました：

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-buh4{background-color:#f9f9f9;text-align:left;vertical-align:top} .tg .tg-p7vi{background-color:#C9DAF8;font-weight:bold;text-align:left;vertical-align:top} .tg .tg-68av{background-color:#f9f9f9;color:#15C;text-align:left;vertical-align:top} .tg .tg-zb5k{color:#15C;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}

Setting	Zone Type	Description
Foundation DNS advanced nameservers	Primary and secondary zones	Allows you to enable advanced nameservers on your zone.
Secondary DNS override	Secondary zones	Allows you to enable Secondary DNS Override on your zone in order to proxy HTTP/S traffic through Cloudflare.
Multi-provider DNS	Primary and secondary zones	Allows you to have multiple authoritative DNS providers while using Cloudflare as a primary nameserver.

設定

ゾーンタイプ

説明

Foundation DNSの高度なネームサーバー

プライマリゾーン/セカンダリゾーン

お客様のゾーンで高度なネームサーバーを有効にすることができます。

セカンダリDNSのオーバーライド

セカンダリゾーン

お客様のゾーンでセカンダリDNSオーバーライドを有効にしてHTTP/SトラフィックをCloudflare経由でプロキシすることができます。

マルチプロバイダーDNS

{
  "query": "{
    viewer {
      zones(filter: { zoneTag: $zoneTag }) {
        dnsAnalyticsAdaptiveGroups(
          filter: $filter
          limit: 10
          orderBy: [datetime_ASC]
        ) {
          avg {
            processingTimeUs
          }
          quantiles {
            processingTimeUsP90
          }
          dimensions {
            datetimeFifteenMinutes
            sourceIP
          }
        }
      }
    }
  }",
  "variables": {
    "zoneTag": "<zone-tag>",
    "filter": {
      "datetime_geq": "2024-05-01T00:00:00Z",
      "datetime_leq": "2024-06-01T00:00:00Z"
    }
  }
}

プライマリゾーン/セカンダリゾーン

CloudflareをプライマリNSとして使用しながら、複数の権威DNSプロバイダーを持つことができます。

アカウントおよびゾーンごとに固有のDNSSECキーを使用

DNSSEC（Domain Name System Security Extensionsの略）は、DNSクエリに対して受信した応答が本物かつ改ざんされていないことを確認する方法を提供することで、ドメインまたはゾーンのセキュリティを強化します。DNSSECは、DNSキャッシュポイズニング（DNSスプーフィング）を防止し、DNSリゾルバーが正しいIPアドレスでDNSクエリに応答していることを確認します。

2015年にUniversal DNSSECを発表して以来、セカンダリゾーンの事前署名済みDNSSECや複数署名者DNSSECのサポートを追加するなど、いくつかの改善を行ってきました。デフォルトでは、CloudflareはDNSクエリに応答する際に、その場でDNSレコードに署名（ライブ署名）します。これにより、CloudflareはプロキシされたオリジンのIPアドレスを動的に割り当てながら、DNSSECで保護されたドメインをホストすることができます。また、このような場合のDNS応答で提供されるIPアドレスはステアリングに基づいて変化するため、特定の負荷分散のユースケースも可能になります。

Cloudflareは、現在使用されているほとんどのRSA鍵よりも強力な楕円曲線アルゴリズムECDSA P-256を使用しています。署名の生成に使用されるCPUの使用量が少ないため、より効率的に署名をその場での生成が可能です。通常、DNSSECの一部として、ゾーン署名鍵 (ZSK) と鍵署名鍵 (KSK) との2つの鍵が使用されます。最も単純なレベルでは、ZSKはクエリに応答して提供されるDNSレコードの署名に使用され、KSKは真正性を確保するためのZSKを含めてDNSKEYの署名に使用されます。

現在、Cloudflareは、すべてのDNSSEC署名にグローバルに共有ZSKとKSKを使用しています。このような強力な暗号化アルゴリズムの使用によりこの鍵セットの安全性に確信を持っているため、少なくともセキュリティ上の理由からZSKやKSKを定期的にローテーションする必要はないと考えています。しかしながら、ポリシー上、これらの鍵を特定の間隔でローテーションする必要があるお客様もいます。このため、新しいFoundation DNSの高度なネームサーバーには、必要に応じてアカウントごと、またはゾーンごとにZSKとKSKの両方をローテーションする機能が追加されています。これはまずAPI経由で利用でき、続いてCloudflareダッシュボードから利用できるようになります。そのため、DNSSEC鍵のローテーションに関する厳格なポリシー要件を持つお客様も、Cloudflare Foundation DNSを使用してその要件に対応することができます。

GraphQLベースのDNS分析

GraphQLをあまりご存じない方のために説明すると、GraphQLはAPI用のクエリ言語であり、それらのクエリを実行するためのランタイムです。クライアントは必要な情報を過不足なく正確にリクエストすることができます。複数のソースから単一のAPI呼び出しでデータを集約し、サブスクリプションを介したリアルタイム更新を実現します。

Cloudflareにはしばらく前からGraphQL APIがあったことをご存知の方もいるかと思いますが、Foundation DNSの一部として、新しいFoundation DNSの高度なネームサーバーでのみ利用できる新しいDNSデータセットをそのAPIに追加します。

GraphQL APIの新しいDNSデータセットを使用すると、ゾーンが受信したDNSクエリに関する情報を取得することができます。現在のDNS Analytics APIより高速で強力な代替手段となり、制限やタイムアウトに悩まされることなく、迅速かつ効率的にデータを照会することができます。GraphQL APIは、受け入れるクエリに関してはより柔軟で、DNS Analytics APIよりも多くの情報を公開します。

たとえば、以下のクエリーを実行すると、送信元IPアドレス別にグループ化した15分バケットのクエリーの平均と90パーセンタイルの処理時間を取得することができます。このようなクエリーは、指定された時間範囲内に最も頻繁にレコードをクエリーしたIPSを判定するのに役立ちます：

以前は、このようなクエリーはいくつかの理由で不可能でした。これが可能になった1つ目の理由は、sourceIPのような新しいフィールドを追加したことです。これにより、DNSクエリを行ったクライアント（通常はリゾルバー）のIPアドレスでデータをフィルタリングできるようになりました。2つ目は、GraphQL APIクエリは、非常に大きな時間範囲からデータを処理して返すことができることです。これまで、膨大な量のクエリを処理するDNSゾーンに対しては、数日間のトラフィックしかクエリーをできませんでしたが、新しいGraphQL APIでは、最大31日間のデータを提供することができます。私たちはその範囲のさらなる強化と、どれだけ前の過去のデータの保存とクエリーが可能かを計画しています。

GraphQL APIを使用すると、Cloudflareダッシュボードに新しいDNS分析セクションを追加することもできます。お客様は、最も高頻度でクエリされたレコードを追跡したり、そのクエリーに応答しているデータセンターやクエリー数などを確認できるようになります。

GraphQL APIの新しいDNSデータセットと新しいDNS分析ページが連携し、DNSをご利用のお客様のFoundation DNSデプロイメントの監視、分析、トラブルシューティングを容易にします。

新規リリースに対するプロセス

Cloudflareの権威DNS製品は、およそ1週間に1回ソフトウェアのアップデートを受け取ります。Cloudflareは、新しいソフトウェアリリースによって発生する不具合が本番トラフィックに影響を与えるのを防ぐのに役立つ、高度なリリースプロセスを備えています。稀に、新しいリリースが実稼働のトラフィックの量や独自性にさらされると、問題が表面化する可能性があります。

Cloudflareの企業のお客様は新機能よりも安定性を望んでいるため、新規リリースでは、Foundation DNSの高度なネームサーバーがアップグレードされる前に、標準ネームサーバーで2週間の耐久性テスト期間を設けます。問題が発生しなければ、2週間後Foundation DNSの高度なネームサーバーもアップグレードされます。

Foundation DNSの高度なネームサーバーを使用するゾーンは、新しいソフトウェアリリースによって発生する不具合に対する保護が強化され、信頼性が向上します。

よりシンプルなDNS価格設定

これまで、Cloudflareの権威DNSの料金設定は、月間のDNSクエリー数とアカウント内のドメイン数に応じた課金体制でした。当社のDNSを利用される企業のお客様は、通常、CDN、WAF、ボット管理などのリバースプロキシ（レイヤー7）を使用しないDNSゾーンに関心を持っています。Foundation DNSでは、デフォルトで10,000個のDNS専用ドメインを含めることで、大多数のお客様にとってシンプルな価格設定となっています。この変更により、ほとんどのお客様は、消費したDNS クエリーの数に対してのみ料金を支払うことになります。

また、アカウントのすべてのドメインに100万件のDNSレコードも含めていますが、これが上限と言うわけではありません。実際、当社プラットフォーム上の最大の単一ゾーンには390万以上のレコードがあります。一方、最大のDNSアカウントは、複数のゾーンにまたがる3000万近いDNSレコードを持っています。Cloudflare DNSを使用すれば、最大規模の展開でも問題ありません。

まだまだあります

できることはまだまだあります。将来的には、Foundation DNSにさらに専用機能を追加する予定です。その一例が、要望の多かった機能である、レコード単位でスコープ設定されたAPIトークンとユーザー権限です。これにより、さらに細かいレベルで権限を設定することができます。たとえば、ドメインへのWebトラフィックに影響を与えるアドレスレコードを誤って削除または編集しないように、アカウントの特定のメンバーに対してのみTXTおよびMXタイプのレコードの作成および管理のみを許可するように指定することができます。別の例としては、サブドメインに基づいて権限を指定し、特定のユーザーの範囲をさらに制限することができます。

既存の企業のお客様でFoundation DNSの使用を希望される方は、アカウントチームに連絡して、アカウントにFoundation DNSをプロビジョニングしてください。

Cloudflare ブログ