第100回IETF Meeting（シンガポール）報告

2017年11月11日から17日にかけて、第100回IETF Meeting（以下、IETF 100）がシンガポールで開催されました。

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

• IETF 99以降のDNS関連RFCの発行状況
  - 特殊用途ドメイン名における問題点
  
• dnsop WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
  
• doh WGにおける話題
  - doh WGの設立
  - 議論された提案の内容と標準化作業の進行状況
  
• IEPG会合における話題
  - TLD間におけるインフラ共有に関する調査
  - ルートゾーンKSKロールオーバーの作業延期に関するアップデート
  
• 次回のIETF Meetingについて
  

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

特殊用途ドメイン名における問題点

• RFC 8244：特殊用途ドメイン名における問題点
  （Informational、draft-ietf-dnsop-sutld-ps）
  
  特殊用途ドメイン名（Special-Use Domain Names）（*1）は、.localや.testなど、通常のインターネットの利用以外の、特殊な用途のために予約されるドメイン名です。特殊用途ドメイン名の取り扱いはRFC 6761で定義されており、利用者やソフトウェアが対象のドメイン名を特殊用途ドメイン名であると認識し、通常とは異なる形で取り扱うことを想定しています。
  RFC 8244は、特殊用途ドメイン名の取り扱いについて、IETFにおけるこれまでの議論状況と現在の問題点をまとめて文書化したものです。このRFCで挙げられた代表的な問題点は、以下の通りです。
  


• ICANNとIETFの連携のプロセスが定められていないこと
  
• ICANNやIETFが、アドホックな名前の利用を排除できる権限を持っているわけではないこと
  
• インターネットに存在しない名前（内部利用名）である.onionの名前にサーバー証明書が発行・利用されていたことが、特殊用途ドメイン名の予約に影響を及ぼしたこと
  

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

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

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

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

今回のWGでは、提案の初版から現在の版までに拡張された主な用語の紹介と、今後の予定として、DNSクエリに関する次の四つの用語を追加予定であること、2018年1月15日にワーキンググループラストコール（WGLC）（*2）を実施予定であることが示されました。

• Recursive query
  
• Non-recursive query
  
• Iterative query
  
• Iterative resolution
  

参加者からは、「用語を新しい定義で使う人がいる中、これまでの定義で使う人も多くいることを認識すべき」「そもそも用語の定義は変化しうるものである」「われわれが進めているのは用語の定義の固定化ではなく、辞書の作成である」といったコメントがありました。

また、現在のRFC 7719はInformationalであったが、今回はStandards Trackでの標準化を目指すことが、WGチェアから示されました。

▽一つのDNSクエリで複数の応答を得る提案の比較検討

IETFでは以前から、一つのDNSクエリで複数の応答を得るための提案が何度か行われてきました。しかし、これまではいずれの提案も合意が得られず、標準化には至っていませんでした。

最近、この提案の議論が再開され、これまでに四つの提案が示されました。今回、JPRSの藤原和典が五つ目の提案を行うと同時に、それら五つの提案について技術的な特徴を比較検討した結果を発表しました。

比較検討の対象となった提案は、以下の通りです。

五つ目の藤原の提案は三つ目の提案と同様、Additional sectionに応答を追加するものですが、以下の点が異なっています。

• ゾーン管理者ではなく権威DNSサーバーの実装者がAdditional sectionに追加する応答を選ぶこと（*3）
  
• 追加対象のレコードが存在しなかった場合、不在証明に利用可能なNSEC/NSEC3レコードを追加することで、RFC 8198（*4）を活用したDNSの性能向上を想定していること
  

発表では、藤原が提示した比較表に対し参加者から活発にコメントが寄せられ、今後、この比較表を基にしつつ内容の追加や以降の進め方を検討することとなりました。

▽DNSエラーコードの拡張（draft-ietf-dnsop-extended-error）

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

現在のDNSの仕様では、名前解決処理においてサーバー側でエラーが発生した場合、それを知らせるためのエラーコードであるServFailを応答に設定します。しかし、DNSの運用においてServFailエラーが発生する原因はさまざまであり、現在の仕様では問い合わせ側にそれを伝える手段がないため、DNSのトラブルシューティングにおける課題となっていました。

本提案は、EDNS0を用いてServFailエラーの原因に関する情報を返すためのプロトコル拡張を定義し、DNS及びDNSSECの障害の原因を問い合わせ元に伝達できるようにするものです。現在の提案では、DNSSEC Bogus・DNSSEC Indeterminate・Lame・Prohibited・TooBusyの五つのエラーコードが新たに定義されています。

今回のWGでは、パケットのデータ構造を決めるためのエンコード案が複数提案され、活発な議論が行われましたが結論は出ず、継続して議論を進めることとなりました。

▽トラストアンカーの状況をクライアント側から調べる方法（draft-huston-kskroll-sentinel）

DNSクエリによって、DNSSECバリデーターのトラストアンカーの状況をクライアント側から調べるための仕組みを定義するプロトコル拡張の提案で、ルートゾーンKSKロールオーバーの進行状況の調査に用いることを想定しています。

提案では、以下に示す二つの特殊ラベル（special labels）によって、調査対象の鍵がトラストアンカーとなっているかどうかを、クライアント側から調べることができるようにしています。なお、<tag-index>には、鍵タグを16進表記で指定します。

今回のWGでは本提案に関心を持つ人が多く、WGとして標準化作業を進める方向となりました。しかし、特殊ラベルとして名前に特別な意味を持たせることを嫌う意見も多く、今後、WGの場で議論が進められることになります。

doh WGの設立

過去のDNS関連WGやアプリケーション関連エリアにおける議論で、DNSの通信をHTTPSの通信路で実現することの必要性が認識されました。それを受け、2017年9月15日にdoh WGが設立され、標準化作業を進めることとなりました。dohはDNS over HTTPSに由来しています。

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

今回のWGでは、前回のIETF 99 dispatch WG（*6）で提案・議論された、DNS over HTTPSの提案の改訂版に関する議論が行われました。

▽DNS over HTTPS（draft-ietf-doh-dns-over-https）

HTTPS通信のメッセージの本体に、DNSのワイヤーフォーマット（ビット列形式のバイナリフォーマット）をそのまま用いる提案です（*7）。

現在の提案では、GETメソッドではBase64エンコード、POSTメソッドではバイナリフォーマットのままで取り扱う形になっています。

WGでは、プロトコルの仕様としてHTTP/2を必須とするかどうかと、DNSのキャッシュとHTTPのキャッシュの取り扱いの違いについて議論され、継続して作業を進めることとなりました。

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

TLD間におけるインフラ共有に関する調査

SIDN LabsのGiovane C. M. Moura氏が、権威DNSサーバーやそのネットワークがTLD間でどの程度共有されているかについて、ルートゾーンの設定内容から調査した結果を発表しました。

あるドメイン名の権威DNSサーバーがDDoS攻撃の被害を受けた場合、同じ権威DNSサーバーやネットワークインフラを使って提供されている攻撃対象外のドメイン名も、巻き添えによる被害を受けることになります。

発表では、2014年と2017年のルートゾーンの設定内容を基に、TLD間におけるネームサーバー名・IPアドレスブロック・AS番号の共有状況を調査した結果が発表されました。Moura氏からは、想定よりも多くのTLDでインフラが共有されていたことと、現在は「oversharing（過度に共有されている状態）」なのではないかという見解が示されました。

ルートゾーンKSKロールオーバーの作業延期に関するアップデート

ICANN CTOのDavid Conrad氏が、10月に予定されていたルートゾーンKSKロールオーバーの作業延期の経緯（*8）と、その後の状況について発表しました。

発表では、作業延期の理由と今後の予定に加え、作業延期の発表後にトラストアンカーとしてKSK-2017を保持するフルリゾルバーのIPアドレスの数が減り、KSK-2010のみを保持するリゾルバーのIPアドレスの数が増えたことが報告されました。

RFC 5011によるトラストアンカーの自動更新を有効にしている場合、今回の作業延期によって保持するトラストアンカーがKSK-2010のみになることはありません。そのため、これらのフルリゾルバーはトラストアンカーを手動で設定している可能性があり、今回の作業延期の発表を受け、管理者がトラストアンカーの設定を元に戻したのではないかと推測されています。

発表では今後のステップとして、更に情報を集めて状況の理解を進めること、作業をどの程度延期するかはまだ決定していないこと（*9）、KSK-2010のみを保持しているフルリゾルバーが存在する原因の分析を継続することが示され、今回の状況から「KSK-2017を削除しないでください」という旨の追加アナウンスが必要になるかもしれないことが示されました。

次回の第101回IETF Meeting（IETF 101）は2018年3月17日から23日にかけ、英国のロンドンで開催されます。

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