RRをDNS問い合わせでチェックし、その内容から「当該証明書を発行する許可が出ているか」を確認する。RRを使って、事前に制限できるようにするわけだ。RRを設定していない場合は従来と同様であり、証明書の発行は制限されない。設定する内容は、図3と図4に示されるように、自身のドメイン名に対する証明書を発行して良いCAの指定と、許可していないCAに発行要求があった際の連絡に関する指定である。RRを使った手続きの流れを示している。RRを使った手続きの流れこの仕組みは、証明書の申請者とサービスの利用者を保護するものであると言えるだろう。RRを適切に設定し、CAがその設定内容をチェックすることで、申請者が意図しない証明書の発行を抑止できるようになるからである。Transparency)との違いについては、CAAは誤発行を発行前に予防・検知する仕組みであるのに対して、CTは誤発行を発行後に早期検知する仕組みであり、それぞれを補完する技術であるとした(図6)。RRの現在の仕様には問題点が指摘されており、すでにIETFで改定作業が始まっている(図7)。RRの検証を必須としたため普及は進むであろうが、気になる部分である。RRのまとめ証明書の管理を自動化するACMEACMEは図9に示されるように、証明書の管理、すなわち検証・発行・失効といった一連のプロセスの自動化を目的とするプロトコルである。本セッションの発表時点ではWGにおける標準化作業を完了し、IESG[*2]に送られた状態になっている。ACMEではDNSを利用したバリデーション(検証)の方式として「dns-01」を定義している。)の説明dns-01は証明書発行における認証手続きをDNSで行う仕組みで、図10に示されるように、CAから指定された内容を証明書の申請者が自身のドメイン名の権威DNSサーバーに設定し、CAがその内容を確認するというかたちを取る。イメージとしては、CAとの間で合い言葉を使い、申請者がそのドメイン名の管理権限を有していることを証明すると考えていただけると良い。Validation)証明書の発行を半自動化したい場合に使うことが想定されている。dns-01を使った際の流れが、図11に示されている。ACMEのまとめDNS運用者がすべきことは何か森下氏により行われたまとめパートの説明は、DNS関係者に向け、今後どのような点に気を付けなければいけないかについて述べたものであった。最初に、ドメイン名と証明書のライフサイクルを一致させることが挙げられた。これが一致せず、ドメイン名が廃止・移転されたのに古い証明書が残っていた場合、例えば当該ドメイン名が第三者にドロップキャッチされ、発行済みの証明書が悪用されるといった事例のリスクを考える必要があるということだ。続くリソースレコードタイプの増加は、DNS運用者にとって悩ましい問題であろう。DNS」によって、プロトコルを拡張してDNSに新たな情報を載せたい場合、リソースレコードタイプの追加が好ましい解決策とされた。これにより、2010年以降、現在までに18種類のリソースレコードタイプが追加されている。今後も新たなリソースレコードの追加が見込まれるということだが、DNS関係者はこのような情報を収集し、どのように対応するか判断し対応していくことが求められるであろう。追加されるリソースレコードについて標準化・意思決定による影響は、意思決定しているのが誰(どの組織)で、どう決定しているかという点に留意したほうが良いという話である。Forumによる意思決定の結果である。そのため、強力に推進されることが容易に想像できる。Forumにおける意思決定の影響が大きいため、IETFにおける標準化の状況と同様、あるいはそれ以上に注意を払う必要がある。新たな注意点では、新しい仕様には、新しい注意点(はまりどころ)が存在するということが述べられている。nameの取り扱いがDNS運用に与える影響などについては、その問題点を知らないと落とし穴にはまる可能性があるため注意が必要である。RRとACMEのdns-01認証では双方ともプロトコルレベルでDNSSECの利用を強く推奨していることが述べられている。森下氏からは、DNSSECで信頼性の向上を図るためにはCA側のリゾルバに加え、申請者側の権威DNSサーバー側の対応も必要であることが示された。DNSと証明書の関係のまとめ変化に対応できるようにするために必要なことDNSは、従来の名前解決だけでなく、新しいかたちで使われるようになってきている。RRやACMEのdns-01認証もその1つである。重要なのは、いかに早く、有用な情報を得るかにある。IETFなどの動向や関係する団体にアンテナを張り、情報を得て理解し選択する能力が、組織のDNS管理者やネットワーク管理者、ひいてはマネージャーや経営者にも求められる時代になってきたのかもしれない。日本語で情報を得たいのであれば、JPRSや日本ネットワークインフォメーションセンター(JPNIC)、ISOC-JP、DNSOPS.jpなどがさまざまな技術情報を公開しているので、それらの公式サイトを入念にチェックすることをお勧めする。今回のランチセミナーで使用したスライドは、すでにJPRSのサイトで公開されている。興味のある方は、その資料にアクセスしてほしい。インターネットにおいて、経路情報をやりとりするための経路制御プロトコル。IETFのWGが所属する各エリアのエリアディレクターにより構成され、IETFの活動と標準化プロセスの技術的な側面について責任を担っているグループ。IETFの活動方針とインターネット標準化プロセスを監督し、インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団。