以下の内容はhttps://asnokaze.hatenablog.com/entry/2025/09/24/000350より取得しました。


DNSレコードを自動設定するDomain Connectの標準化動向

DNSレコードの自動設定をするDomain Connectという仕組みの標準化がIETFで行われています。

未だにDNSレコードを手動設定する機会があります。例えば

  • メール系SaaSSPF・DMARCレコードを設定する際、マニュアルに沿ってドメイン設定を手動設定したり
  • Webサイトのホスティングサーバなどでカスタムドメインを利用する際に、CNAMEレコードを設定したり

SaaSDNS管理が別サービスであることも多いため、自動設定が出来ないケースもあります。

そこで、Domain Connectはサービスプロバイダー(SaaS)と、DNSプロバイダーが連携し、必要なDNSレコードを自動設定できるようになっています。

すでに幾つかのサービスでは利用できるようになっています

今回は、そのプロトコル部分について簡単に紹介する。

Domain Connect Protocol

Domain Connect Protocol - DNS provisioning between Services and DNS Providers』に基づいて紹介する

登場人物
  • サービスプロバイダー: ドメイン名を使用して設定またはアクセスされる製品やサービスを提供する組織およびそのシステム
  • DNSプロバイダー: DNSゾーンホスティングサービスを提供する組織およびそのシステム
  • ユーザ: DNS プロバイダーでドメイン名の DNS 構成を制御する手段を持ち、サービスプロバイダーが提供するサービスと連携するように構成したいエンドユーザー
フローについて

Domain Connectには2つのフローがあります

  • 同期フロー: ユーザ(ブラウザ)を介して、同期的にサービスプロバイダーとDNSプロバイダーの連携を行う
  • 非同期フロー: OAuthを利用し、ユーザを介さずに非同期的に連携を行えるようにする

主には同期フローが一般的に利用されているようなので、以下は同期フローについて紹介する

同期フロー

結構長いが、ユーザ(ブラウザ)を介してサービスプロバイダーに要求を行い、DNSプロバイダーのディスカバリ(エンドポイント情報の取得)、必要なパラメータの送信を行っている。順に見ていく (手順10,11は省略する)



  • 1. ユーザーが、サービスプロバイダーにドメイン名を入力する
  • 2. サービスプロバイダーは入力されたドメインにおいて 『 _domainconnect.(入力されたドメイン) 』のTXTレコードを引く
  • 3. DNSプロパイダーは、(2)の問い合わせに対して、Domain Connect用APIサーバのURLを返す
  • 4. サービスプロバイダーは URL を使用して、DNSプロバイダーにDomain Connect 設定を開始する
  • 5. DNSプロバイダーは、API エンドポイントに関する情報を含む設定を返す
  • 6. サービスプロバイダーは、DNSプロバイダーがサービスに必要な特定のテンプレートをサポートしているかどうかを確認する
  • 7. DNSプロバイダーは、要求されたテンプレートをサポートしているかどうかを確認し、応答する
  • 8. サービスプロバイダーは、DNSプロバイダーのDomain Connectサービスにつながるリンクをユーザーに提供する
  • 9. ユーザーがリンクに移動し、ユーザーエージェントは DNSプロバイダーの Web サイトにアクセスする
  • 12~13. DNS プロバイダーはユーザーを認証します
  • 14. DNSプロバイダーは、ユーザーがドメインDNSゾーンを変更する権限を持っていることをチェックする
  • 15. DNSプロバイダーは、DNS ゾーンに変更を適用することへの同意をユーザーに求める
  • 16. ユーザーは、DNSレコードの変更に対する同意を示す
  • 17. DNS プロバイダーはゾーンに変更を適用する
  • 18. DNSプロバイダーは、ユーザーをサービス ロバイダーにリダイレクトするか、Webページの処理としては終わりとする
  • 19~20. サービスプロバイダーは、DNSレコードを照会して変更が適用されたことを確認する
  • 21. サービスプロバイダーは、ドメインがサービスに正常に接続されたことをユーザーに示し完了する
テンプレートについて

プロトコルのやり取りの中に"テンプレート"というものが登場します。
テンプレートはサービスプロパイダの必要な情報が記載されたものです。

この中には、サービスプロパイダが必要としているDNSレコードも記載されており、こと変数 (%verifytxt%) がプロトコル中で注入され、DNSプロパイダがDNSレコードを変更するということになります。

https://github.com/Domain-Connect/Templates/blob/master/google.com.domain-verification.json

{
  "providerId":"google.com",
  "providerName":"Google",
  "serviceId":"domain-verification",
  "serviceName":"Domain Verification",
  "sharedServiceName": true,
  "version": 3,
  "logoUrl":"",
  "description":"Enables a domain to work with Google",
  "variableDescription":"Unique verification code provided for purpose of verification",
  "multiInstance": true,
  "syncBlock": false,
  "syncPubKeyDomain": "google.com",
  "records":[
    {
      "groupId": "verification",
      "type": "TXT",
      "host": "@",
      "data": "%verifytxt%",
      "ttl": 3600
    }
  ]
}

標準化動向

IETFでは先述の通り、Domain Connect Protocolの標準化が進められています。現在は、Working Groupの立ち上げが行われている最中になります。
Draft自体は改版を重ねているところになるので、WGになりしだい標準化に向けて進むものと思われます。

datatracker.ietf.org




以上の内容はhttps://asnokaze.hatenablog.com/entry/2025/09/24/000350より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14