第99回IETF Meeting（プラハ）報告

2017年7月16日から21日にかけて、第99回IETF Meeting（以下、IETF 99）がチェコのプラハで開催されました。

今回のFROM JPRSでは、IETF 99における議論から、FROM JPRS編集局が注目した以下の話題をお伝えします。

• dnsop WGにおける話題
  - IETF 98以降のRFC発行状況
  - 議論された提案の内容と標準化作業の進行状況
  
• 新たなトランスポートプロトコルのDNSへの適用
  - DNS over QUIC
  - DNS over HTTPS
  
• IEPG会合における話題
  - DNSSECの全自動化
  - Root Canary Project
  
• 次回のIETF Meetingについて
  

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、DNSプロトコルの拡張・メンテナンスも活動項目としています。

IETF 98以降のRFC発行状況

前回のIETF 98以降に発行されたRFCは、以下の2本です。

• RFC 8145: DNSSECバリデーターから権威DNSサーバーへのトラストアンカーの伝達
  （Standards Track、draft-ietf-dnsop-edns-key-tag）
  
  DNSSECバリデーターとなっているリゾルバーが、使用中のトラストアンカーの情報（トラストアンカーの鍵タグ、あるいはトラストアンカーで指定されるゾーンからのDNS応答により入手したDSレコードの鍵タグ）を、対象のゾーンを管理する権威DNSサーバー（通常はルートサーバー）に伝達する機能を定義します。
  
  本機能により、DNSSECバリデーターが使用中のトラストアンカーの情報を権威DNSサーバーに定期的に送信する機能が提供されます。権威DNSサーバー側で各バリデーターから送られるトラストアンカー情報を調べることにより、トラストアンカーに対応する鍵署名鍵（KSK）のロールオーバーの進行状況を確認できるようになります。
  


• RFC 8198: DNSSEC検証済のキャッシュデータを活用したDNSの性能向上
  （Standards Track、draft-ietf-dnsop-nsec-aggressiveuse）
  
  DNSSECのプロトコル変更について定めたRFC 4035の内容を一部更新するもので、DNSSECバリデーターとなっているリゾルバーにおいて、DNSSEC検証済のキャッシュされた応答を不在応答やワイルドカードによる応答の生成に利用することで、名前解決のパフォーマンスの向上や遅延・負荷の減少を図るものです。
  
  このRFC 8198は、JPRSの藤原和典が著者の一人となっています。
  https://jprs.co.jp/topics/2017/170726.html

議論された提案の内容と標準化作業の進行状況

FROM JPRS編集局が注目した提案の内容と、標準化作業の進行状況について紹介します。

▽TSIGの脆弱性をきっかけとしたRFC 2845の改訂着手

2017年6月に、Knot DNSとBINDにおいてTSIG（*1）実装の脆弱性が発表されました。

脆弱性対応を進める中で、TSIGのプロトコル仕様を定めたRFC 2845の更新が必要であると判断され、今後RFC 2845の改訂を進める予定であることが共有されました。

▽DNS用語の明確化（draft-ietf-dnsop-dns-terminology-bis）

本提案はDNS用語集であるRFC 7719を改訂するもので、RFC 7719に引き続きJPRSの藤原和典が著者の一人となっています。

今回の改定版では、現在異なる二つの文脈で使われている内部名（in-bailiwick）という用語を、それぞれの意味ごとに「in-domain」と「sibling domain」の二つに分割して再定義することをはじめとする、いくつかの用語の追加・改訂が盛り込まれました。詳細はJPRS用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0190

今回のWGでは前回同様に、追加・改訂された用語の紹介と、参加者へ内容のレビュー依頼が行われました。

▽ANAMEリソースレコードの定義（draft-ietf-dnsop-aname）

ANAME（Address-specific DNS Name Redirection）という、CNAMEレコードと同様の機能を提供する、他のリソースレコードと共に指定可能な新しいリソースレコードを定義するための提案です。

CDNサービスを利用する際、サービス対象のホスト名に対し、CDN事業者のホスト名をCNAMEレコードで指定する方式が普及しています。しかし、サービス対象のホスト名がゾーン頂点の名前であった場合、その名前にはSOAレコードとNSレコードが必ず存在しており、CNAMEレコードを指定することができません。

そのため、一部のCDNサービスではゾーン頂点のA/AAAAの問い合わせに対し、CNAMEを返す権威DNSサーバーを実装・運用しています。しかし、この動作はDNSでは推奨されていません。

本提案は、ANAMEが指定された名前に対しA/AAAAレコードが問い合わされた場合、権威DNSサーバー側で名前解決と変換を実施し対応するA/AAAAレコードを応答することで、この問題を解決することを目的としています。

WGでは、仕様が複雑すぎることや、DNSSECに対応する場合、権威DNSサーバーにおいてオンライン署名が必須となる点などについて活発な議論が交され、継続して作業を進めることとなりました。

▽期限切れキャッシュによる名前解決の継続（draft-tale-dnsop-serve-stale）

名前解決においてリゾルバーがすべての権威DNSサーバーに到達できなかった場合に、期限切れとなったキャッシュを使って名前解決を継続可能にするための提案です。

本提案は、DDoS攻撃や事故などで当該ゾーンの権威DNSサーバーに到達できない状態が続いた際に、名前解決エラーの発生を回避することを目的としています。Akamai Technologies（以下Akamai）とGoogleの社員が著者となっており、一部のパブリックDNSサービスにおいて既に実装されています。

発表では、発表者が所属するAkamaiはBIND 9にパッチを当てて本提案を6年間運用している実績があること、そのパッチを開発元のISCに提供したこと、本提案の手法はAkamaiとGoogleが特許を保有しているが、無償で利用可能とすることを計画していることなどが報告されました。

WGでは、OpenDNSも特許が存在する旨のクレームを出しているのではないかという指摘や、標準化の前に本提案における要求事項の定義から始めるべきであるといった意見が出され、継続して作業を進めることとなりました。

▽EDNS0を用いたエラーコードの拡張（draft-wkumari-dnsop-extended-error）

EDNS0（*2）を用いてDNSのエラーコードを拡張するための、プロトコル拡張の提案です。

RFC 1035で定義されるDNSの応答コード（RCODE）は4ビットであり、0から15までの値しか返すことができません。そのため、DNSSEC検証エラーやサーバーの高負荷時においても通常の名前解決エラーと同じエラーコード（ServFail）しか返せず、クライアント側から状況を把握できないことが課題となっていました。

本提案は、EDNS0に用意されている8ビットの拡張応答コードを用いてServFailエラーを拡張し、DNSSEC検証エラーを含むより詳細なエラーコードを返せるようにするもので、DNSSEC Bogus、DNSSEC Indeterminate、Lame、Prohibited、Too Budyといったエラーコードが新たに定義されています。

WGでは、本提案をサポートする意見が多く、継続して作業を進めることとなりました。

DNS over QUIC（draft-huitema-quic-dnsoquic）

今回のdprive WG（*3）において、DNSのトランスポートプロトコルとしてQUIC（*4）を使用するための提案（DNS over QUIC）が発表されました。

本提案はquic WGにおいて発表されたものですが、今回、dprive WGにも持ち込まれました。

その背景として、QUICが通信路の暗号化機能を備えておりDNS over TLSと同様の機密性を提供すること、最初にスタブリゾルバーとフルリゾルバー（キャッシュDNSサーバー）の間の通信への適用、続いてフルリゾルバーと権威DNSサーバー間の通信への適用という、DNS over TLSと同様の形での普及が見込めることが挙げられました。

WGでは、関心を持つ人が多かったものの、dprive WGで本件を取り扱うためにはチャーターの改訂が必要になるため、標準化活動の開始には時間を要することが見込まれます。

DNS over HTTPS（draft-hoffman-dispatch-dns-over-https）

また、今回のdispatch WG（*5）において、DNSの通信をHTTPSの通信路で実現するための提案（DNS over HTTPS）が発表されました。

提案では、HTTPS通信のメッセージ本体にDNSのワイヤーフォーマット（ビット列形式のバイナリフォーマット）をそのまま用いる、もしくはDNS問い合わせ・応答をJSON（*6）で表現することで、DNSの通信をHTTPS上で実現可能にしています。

本提案により、現在HTTPSで使われているさまざまな技術を、DNSの通信にそのまま適用できるようになります。

WGでは、Webブラウザーベンダーの担当者が好意的な意見を述べていた一方、DNSプライバシーの議論に発展し、今後の進め方については改めてdprive WGと調整することになりました。

なお、dprive WGとdispatch WGの後で開催されたdnsop WGの2回目のセッションでDNS over QUICとDNS over HTTPSの提案が紹介された際、WGチェアが「DNS Over New Transport（DONT）」という、類似の提案が相次いで出されている状況を若干の皮肉を込めた略称で紹介し、参加者の笑いを取っていました。

IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って開催される会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。

DNSSECの全自動化

チェコのccTLDレジストリであるCZ.NICのOndrej Sury氏が、DNSSECの全自動化の試みと、.czにおける実装状況について発表しました。

同氏からは、レジストリシステムにCZ.NICが開発・公開しているFREDを用い、DNSSEC署名にKnot DNSを用いることで、.czにおいてCDS/CDNSKEYレコード（*7）を用いたKSKロールオーバーの自動化を実装したことが発表されました。

この実装では、.czに登録済みのすべてのドメイン名のCDNSKEYをTCPによる問い合わせで入手した後にDNSSEC検証を実施し、それらが置き換わった場合にRFC 7344とRFC 8078（*8）の仕組みによって.czのDSを自動的に書き換え、当該ドメイン名の技術連絡担当者とレジストラに連絡する仕組みとなっています。

また、今後実装する予定の機能として、登録者・レジストラ以外のDNSオペレーターによるDSレコードの自動更新（*9）のためのAPIと、アルゴリズムロールオーバーの全自動化が示されました。

Root Canary Project

NLnet LabsのWillem Toorop氏が、2017年7月から2018年3月にかけてルートサーバーで実施されるルートゾーンKSKロールオーバー（*10）の影響について、計測と監視により、状況を早期に把握するために始められた「Root Canary Project」の概要について紹介しました。本プロジェクトは、オランダの5組織（SURFnet、the University of Twente、Northeastern University、NLnet Labs、SIDN Labs）及びthe RIPE NCCとICANNの7者による合同プロジェクトとなっています。

プロジェクト名のCanary（カナリア）は「炭鉱のカナリア（Canary in the coalmine）」に由来しており、炭鉱で発生する酸欠や有害ガスを、人間よりも敏感なカナリアを使って早期発見していることと同様、ルートゾーンKSKロールオーバーによる影響を早期に検知・把握することを目指しています。

同氏からは今後、ルートゾーンKSKロールオーバーによる異常や影響について、本プロジェクトの公式サイトで情報提供を進めていくことが発表されました。

なお、同プロジェクトの公式ページでは、使用中のフルリゾルバーがどのようなDSアルゴリズムとDNSSEC署名アルゴリズムの検証をサポートしているかを確認可能なテストページを公開しており、トップページから「Algorithm Test」→「Start Test」で実行できます。
https://rootcanary.org/

次回の第100回IETF Meeting（IETF 100）は2017年11月11日から17日にかけて、シンガポールで開催されます。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。