イベントレポート
Internet Week 2017
変化するDNSとサーバー証明書の関係～「ランチのおともにDNS」より
2017年12月8日 12:00
「向き合おう“グローバル”インターネット」をテーマに、11月28日から12月1日まで開催された「Internet Week 2017」。その中から、いくつかのセッションの模様をお伝えする。
- がんばりすぎないルーティングとは？ 日本人はギリギリ運用しすぎ？（12月1日付記事）
- IoT機器のマルウェア感染、国内で1日8000台を観測、一番の狙われどころはtelnet（12月5日付記事）
- Wi-Fiストレージ「ポケドラ」の脆弱性・出荷停止から学んだ、IoTハードウェアメーカーとしての取り組み（12月6日付記事）
- 変化するDNSとサーバー証明書の関係～「ランチのおともにDNS」より（この記事）
- 「KSKロールオーバーはまだ終わっていない」～今年の「DNS DAY」の話題から（12月13日付記事）
- シンガポールとAPNICから見た、アジアと日本のインターネット（12月15日付記事）
- 1995年ごろのAPNICやISOCや「インターネットマガジン」を振り返る（12月15日付記事）
ここでは、11月30日のランチセッションとして行われた、株式会社日本レジストリサービス（JPRS）による「ランチのおともにDNS」をレポートする。
SSL/TLSによる通信の保護に使われるサーバー証明書（以降、単に「証明書」と記述する）は、インターネットを安全に利用する上で必須のアイテムである。しかし、ここ数年、証明書の誤発行や不正発行といった事故が相次いでおり、その信頼性が揺らいでいる。最近では、Googleが今年9月、Google Chromeにおいて旧Symantecの認証局（CA）が発行した証明書を今後、段階的に「信頼しない」ようにすることをGoogle公式ブログで発表した事例が記憶に新しい。
- Chrome's Plan to Distrust Symantec Certificates（Google Security Blog）
登録情報の不正書き換えによるドメイン名ハイジャックや経路ハイジャックなど、さまざまな手法で利用者のアクセスを偽サイトに誘導する攻撃手法が以前から知られている。もし、攻撃者が誤発行・不正発行された証明書を入手でき、それが偽サイトに導入された場合「ウェブブラウザーに正しいURLが表示され、かつ、アドレスバーの鍵も閉まっているのに、アクセス先は偽サイト」という状況を作り出すことが可能になってしまう。つまり、DNSやBGP[*1]に対する攻撃に不正発行された証明書が組み合わされた場合、証明書の存在が状況をさらに悪化させてしまうことになるのである。
今回のランチセッションは「向き合おう、DNSとサーバー証明書～DNSとサーバー証明書の最近の関係を踏まえ、DNS運用者がすべきこと～」と題し、DNSと証明書の関係の変化と、それがDNSの運用にどのように影響するかについてスポットを当てたもの 。DNSを用いた証明書関連技術の例として、CAAリソースレコードと自動証明書管理環境（ACME：Automatic Certificate Management Environment）におけるdns-01認証の2つが取り上げられた。本稿では、これらの技術的な詳細には触れず、ポイントとなる事項のみを取り上げる。
DNSと証明書間の「横の関係」
証明書の発行手続きでは、申請者と認証局（CA）との間でさまざまな情報をやりとりする必要がある。森下氏からは、最近この部分のやりとり、特に、申請者からCAへの情報の伝達にDNSを使うケースが出てきており、DNSのモデルと証明書のモデルのそれぞれに閉じた従来からの「縦の関係」に加え、モデル間を横断する、いわば「横の関係」が追加されつつあることが示された（図1）。
森下氏は横の関係の実例としてCAAレコードとACMEにおけるdns-01認証を挙げ、続いて島田氏がそれらの技術的な概要について解説した。
CAAは、証明書の申請者とサービスの利用者を保護する仕組み
CAAリソースレコード（以降、単に「CAA RR」と記述する）は、「Certification Authority Authorization（認証局の許可）」を意味しており、DNSのリソースレコードとして2013年に標準化された（RFC 6844）ものである。
面白いのは、このCAA RRの役割である。図2に示されるように、証明書の発行申請「前」に、申請者が自身のドメイン名の権威DNSサーバーにCAA RRを設定する。発行申請を受け取ったCAは、申請者が設定したCAA RRをDNS問い合わせでチェックし、その内容から「当該証明書を発行する許可が出ているか」を確認する。すなわち、証明書の申請者自身が、「我々が使う証明書を発行して良いのは、このCAである」ということをCAA RRを使って、事前に制限できるようにするわけだ。なお、申請者がCAA RRを設定していない場合は従来と同様であり、証明書の発行は制限されない。
設定する内容は、図3と図4に示されるように、自身のドメイン名に対する証明書を発行して良いCAの指定と、許可していないCAに発行要求があった際の連絡に関する指定である。図5は、CAA RRを使った手続きの流れを示している。
この仕組みは、証明書の申請者とサービスの利用者を保護するものであると言えるだろう。申請者がCAA RRを適切に設定し、CAがその設定内容をチェックすることで、申請者が意図しない証明書の発行を抑止できるようになるからである。
また、CAAと同様に証明書の誤発行に対応する技術であるCT（Certificate Transparency）との違いについては、CAAは誤発行を発行前に予防・検知する仕組みであるのに対して、CTは誤発行を発行後に早期検知する仕組みであり、それぞれを補完する技術であるとした（図6）。
ただし、CAA RRの現在の仕様には問題点が指摘されており、すでにIETFで改定作業が始まっている（図7）。業界団体（CA/Browser Forum）が証明書発行時のCAにおけるCAA RRの検証を必須としたため普及は進むであろうが、気になる部分である。
証明書の管理を自動化するACME
ACMEは図9に示されるように、証明書の管理、すなわち検証・発行・失効といった一連のプロセスの自動化を目的とするプロトコルである。本セッションの発表時点ではWGにおける標準化作業を完了し、IESG[*2]に送られた状態になっている。ACMEではDNSを利用したバリデーション（検証）の方式として「dns-01」を定義している。
dns-01は証明書発行における認証手続きをDNSで行う仕組みで、図10に示されるように、CAから指定された内容を証明書の申請者が自身のドメイン名の権威DNSサーバーに設定し、CAがその内容を確認するというかたちを取る。イメージとしては、CAとの間で合い言葉を使い、申請者がそのドメイン名の管理権限を有していることを証明すると考えていただけると良い。ACMEでは、運営者の実在性審査が無いDV（Domain Validation）証明書の発行を半自動化したい場合に使うことが想定されている。dns-01を使った際の流れが、図11に示されている。
DNS運用者がすべきことは何か
森下氏により行われたまとめパートの説明は、DNS関係者に向け、今後どのような点に気を付けなければいけないかについて述べたものであった。
最初に、ドメイン名と証明書のライフサイクルを一致させることが挙げられた。これが一致せず、ドメイン名が廃止・移転されたのに古い証明書が残っていた場合、例えば当該ドメイン名が第三者にドロップキャッチされ、発行済みの証明書が悪用されるといった事例のリスクを考える必要があるということだ。
続くリソースレコードタイプの増加は、DNS運用者にとって悩ましい問題であろう。2009年に発行された、IAB[*3]が著者となったRFC 5507「Design Choices When Expanding the DNS」によって、プロトコルを拡張してDNSに新たな情報を載せたい場合、リソースレコードタイプの追加が好ましい解決策とされた。これにより、2010年以降、現在までに18種類のリソースレコードタイプが追加されている。今後も新たなリソースレコードの追加が見込まれるということだが、DNS関係者はこのような情報を収集し、どのように対応するか判断し対応していくことが求められるであろう。
標準化・意思決定による影響は、意思決定しているのが誰（どの組織）で、どう決定しているかという点に留意したほうが良いという話である。たとえば、今回のCAによるCAA RRのチェックの必須化は、業界団体のCA/Browser Forumによる意思決定の結果である。そのため、強力に推進されることが容易に想像できる。このように、証明書の運用ポリシーについてはCA/Browser Forumにおける意思決定の影響が大きいため、IETFにおける標準化の状況と同様、あるいはそれ以上に注意を払う必要がある 。
新たな注意点では、新しい仕様には、新しい注意点（はまりどころ）が存在するということが述べられている。この記事では説明を省略しているが、CAA RRの検索アルゴリズムが特殊であることや、dns-01認証におけるprefixed nameの取り扱いがDNS運用に与える影響などについては、その問題点を知らないと落とし穴にはまる可能性があるため注意が必要である。
最後のDNSSECとの関係では、証明書の発行手続きの中でDNSが直接使われるようになったことで、DNSの信頼性が証明書の信頼性に直接影響することになったこと、それに対応するため、CAA RRとACMEのdns-01認証では双方ともプロトコルレベルでDNSSECの利用を強く推奨していることが述べられている。森下氏からは、DNSSECで信頼性の向上を図るためにはCA側のリゾルバに加え、申請者側の権威DNSサーバー側の対応も必要であることが示された 。
変化に対応できるようにするために必要なこと
DNSは、従来の名前解決だけでなく、新しいかたちで使われるようになってきている。今回のランチセミナーで取り上げられた、CAA RRやACMEのdns-01認証もその1つである 。
重要なのは、いかに早く、有用な情報を得るかにある。IETFなどの動向や関係する団体にアンテナを張り、情報を得て理解し選択する能力が、組織のDNS管理者やネットワーク管理者、ひいてはマネージャーや経営者にも求められる時代になってきたのかもしれない。日本語で情報を得たいのであれば、JPRSや日本ネットワークインフォメーションセンター（JPNIC）、ISOC-JP、DNSOPS.jpなどがさまざまな技術情報を公開しているので、それらの公式サイトを入念にチェックすることをお勧めする。
今回のランチセミナーで使用したスライドは、すでにJPRSのサイトで公開されている。興味のある方は、その資料にアクセスしてほしい。
[*1]……Border Gateway Protocol。インターネットにおいて、経路情報をやりとりするための経路制御プロトコル。
[*2]……Internet Engineering Steering Group。IETFのWGが所属する各エリアのエリアディレクターにより構成され、IETFの活動と標準化プロセスの技術的な側面について責任を担っているグループ。
[*3]……Internet Architecture Board。IETFの活動方針とインターネット標準化プロセスを監督し、インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団。