第103回IETF Meeting（バンコク）報告

2018年11月3日から9日にかけて、第103回IETF Meeting（以下、IETF 103）がタイのバンコクで開催されました。

今回のFROM JPRSでは、IETF 103とその周辺で開催された会合の中から、FROM JPRS編集局が注目した以下の話題をお伝えします。

• IETF 102以降のDNS関連RFCの発行状況
  - EDNS0のパディングオプションの実装ポリシー（RFC 8467）
  - Yeti DNSテストベッドと実験の概要（RFC 8483）
  - DNS over HTTPS（DoH）の仕様（RFC 8484）
  - ISPのためのIPv6逆引きDNSの管理運用手法と考慮事項（RFC 8501）
  - DNS用語集（RFC 8499）
  - 問い合わせタイプANYの応答サイズの小型化（RFC 8482）
• dnsop WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
• 「Root KSK futures」ミーティングの開催
• IEPG会合における話題
  - 名前解決における権威DNSサーバーの選択
• 次回のIETF Meetingについて

前回のIETF 102以降に発行されたDNS関連のRFCは、以下の4本です。

EDNS0のパディングオプションの実装ポリシー（RFC 8467）

• RFC 8467: Padding Policies for Extension Mechanisms for DNS(EDNS(0))
  （Experimental、draft-ietf-dprive-padding-policy）
  
  RFC 8467は、EDNS0（*1）のパディング（*2）オプションの実装ポリシーを記述しています。
  
  DNSでは、データサイズや問い合わせのパターンがいくつかに限定されています。そのため、単純な暗号化のみではプライバシー保護の観点から、機密性の確保には不十分であることが指摘されています。
  
  これに対応するため、DNSでやりとりされるデータにランダムなパディングを追加することで機密性を高めるパディングオプションが、RFC 7830で標準化されました。本RFCでは、RFC 7830をアプリケーションに実装する際の具体的なポリシーと方策について記述しています。

Yeti DNSテストベッドと実験の概要（RFC 8483）

• RFC 8483: Yeti DNS Testbed
  （Informational、draft-song-yeti-testbed-experience）
  
  RFC 8483は、2015年5月に開始されたYeti DNS（*3）テストベッドの活動の紹介と、これまでに実施された実験の概要をまとめたものです。
  
  Yeti DNSテストベッドではIPv6専用のルートサーバー、トラストアンカーの自動更新、DNSSECにおけるRSA以外のアルゴリズムの運用など、ルートサーバーの設定変更を要するさまざまな実験環境の構築と試験運用が行われています。
  
  なお、Yeti DNSテストベッドについては利用者の混乱を引き起こすオルタネート・ルート（*4）であるという懸念も表明されており、本RFCではその論争と、テストベッドの運営者自身による見解も紹介されています。

DNS over HTTPS（DoH）の仕様（RFC 8484）

• RFC 8484: DNS Queries over HTTPS (DoH)
  （Standards Track、draft-ietf-doh-dns-over-https）
  
  RFC 8484は、DNSの通信をHTTPS（*5）の通信路上で実現するDNS over HTTPS（DoH）の仕様を定義しています。
  
  DNSの通信路の暗号化は、DNS over TLS（*6）で実現できます。しかし、制限されたネットワーク環境ではDNS over TLSで使うTCPのポート853番がブロックされている可能性があり、DNS over TLSを使えない場合があります。
  
  そうした背景から、DNSの通信路にWebの通信で使われるためブロックされにくいHTTPSを使うアイデアが提案され、DNS over HTTPSとして標準化されました。DNS over HTTPSではHTTPSのGET/POSTメソッドを用いて、DNSパケットをそのままの形で扱います。
  

ISPのためのIPv6逆引きDNSの管理運用手法と考慮事項（RFC 8501）

• RFC 8501: Reverse DNS in IPv6 for Internet Service Providers
  （Informational、draft-ietf-dnsop-isp-ip6rdns）
  
  RFC 8501は、ISP向けのIPv6の逆引きDNSの管理運用の手法と考慮点について分析し、まとめたものです。
  
  IPv4では、ISPが顧客に割り当てたすべてのIPアドレスの逆引きDNSを設定することが一般的です。しかし、IPv6はアドレス空間が膨大であることから、IPv4と同じ手法で逆引きDNSを設定することは困難です。本RFCでは、IPv6の逆引きDNSの管理運用においてISPがとりうる手法と考慮点をまとめ、管理運用に役立てるための情報提供をしています。
  

また、以下の2本がRFC発行に向けた最終段階（AUTH48-DONE、AUTH48）となっており、RFC番号が割り当てられています。最終確認が終了次第、RFCとして発行される予定です。

DNS用語集（RFC 8499）

• RFC 8499: DNS Terminology
  （Best Current Practice、draft-ietf-dnsop-terminology-bis）
  
  RFC 8499は、DNS用語集であるRFC 7719を置き換え、ネガティブキャッシュについて定義したRFC 2308の内容を一部更新するもので、RFC 7719に引き続きJPRSの藤原和典が著者の一人となっています。
  

問い合わせタイプANYの応答サイズの小型化（RFC 8482）

• RFC 8482: Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
  （Standards Track、draft-ietf-dnsop-refuse-any）
  
  RFC 8482は、DNSリフレクター攻撃（*7）の効果を低減するため、ANYリソースレコード（以下、RR）の問い合わせに対する権威DNSサーバーの応答の仕様を変更して、最小サイズの応答を可能にします。
  
  本RFCでは、問い合わせタイプANYの応答として、権威DNSサーバーが知っているすべてのRRを返すという従来の動作に加え、その時点で有効な一部のRRSetのみを返すことができることを明確化します。また、RFC 1034と1035には含まれていなかった、DNSサーバーまたはクライアントの動作に関する指針を提供します。
  

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

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

▽期限切れキャッシュを使った名前解決の継続（draft-ietf-dnsop-serve-stale）

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

本提案は、DDoS攻撃や事故などによって権威DNSサーバーに到達できない状態が続いた際に、名前解決エラーの発生を回避することを目的としています。なお、本提案はBINDやKnot Resolverなど一部のソフトウェア実装や主要なパブリックDNSサービスにおいて、既に利用されています。

今回のWGでは、最大1週間、すべての権威DNSサーバーから応答がなくてもTTL値30でstale RRsetsを返すようにすることや、応答の際、権威DNSサーバーと通信できない状態であることを返せるようにするためのEDNSオプションの追加などが提案されています。

会場からは、提案された30秒のタイマー値の理由や、期限切れのキャッシュを再利用する際の条件と期間などについてコメントがあり、今後も継続して作業を進めることになりました。

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

CDN（Content Delivery Network）での利用を想定した、ゾーン頂点に指定可能なANAME（Address-specific DNS aliases）という、CNAME RRと同様のRRを追加することが提案・議論されています（*8）。

なお、今回の提案からANAMEの名称が、Address-specific DNS Name RedirectionからAddress-specific DNS aliasesに変更されています。

今回のWGでは親ゾーンへ委任情報の代わりにCNAME RRとDNAME RRを設定することで98%以上のケースで正常動作したというIETF Hackathon Bangkokでの実験結果や、Amazon Route 53における実装（エイリアスレコード）が紹介されました。

また、ANAME RRの追加をDynamic Updateで実装するという提案、SRV RRを使って閲覧者のWebブラウザーの設定を変更するという提案などの議論が行なわれましたが結論には至らず、継続して議論を進めることとなりました。

▽QNAME minimisationのStandards Track化（draft-ietf-dnsop-rfc7816bis）

QNAME minimisationはRFC 7816で定義される、プライバシー保護の観点からフルリゾルバー（キャッシュDNSサーバー）の名前解決アルゴリズムを変更するための仕組みです（*9）。

本提案は、現在は実験（Experimental）仕様となっているQNAME minimisationを、標準化過程（Standards Track）にするためのものとなっています。

なお、QNAME minimisationは、今回の提案からQuery Minimisationに名称が変更される予定となっています。

今回のWGでは、主要なフルリゾルバーやパブリックDNSサービスにおける対応状況を追記・更新したこと、予期した応答が得られなかった場合のフォールバックの戦略（Fallback strategies）については更なる議論が必要であることなどが報告され、継続して作業を進めることとなりました。

▽ルートサーバーへのアクセス時間の短縮（draft-ietf-dnsop-7706bis）

本提案は2015年に発行された、RFC 7706を更新するものです。RFC 7706では、リゾルバーと同じサーバーでルートゾーンのコピーを保持する権威DNSサーバーを動作させることでルートサーバーへのアクセス時間を短縮し、名前解決を効率化する方法を記述しています（*10）。

RFC 7706では、ループバックインタフェースを意識した実装方法が細かく定められていましたが、それ以外の方法も含め、具体的な実装方法についてはそれぞれの実装者に委ねる形に、提案が修正されています。

発表では、リゾルバーが保持するルートゾーンのコピーに問題があった場合の対応が課題として挙げられました。会場からは、インターネットのすべてのホームルーターがルートゾーンのコピーを保持することを想定した場合、技術的に対応可能かどうかについて質問や確認がありました。

今後は、アクセス時間の短縮だけでなく安定性が求められる場合など、本件のユースケースをより明確にする形で提案を修正することが報告され、継続して作業を進めることとなりました。

IETF 103開催中の2018年11月7日と11月9日に、現在作業が進められているルートゾーンKSKロールオーバーの今後に関する意見交換を目的とした「Root KSK futures」ミーティングが、ICANNのPaul Hoffman氏の主催で開催されました。なお、このミーティングはIETFの公式プログラムではなく、非公式のSide Meetingでした（*11）。

このミーティングでは、ルートゾーンのKSKを今後どのように維持管理すべきであるかという問いかけ／アイデアの募集と、今回のルートゾーンKSKロールオーバーに関する情報共有・議論が行われました。議論内容としては、ルートゾーンKSKロールオーバーそのものの必要性に関するものと、今回の作業において実際に観測・発生した状況に関するものが中心でした。

ルートゾーンKSKロールオーバーそのものについては、今後も定期的な実施が望ましいという意見が大勢を占めました。その理由として、鍵の危殆（きたい）化やサーバーのハードウェアの変更などに対応するため、常日頃から鍵の更新のオペレーションを経験しておくべきであることや、ルートゾーンにおいてもアルゴリズムロールオーバーをいずれかのタイミングで実施すべきであり、それに備える必要があるといった点が指摘されました。

ロールオーバーで観測された内容については、障害の発生状況と鍵更新における具体的なオペレーションに関する内容が報告・共有されました。APNICのGeoff Huston氏が実施した調査において、75のネットワークでエラーを検出・対応し、その中には100万人の利用者を持つISPも含まれていたことが報告されました。

また、このミーティングを主催したPaul Hoffman氏からは、今回のルートゾーンKSKロールオーバーに起因する障害事例や状況報告を求めており、情報がある場合、ksk-rolloverメーリングリスト（*12）に共有してほしい旨が呼び掛けられました。

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

名前解決における権威DNSサーバーの選択

NLnet LabsでUnboundの開発を担当しているBenno Overeinder氏から、Unboundに実装されている権威DNSサーバー選択アルゴリズムの概要を紹介する発表がありました。

フルリゾルバーが非再帰的問い合わせ（*13）を実行する際、あるゾーンの複数の権威DNSサーバーのいずれを選択するかのアルゴリズムは標準化されておらず、それぞれの実装により異なっています。

名前解決の効率を向上させるため、フルリゾルバーは応答のRTT（*14）や応答の受信におけるタイムアウトの制御（*15）といったさまざまな条件を加味し、権威DNSサーバーの選択アルゴリズムを実装・決定しています。

発表では、Unboundが名前解決においてどのように権威DNSサーバーを選択しているかが紹介され、DNS全体のパフォーマンスの向上とインターネットの安定性確保のためには、適切なサーバーの選択が重要であることが示されました。

次回の第104回IETF Meeting（IETF 104）は2019年3月23日から29日にかけ、チェコのプラハで開催されます。

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