COLUMN

2024.11.13 ｜ Writer：NTT東日本　白鳥翔太

Amazon Route 53の新しいHTTPS/SVCB/SSHFP/TLSAリソースレコードタイプについての技術概説とユースケースの考察

	こんにちは、白鳥です。

先日Amazon Route 53に新しいリソースレコードの対応追加が発表されました

Amazon Route 53 announces HTTPS, SSHFP, SVCB, and TLSA DNS resource record support - AWS

DNSを専門にされている方であればCDNサービスなどですでに実装されておりようやくAmazon Route 53で対応というイメージを持つ方もいらっしゃるかもしれませんが、ここ数年でRFC化されるなど技術的に新しい部分もありますので、技術的な解説をしながらユースケースを考察してみたいと思います。

NTT東日本では、AWSやクラウドに関する情報をメールマガジンにて発信しています。ご購読を希望される方は、ぜひこちらからご登録ください。

1. レコードタイプ追加の背景: 1-1. HTTPSレコード/SVCBレコード; 1-2. TLSAレコード; 1-3. SSHFPレコード
2. まとめ
3. 最後に

1. レコードタイプ追加の背景

DNSといえばAレコードやAAAAレコードを設定することが多く、DNSといえば「ドメイン名からIPアドレスを紐づける仕組み」と解説されるものも多くありますが、正しくは「ドメイン名を管理・運用するためのシステム」となります。したがって、ドメイン名を使って認証や情報取得を行うこともできます。ゲスト寄稿したブログ記事になりますが、過去にはこんな記事を寄稿しておりました。

Amazon Route 53でサポートされるレコードタイプについてざっくり理解する | DevelopersIO

多くの場合、エンドツーエンドで通信を行う際にレイヤ7ではDNS問い合わせが最初になります。

DNSの応答の際に後続の通信で必要になるプロトコルに関連する情報がわかれば、後続の通信を効率的かつセキュアに行うことができるようになります。

通信の高速化は帯域やシステムの性能を上げるだけではなく、こうしたプロトコルを効率化することも必要になってきます。こうした背景で出てきたのがHTTPS/SVCBレコードとなります。

また、DNSのフェーズで認証を行い、なりすましを防ぐことができれば、早い段階で安全性を得ることができます。SSHFPレコードはSSHのセキュリティ向上、TLSAは主にSMTPのセキュリティ向上に寄与することができるようになります。

1-1. HTTPSレコード/SVCBレコード

1-1-1. 技術解説

HTTPSレコードとSVCBレコードは2020年ごろから利用が始まり、2023年にRFC9460で定義されたレコードタイプとなります。どちらもエンドツーエンドで通信を行う際の後続のプロトコルに関する情報提供を行うものとなりますが、HTTPSレコードはHTTP/HTTPS通信に特化したものとなり、SVCBレコードは任意のプロトコルで利用できるものとなります。名前解決をHTTPSで行うものと混同されることもありますが、これは別の仕組み（DNS over HTTPS）で行われます。

HTTPSレコードとSVCBレコードは二つのモードを持っており、AliasModeとServiceModeの二つがございます。

AliasMode

AliasModeは別のDNS名への代替を行います。CNAMEレコードと同じと思われるかもしれませんが、CNAMEレコードとの違いはZone Apex（例：example.jp）の応答が可能になる点です。Amazon Route 53でもエイリアスレコードというレコードでZone Apexの名前解決を行っておりましたが、エイリアスレコードではAWSのリソース（例：ALBのエンドポイント）への名前解決のみでした。HTTPSレコードでは、任意のドメイン名への代替えが行えるようになります。Amazon Route 53の場合、このようにHTTPSレコードを記述します。

AliasModeを使う場合は、Priorityを0にして、リダイレクトさせたいドメイン名を指定します。

ServiceMode

ServiceModeは対象になるドメインで利用する情報を事前に提供します。接続先のWebサーバーがHTTP/3対応しているか、TLSの公開鍵を取得する、ポート番号の指定を行うなどができるようになります。ServiceModeを使う場合はPriorityを1以上にして必要な情報を記述していきます。Priorityの小さい順に処理されていきます。

Amazon Route 53では、このように記述します。今回は検証のため、cloud-ntteast-2.comドメインを使用しています。

参考：RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

1-1-2. HTTPSレコード/SVCBレコードを使用するメリット

大きく分けて高速化とセキュリティの2点があります。事前にバージョン情報や公開鍵を知った状態でサーバーへの通信が開始できるので、事前のネゴシエーションの回数が減らせること、またClientHelloで暗号化バージョンや公開鍵情報を平文でやり取りする必要がなくなるため、その分セキュアな通信が可能となります。HTTPSレコード/SVCBレコードを使用しない場合と、使用した場合のシーケンスの違いを次の図で示します。

このように、HTTPのレスポンスを得るまでにクライアントとサーバーの応答回数を減らすことができます。

1-2. TLSAレコード

1-2-1. 技術解説

TLSAレコードはDNSSECを活用した公開鍵フィンガープリントの検証用途になります。TLSの公開鍵の検証プロセスとDNSSECを組み合わせることで、信頼できるDNS応答と信頼できる機関によって発行された検証済みのTLS証明書を提供するためのものとなります。こうした仕組みはDANE(DNS based Authentication of Named Entities)と呼ばれ、RFC 6698で規定されております。TLSAレコードを使用すると、DNSでTLS証明書の公開鍵フィンガープリントを指定できます。これにより、TLSクライアントはサーバーによって提示される証明書がDNS所有者のものであることをDNSで検証します。一致しない場合は、証明書のなりすましや設定エラーの可能性があることを示しています。Amazon Route 53では、下記の形式で記述します。

レコード名： _[port]._[protocol].hostname
値： [certificate-usage-field] [selector-field] [matching-type-field] [certificate-data]

値の解説

[certificate-usage-field] TLSハンドシェイク時の証明書の提供元

0 CA
1 サービス
2 トラストアンカー
3 ドメイン

[selector-field] TLSハンドシェイク時にTLS証明書のどの部分を照合するか

0 すべて
1 Subject Public KeyまたはDER

[matching-type-field]　証明書の検証方法（完全一致またはハッシュ値）

0 完全一致
1 SHA-256
2 SHA-512

[certificate-data]　関連付けるデータ(フィンガープリントなど)

参考：The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA

1-2-2. TLSAレコードのユースケース

TLSAレコードの主なユースケースは前述にもある通りSMTP over TLSとなります。メールサーバーのなりすましへの対策にTLSAレコードを使用します。TLSAレコードとサーバーの公開鍵が一致することを確認することで、正しいメールサーバーを認識できるようになります。

1-3. SSHFPレコード

1-3-1. 技術解説

SSHFPレコードはRFC 4255で規定され、SSH鍵の管理に使われます。DNSサーバーではSSHフィンガープリントとDNSSECの署名付きレコードのセットを使用して、クライアントがSSHフィンガープリントを要求し、サーバー側が提示するフィンガープリントを照合します。フィンガープリントと暗号化アルゴリズムとハッシュタイプを指定して記述します。最初のパラメータが暗号化アルゴリズムで、Amazon Route 53では下記となります。