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

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

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

• IETF 105以降のDNS関連RFCの発行状況
  - DNSパケットキャプチャーのためのフォーマットの定義
  - CAAリソースレコードにおける、アカウントURIと自動証明書管理環境
  （ACME）における検証方法の指定
  - CAAリソースレコードの仕様改訂
• dnsop WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
• dprive WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
  
• Application Behavior Considering DNS（abcd）BoFの状況
• IEPG会合における話題
  - TLDの権威DNSサーバーにおけるDNSSEC検証エラーの検出
• 次回のIETF Meetingについて

前回のIETF 105以降に発行された、DNS関連のRFCの内容は以下の通りです。

▼DNSパケットキャプチャーのためのフォーマットの定義

• RFC 8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture
  （Standards Track、draft-ietf-dnsop-dns-capture-format）
  
  RFC 8618は、DNSメッセージを収集する際に利用可能なデータ表現形式を定義します。
  
  DNSトラフィックの監視や分析、サイバー攻撃の検出などを目的としたパケットキャプチャーをする場合、収集した大量のDNSメッセージを効率よく保存・交換できる形式があると便利です。
  
  本RFCは保存に必要な容量を削減し、かつ、データの交換が可能なデータ表現形式としてCBOR[*1]を用いた「Compacted-DNS（C-DNS）」を定義し、アプリケーションの開発を支援することを目的としています。

▼CAAリソースレコードにおける、アカウントURIと自動証明書管理環境（ACME）における検証方法の指定

• RFC 8657: Certification Authority Authorization (CAA) Record
  Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding（Standards Track、draft-ietf-acme-caa）
  
  CAAリソースレコード[*2]のissue/issuewildプロパティでは、ドメイン名の管理者が証明書の発行を許可する認証局（CA）を、パラメーターとして指定します。

▼CAAリソースレコードの仕様改訂

• RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record（Standards Track、draft-ietf-lamps-rfc6844bis）
  
  RFC 8659は、CAAリソースレコードの基本仕様を定義します。
  RFC 8659は、従来のRFC 6844を置き換えます。
  
  RFC 8659はRFC 6844から、以下の点が変更されています。
  


• 認証局がCAAリソースレコードを検索するアルゴリズムを、途中で見つかったCNAME/DNAMEで指定される階層構造は対象としないように簡略化
• issue/issuewildタグの文法を明確化
• issue/issuewildタグを含まないCAAリソースレコードの処理を明確化
• 用語の定義を明確にするための構成変更

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

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

▽DNSにおけるIPフラグメンテーションの回避
（draft-fujiwara-dnsop-avoid-fragmentation）

JPRSの藤原和典が提案している、DNSにおけるIPフラグメンテーション（断片化）を回避する提案です[*4]。-00版から-01版への更新にあたり、FarsightのPaul Vixie氏が共著者に加わっています。

今回、IETF 105以降の作業で、以下の項目を追記したことが発表されました。

• RFC 8085（UDPの使用ガイドライン）への参照
• DNSにおけるデフォルトのUDPペイロードサイズに関する考察
• ゾーン管理者に対する要請事項
• path MTUの値を得る方法

WGでは、intarea WGがIPフラグメンテーションの脆弱さ（fragility）とその代替案を開発者とネットワークオペレーターに提案している、draft-ietf-intarea-frag-fragileがRFC発行の直前（RFC Ed Queue）であり発行を待つことと、発行後にその内容を踏まえた内容調整が必要であるとのコメントがありました。今後、コメントを受けたアップデート作業を継続していく予定です。

▽プライベートな名前空間のためのTLD（draft-arends-private-use-tld）

プライベートな名前空間のためのTLDとして、ISOがユーザー割り当て用コード（user-assigned codes）として予約している文字列を使える、ということを示した提案です。

これまで、通常のインターネット以外で利用するための特殊用途ドメイン名（Special-Use Domain Names）[*5]として、.testや.localなどのTLDが提案・予約されてきました。しかし、現時点ではプライベートIPアドレスに相当する、プライベートな名前空間のためのTLDは設定・予約されていません。

この提案ではプライベートな名前空間のためのTLDとして、ISO 3166 alpha-2[*6]のユーザー割り当て用コードとされている文字列のうち、.ZZを利用することを推奨しています。

その理由として、それらの文字列は予約されているため、将来いずれかの国や地域に割り当てられてしまうリスクがないことを挙げています。

WGでは、これまでのTLD予約文字列とそのRFCに関する状況が確認されました。会場からは、ccTLDの国・地域コードを定めるのはISOの仕事であってIETFの仕事ではなく、dnsop WGとして特定のコードに関する特別な使用法を推奨することはできないのではないか、という意見が寄せられました。

▽相互運用可能なサーバークッキー（draft-ietf-dnsop-server-cookies）

IP Anycastを用いた複数台／複数種類のサーバーを運用する際にも相互運用可能な、DNSクッキー[*7]の作成方法を定義するための提案です。

前回のIETF 105では、使用されるアルゴリズムがSipHash-2.4の1種類のみとされ、クッキー中のSub-Fieldの利用方法が明確化されました。

今回のIETF 106ではdnsop WGに先だって開催されたIETFハッカソンの結果を踏まえた提案が行われました。提案では、従来からのサーバークッキーの相互運用性に加え、クライアントクッキーが少なくとも64ビットのエントロピーを持つようにという推奨事項が加えられるなど、DNSクッキーに関するセキュリティとプライバシーに関する考慮事項が追加されています。

今後、これまでに議論・実験された仕様をもとに、標準化作業と実装が進められていく予定です。

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

本提案では、EDNS0を用いてエラーコードを拡張するための「Extended DNSError (EDE)」オプションと、情報を返すための「Extended DNS Error Code」を定義することで、エラーの原因に関する追加情報を問い合わせ元に返せるようにします。

現在のDNSSECでは検証においてエラーが発生した場合、従来のDNSにおける名前解決エラーの場合と同様、SERVFAIL応答を返します。しかし、SERVFAIL応答はサーバー側で名前解決エラーが発生したことのみを示しており、その原因が何なのかを示す追加情報は含まれません。この提案は、この問題を解決し、DNSSEC検証エラーの原因を問い合わせ（スタブリゾルバー）側で把握できるようにするものです。

本提案は、2017年2月に初版（draft-wkumari-dnsop-extended-error-00）が公開された後、多くの議論と改訂を経た後、現在ワーキンググループラストコール（WGLC）が実施されています。

dpriveはDNS PRIVate Exchangeに由来しており、DNSトランザクションにおける機密性（confidentiality）の提供を目的としています。

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

▽Oblivious DoHによるプライバシーの向上
（draft-pauly-dprive-oblivious-doh）

DNSクライアントとフルリゾルバー（キャッシュDNSサーバー）の通信にプロキシを介在させることで、DNSクライアントのIPアドレスと問い合わせ内容の双方を同時に把握されないようにする、DNS over HTTPS（DoH）の拡張機能の提案です。

本提案では、Oblivious DoH（ODoH） Proxyと呼ばれるプロキシをDNSクライアントとフルリゾルバーの間に配置したうえで、クライアントとフルリゾルバーの間の通信を暗号化する方式を提唱しています。

しかし、この方式はODoH Proxyの追加に加え、DNSクライアントとフルリゾルバーにおける暗号化と復号も必要になるため、プロトコルが複雑化するというデメリットがあります。

▽権威DNSサーバーとフルリゾルバーの間の通信の暗号化に関する議論
（draft-lmo-dprive-phase2-requirements）

dprive WGのPhase 2[*8]として、権威DNSサーバーとフルリゾルバーの間の通信の暗号化が検討されています。

今回は前回のIETF 105に引き続き、標準化作業を進めるための要求条件と実装案についての議論が行われました。

会場では、通信の暗号化ではなくQNAME minimisation[*9]で十分ではないか、サーバーの証明書として何を使うべきか、といった既存の問題点が確認され、今回のIETFハッカソンでUnboundに権威DNSサーバーとフルリゾルバーの間のDNS over TLSを試験実装したことが紹介されました。

DoHはプロトコルの仕様がRFC 8484として標準化されましたが、その運用・利用についての規定はなく、さまざまな懸念が指摘されています。今回のIETF 106では、DoHの運用に必要な技術的規定を作成するWGの設立を目的としたabcd BoFが開催されました。

BoFでは、DoHとDoT（DNS over TLS）のクライアント・サーバー実装状況の紹介と、DoHの考慮事項やクライアント設定方法の各種提案[*10]について振り返られた後、WGの作業対象を決めるチャーターについて議論されました。

BoFチェアから示されたチャーター案に対して、会場からは、dnsopではなく独立したWGとする理由を明確にすべき、作業項目をもっと絞り込み解決可能な技術的議論に集中すべき、BCPは技術的課題が解決してからリチャーターして取り込めばよい、などの意見が寄せられました。WG設立に反対する意見は特にありませんでしたが、チャーターのコンセンサスは得られず、AD及びIETFチェアから、WG設立を前提にadd MLで議論を継続することとまとめられました。

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

▼TLDの権威DNSサーバーにおけるDNSSEC検証エラーの検出

国立情報学研究所（NII）とJPRSが共同で進めている、JP DNSサーバーへの問い合わせ状況を計測することでDNSSEC検証失敗の検知を試みる研究について、JPRSの米谷嘉朗が発表しました。

フルリゾルバー（バリデーター）でDNSSEC検証の失敗が発生すると、名前解決を繰り返すため、当該ドメイン名の権威DNSサーバーやTLDを含む親ゾーンの権威DNSサーバーへのDNSSEC関連クエリが増加します。DNSSEC検証失敗によるクエリ増加の特徴を捉えることができれば、DNSSECの誤設定を早期に検知できるようになるのではないかという仮説のもと、研究を進めています。

今回の発表では、現在までの知見として、DNSKEYのクエリ増加がその特徴を示す可能性があることを紹介しています。

次回の第107回IETF Meeting（IETF 107）は2020年3月21日から27日にかけ、カナダのバンクーバーで開催されます。

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