“HTTPSレコード”って知ってる？今知るべき4つの注意点

[注] この記事はすぐに陳腐化するはずの内容について扱っています。何年か経ってからこの記事を参照する場合、2022年3月に書かれた内容であることを留意の上お読みください。

はじめに

IIJ DNSプラットフォームサービスにて、先日大きなアップデートと小さなアップデートがありました。大きなアップデートというのは、これまでのマネージドDNSサービスに加えてもうひとつ、IIJ DNSトラフィックマネージメントサービスという新たなサービスが追加されたこと。サーバの死活監視結果に応じて動的にDNSの応答を変えることができます。小さなアップデートは、従来のマネージドDNSサービスへの機能追加。HTTPSレコードに対応しました。

サービスの宣伝という意味では大きなアップデートの方を紹介した方がいいんでしょうけれど、ヘソ曲がりなのでここでは小さなアップデート、HTTPSレコードの方に焦点をあてます。

そもそもHTTPSレコードって何なの

HTTPSレコードはまだRFCになっていない^(※1)のでご存知ない方も多いと思いますが、その詳しい説明については割愛します。以下の資料をご覧ください。

• DNSでHTTPS
• WebサーバのDNSへの登録方法が変わるよ

簡単に言うと、この資料にもあるように「WebサーバのDNSへの登録方法が変わるよ」ということです。これまでA/AAAAレコードを直接書いていたのが、HTTPSレコードでワンクッション置くようになります。これまでWebサーバをDNSに登録するには、サーバのIPアドレスをAレコード、AAAAレコードとして登録していました。これからは「HTTPSレコード」という新しいレコードタイプを使ってホスト名を登録するようになるでしょう。とりあえず、それだけわかっていれば詳しいことは知らなくてもこの記事を理解するには十分です。

CDNやSaaSサービス等を利用する際に、これまでは事業者から「うちのサービスを使いたいならCNAMEレコードを登録してね」と要求されていましたが、将来的にはCNAMEではなくHTTPSレコードでの登録を求められるケースが増えてくると予想されます。そう要求されたのにDNSに登録する方法がないというのは困るので登録できるようにしました、というのがIIJ DNSプラットフォームサービスの今回のアップデートになります。

DNSのレコードタイプはこれまでもちょくちょく追加されてきましたが、HTTPSレコードの普及はそれらに比べて非常に速いです。使われはじめてからまだ2年もたっていませんが、すでにDNS全体のクエリの中でA、AAAAに次いで3番目、全体の1割を越える量を占めるまでになっています。しかし、普及は急速ではあるものの、十分に普及しきったといえる段階にはまだ遠く及びません。普及の過渡期の状態にあります。

HTTPSレコードはたくさんの機能を持つレコードタイプなので、その利用にも注意を要する点がいくつかあります。たとえばJPRS森下さん(いつもお世話になっております)による以下の動画が参考になります。

• HTTPSレコードを設定・運用する上ではまりそうなところを調べてみた

この動画はHTTPSレコードが完全に普及した将来においても通用する注意点がまとまっていますが、その一方で、普及するまでの過渡期に特有な注意点への言及が少なめです。

ということでこの記事では、その過渡期である現時点で注意しておくべき点をいくつか挙げてみます。

ブラウザの対応

HTTPSレコードは、WebブラウザがWebサイトにアクセスする際に問い合わせるDNSレコードタイプです。なので、まずブラウザがこれに対応していないことにはどうにもなりません。HTTPSレコードに完全に依存してしまうと、A/AAAAレコードにしか対応していないブラウザがアクセスできなくなってしまいます。そうならないように、対応済み、未対応どちらのブラウザでもアクセスできるようにしておかなければなりません。

現時点では、Safari (iOS、macOS) は対応済みでとくに何もしなくても使えます。Firefoxも実装済みで、設定変更により有効にできます。ただしその設定というのが「DNS over HTTPS を有効にする」という極めて非直感的でわかりにくいものになっています^(※2)。Chromeも実装自体は完了していますが、それを有効にするための設定UIが存在しないため実質的に使えません^(※3)。

メジャーなブラウザの対応状況に差がありますが、おそらく今後はデフォルト有効になる方向に変化していくんじゃないかと予想しています。じゃあ、どれもデフォルト有効になれば混在しなくなって過渡期を脱するのかというと、そういうわけにはいきません。

まず、すぐ思いつくように、古いバージョンのブラウザを使い続ける人たちの存在があります。時が解決してくれますが、数年単位の時間がかかるでしょう。

Webブラウザ以外のHTTPクライアントの存在も考慮しなければなりません。APIサーバなど、一般のWebブラウザ以外のクライアントからのアクセスが多いサーバでは、そのクライアント(が利用しているHTTPアクセス用のライブラリ)がHTTPSレコードに対応しているかどうかを把握しておく必要があります。SEOを考えるなら、検索エンジンのクローラーのHTTPSレコードへの対応状況が気になるところでしょう。

また、クライアントがHTTPSレコードに対応したからといって、HTTPSレコードのすべての機能に対応しているとは限りません。HTTPSレコードにはA/AAAAレコードにはない様々な機能があります。拡張性も非常に高く、今後も様々な機能が追加されていくことになるでしょう(追加されすぎて収拾がつかなくなる未来が見えます……)。そのため、クライアントによってHTTPSレコードのこの機能には対応しているがあの機能には対応していない、ということが起こりえます。そのうちのどの機能を自分が必要としていて、クライアントがそれに対応しているのかは常に把握しておく必要があります。

キャッシュDNSサーバの対応

汎用のブラウザではなく、特定のクライアントからのアクセスだけに限定していい場合、たとえばオンラインゲームやスマホアプリなどは、そのクライアントさえHTTPSレコードに対応していればいいように感じられます。とくに、iOSはすでにOSとしてHTTPSレコードに対応が完了していますので、iOS専用アプリからのみアクセスされるWebサーバは(古いバージョンのiOSを切り捨てていいのであれば)HTTPSレコードに依存しても問題なさそうです。

ほんとうでしょうか？

残念ながら、そうとは言いきれません。

HTTPSレコードなんてものを知らない古いキャッシュDNSサーバでも、HTTPSレコードの名前解決は問題なくできます。そのため、キャッシュDNSサーバ自体が問題になることはありません。HTTPSレコードに対応するためだけにキャッシュサーバをバージョンアップする必要はありません^(※4)。

しかし、キャッシュDNSサーバの手前にあるファイアウォールが問題になります。未知のDNSレコードタイプは怪しいとしてパケットをドロップするルールが設定されているファイアウォールやIPS/IDSが一部にあるようです。HTTPSレコードは最近できたばかり(そしてまだRFCにはなっていない)レコードタイプなので、これにひっかかってしまう可能性があります。実際、国内のとあるISPさんがHTTPSレコードの問い合わせをドロップしていた例を確認しています。

これは多くの場合、意図して制限しているわけではないと思われますので、ファイアウォール機器やそのルールを更新することで自然と解消されていくでしょう(これを読んでるFWの管理者のみなさま、何年か先になる機材更新まで放置するのではなく、今すぐ明示的にルールを更新してください)。

しかしながら、意図的に制限しているケースもあります。OpenDNSです。

OpenDNSは、HTTPSレコードの問い合わせに応答を返しません。

## OpenDNSに問い合わせると、HTTPSレコードに空応答を返す
% kdig @208.67.222.222 cloudflare.com https
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 180
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; cloudflare.com. IN HTTPS

;; Received 32 B
;; Time 2022-02-25 17:45:54 JST
;; From 208.67.222.222@53(UDP) in 1.0 ms
## OpenDNSでないサーバ(手元のunbound)に問い合わせると、ちゃんと応答が返る
% kdig cloudflare.com https
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 10084
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; cloudflare.com. IN HTTPS

;; ANSWER SECTION:
cloudflare.com. 232 IN HTTPS 1 . alpn=h3,h3-29,h2 ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

;; Received 111 B
;; Time 2022-02-25 17:46:18 JST
;; From 127.0.0.1@53(UDP) in 0.3 ms

実際の挙動は確認していませんが、OpenDNSの商用版サービスであるCisco Umbrellaでも同様の制限がされているようです。

したがって、HTTPSレコードに対応していないクライアントからのアクセスを考慮しなくていい場合でさえ、OpenDNSやUmbrella(やその他HTTPSレコードが制限されているキャッシュDNSサーバ)が方針を転換するか、もしくはこれらを使っているユーザからはアクセスできなくてもいいと切り捨てる判断をしないかぎり、HTTPSレコードだけに頼らず、従来のA/AAAAレコードだけを使った名前解決ができるようにしておく必要があります。

なお、キャッシュDNSサーバやファイアウォールがHTTPSレコードだけを選択的に制限するというのは、見方によれば中間者攻撃とも言えます。詳細は割愛しますがHTTPSレコードにはセキュリティを向上させるための機能も含まれており、したがって中間者攻撃でHTTPSレコードの名前解決を失敗させるのはダウングレード攻撃となりえます。これを防ぐため、HTTPSレコードの仕様には「中間者攻撃が疑われる場合はA/AAAAレコードで名前解決ができたとしてもHTTPS接続自体をやめるべき(SHOULD) 」と書かれています^(※5)。今のところそこまで厳密に実装したクライアントは存在しないようですが、もしそのような実装がされると、HTTPSレコードの名前解決ができないキャッシュDNSサーバを使っているとあらゆるHTTPS接続ができなくなる可能性がありますのでご注意ください。

結局、HTTPSレコードは使うなってこと？

いいえ。

使うな、ではなく、HTTPSレコード「だけ」に頼らないようにしよう、ということです。現状ではHTTPSレコードでの名前解決ができないクライアントやキャッシュDNSサーバがありますが、その場合でも従来のA/AAAAレコードによる名前解決はできるはずです。HTTPSレコードに対応したクライアントは、HTTPSレコードでの名前解決に失敗すれば従来のA/AAAAによる名前解決をおこないますので、HTTPSとA/AAAAを併記しておくのがいいでしょう。

具体的には、すでに以下のような設定がある場合、

www.example.jp. IN A    192.0.2.1
www.example.jp. IN AAAA 2001:db8::1

このwww.example.jp.のA/AAAAレコードをHTTPSに「置き替える」のではなく、HTTPSレコードを「追加」します。

www.example.jp. IN HTTPS 1 . alpn=h2   ; 追加
www.example.jp. IN A     192.0.2.1     ; A/AAAAはそのまま残す
www.example.jp. IN AAAA  2001:db8::1

このように設定すると、HTTPSレコードに対応していないクライアントは従来と同じくA/AAAAレコードを使って名前解決し、HTTPSレコードに対応したクライアントはHTTPSレコードを参照します(alpn=h2なので、このサーバはHTTP/2に対応してるぞ、ということがWebサーバに実際にアクセスする前にわかります)。サービスモード(優先度が0以外)では “.” は「自分自身」を意味するので、www.example.jpのIPアドレスはA/AAAAレコードに記載されている192.0.2.1と2001:db8::1であることがわかります。このように、サービスモードのターゲット名として “.” を使うようにしておくと、名前解決結果のIPアドレスがA/AAAAレコードしか扱えないクライアントの名前解決結果と常に一致し、意図しないサーバにアクセスされてしまう事故を防げます。HTTPSレコードが完全に普及するまでの間はターゲット名に他のホスト名を指定するような使い方はしないのが無難でしょう。

また、エイリアスモード(優先度が0)は基本的には使わず、従来のCNAMEを使い続けるのがいいでしょう。CNAMEは他のリソースレコードとの同居が禁止されているので、上の例でA/AAAAとHTTPSを併記したようにCNAMEとHTTPSを併記するような使い方はできません。

www.example.jp. IN CNAME www.example.com.

ただし、ゾーン頂点ではSOAとNSレコードがすでに存在しているのでCNAMEを書けません。そういう場合にかぎってエイリアスモードを使います。ただし、HTTPSレコード未対応クライアントを考慮すると、CNAMEもHTTPSも使わずに名前解決できるようにすることも必要です。つまり結局のところ、A/AAAAレコードを直接書かなければならないことには変わりなく、エイリアスを指定する意味が大きく薄れるのは否めません。これは現時点ではどうにもなりません。HTTPSレコードで名前解決できないクライアントが存在しなくなる未来がやってくるのを待つしかありません。

example.jp. IN SOA   ...
example.jp. IN NS    ...
example.jp. IN HTTPS 0 wwww.example.com.
example.jp. IN A     192.0.2.1
example.jp. IN AAAA  2001:db8::1

しかし、一部の権威DNS事業者が独自拡張機能として提供しているような、ホスト名をA/AAAAレコードに自動的に展開してくれる機能を使えば現時点でも問題なく別名を使えます。IIJ DNSプラットフォームサービスの場合、以下のようにANAMEレコードを設定すればいいです。

example.jp. IN HTTPS 0 wwww.example.com.
example.jp. IN ANAME www.example.com.

読んだけどよくわかんない、という場合は、無理してHTTPSレコードは使わずにこれまでどおりA/AAAAレコードだけを登録しておいても問題ありません。もちろんその場合はHTTPSレコードによって得られるメリットもありませんが。

HTTPSレコードによるポート番号の変更

ここまでHTTPSレコード普及までの過渡期における注意点を述べてきましたが、十分に普及した後でも注意しておくべき点をひとつ挙げておきます。

(DNSのレコードタイプじゃない方の)HTTPSはポート番号として443を使うのが標準で、それ以外を使う場合は https://example.com:8443/ のようにURLでポート番号を明示する必要がありました。しかし、HTTPSレコードを使うと、URLに “:8443” のようなポート番号を含めなくても非標準のポートを使えます。こんなふうにサービスモードでポート番号を指定すればおっけーです。

example.com. IN HTTPS 1 . port=8443

が、あくまでこれは仕様上の話であり、それが実用になるかというと別の問題です。そして、これは実用になりません。

組織内部から外部に対してHTTPSアクセスをする際にファイアウォールやプロクシを経由しなければならない環境は珍しくなく、そういう環境では非標準ポートを使ったHTTPSアクセスが禁止されているケースがほとんどです。とくにHTTPプロクシについては、任意のポート番号にHTTPS接続できるのは脆弱性とされていて、組織のポリシーで許可するかどうかという話ではなく、完全に「やっちゃダメ」という扱いになっています。

したがって、HTTPSレコードを使ってポート番号を443から変更すると、そういうネットワーク環境からアクセスする人が接続できなくなります。:8443のようなポート番号を指定するURLがほとんど使われていないのは、そういうURLがカッコ悪いからではありません。アクセスできないからです。特定の組織の人しかアクセスしないWebサーバで、その組織の中からはそのポート番号が制限されていないことがあらかじめわかっている、といった極めて限定された状況以外では使いものになりません。

まとめ

HTTPSレコードはまだ新しく、十分に普及していません。完全に普及しきった後であれば気にしなくてよくなるだろうことでも、現時点では考慮しなければならないところがいくつかあります。

なので、DNSのゾーンをいじっている立場の人であれば、今は無理せずできる範囲での対応でかまわないかと思います。今はこれまでどおりA/AAAAレコードだけを使って、本格的にHTTPSレコードを使いはじめるのは十分に普及してからでも遅くはないでしょう。もし今のうちから対応をはじめるのであれば、HTTPSレコードに対応したクライアントと、A/AAAAレコードしか扱えないクライアントの両方からアクセスできるようにゾーンの記述を工夫する必要があります。

一方、HTTPSレコードを制限しているファイアウォールなど、普及をさまたげる要因になっているところについては早急な対応をお願いします。もしUmbrellaをご利用のユーザ様がいらっしゃれば、使えるようにしてくれとCiscoに要望を出していただければと思います。