JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2018年

第101回IETF Meeting(ロンドン)報告

~DNS関連WG、及び周辺会合における話題~

2018年3月17日から23日にかけて、第101回IETF Meeting(以下、IETF 101)が英国のロンドンで開催されました。

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

  • IETF 100以降のDNS関連RFCの発行状況
    - DNS over TLS/DTLSにおけるプロファイルと認証方式
    - DNSの再設計と置き換え、機能に関する明確な線引きの呼びかけ
  • dnsop WGにおける話題
    - チェアの追加募集
    - 議論された提案の内容と標準化作業の進行状況
    - RFC 8324の公開を受けての議論
  • dprive WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  • doh WGにおける話題
    - 議論された提案の内容と標準化作業の進行状況
  • IEPG会合における話題
    - Additional Truncated Response(ATR)に関する計測結果
    - EDNS0に関する一時的な回避策(ワークアラウンド)の削除
  • 次回のIETF Meetingについて
会場となったHilton Metropole

会場となったHilton Metropole

IETF 100以降のDNS関連RFCの発行状況

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

DNS over TLS/DTLSにおけるプロファイルと認証方式

  • RFC 8310:DNS over TLS/DTLSにおけるプロファイルと認証方式
    (Standards Track、draft-ietf-dprive-dtls-and-tls-profiles)


    RFC 8310は、DNS over TLS/DTLS(*1)による通信のために必要なプロファイル(*2)の内容と、DNS over TLS/DTLSにおけるDNSサーバーの認証方式を定義します。
(*1)
DNS over TLSはHTTPSで用いられているTLSをDNSに適用する技術で、TCPでの通信が前提となります。一方、DNS over DTLSはTLSをUDPに対応させたDTLSをDNSに適用する技術で、UDPでの通信が前提となります。
(*2)
プロファイルについての概要は、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2016/0510IETF.html

DNSの再設計と置き換え、機能に関する明確な線引きの呼びかけ

  • RFC 8324:DNSプライバシー、認可、特殊用途、エンコーディング、文字、マッチング、そしてルート構造:見直しの時なのか?
    (Informational、draft-klensin-dns-function-considerations)


    DNSの基本部分は30年以上前に設計されました。そして、その後のインターネットの状況の変化やDNSに対する要求事項の変化に対応するため、これまでにさまざまな改良や機能追加が図られてきました。
    RFC 8324は、DNSにおいてこれまでに欠点が指摘されたり、議論の対象となったりした項目の概要とその論点をまとめた上で、それらを踏まえたDNSの再設計と置き換え、機能に関する明確な線引きの必要性について、広く問いかけたものです。
    なお、このRFCはIETFのワーキンググループで議論されたものではなく、長年にわたってIETFで活動し、多数のRFCを執筆したJohn Klensin氏の執筆によるものです。今回、IESG(*3)の承認を経た上で、Informational(情報提供)RFCとして発行されました。
(*3)
Internet Engineering Steering Groupの略称。
IETFのWGが所属する各エリアのエリアディレクターにより構成され、IETFの活動と標準化プロセスの技術管理を担当します。

dnsop WGにおける話題

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

チェアの追加募集

最近のdnsop WGでは活発な標準化活動が進められており、第99回IETF Meeting以降、多数の提案を扱うために2枠分の時間を使い議論される状況が続いています。

そのため、担当エリアディレクターのWarren Kumari氏から、dnsop WGの運営を担当する現在の2人のチェアに加え、3人目のチェアの追加募集が呼び掛けられました。

その結果、IETF 101終了後の2018年4月11日にNLnet LabsのBenno Overeinder氏が、3人目のチェアに任命されました。

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

▽DNS用語の明確化(draft-ietf-dnsop-terminology-bis)

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

会合に先立って更新された提案では、「Lame delegation」や「Public suffix」といった用語の追加や、細部の修正などが行われています。

今回のWGでは前回に引き続き、著者の一人であるICANNのPaul Hoffman氏から、WGの参加者に更新内容のレビューが依頼されました。今後、2018年4月中にワーキンググループラストコール(WGLC)が実施される予定です。

▽クエリタイプANYのレスポンスサイズの小型化(draft-ietf-dnsop-refuse-any)

DNSリフレクター攻撃の効果を低減するため、クエリタイプANYに対する応答の仕様を変更して応答サイズを小さくする、プロトコル変更の提案です。

提案では応答サイズを減らすため、サーバーが知っているすべてのリソースレコードセット(以下、RRset)を返すという従来の動作に加え、

1.
一部のRRsetのみを返す
2.
動的に生成されたHINFO(ホストの情報)リソースレコード(以下、RR)を返す

という動作を選択可能にしています。

今回のWGでは、WGLC後に出されたすべてのコメントを提案に反映したこと、近日中にIESGに送付予定であることが報告されました。

▽トラストアンカーの状況をクライアント側から調べる方法(draft-ietf-dnsop-kskroll-sentinel)

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

今回のWGでは、前回のIETF 100からの変更点が共有・議論され、継続して作業を進めることとなりました。主な変更点は、以下の通りです。

トラストアンカーの状況を調べる特殊ラベルの仕様変更
- 従来:_is-ta-<key-tag>と_not-ta-<key-tag>
- 変更:root-key-sentinel-is-ta-<key-tag>とroot-key-sentinel-not-ta-<key-tag>
<key-tag>に指定する鍵タグの仕様変更
- 従来:16進数で指定
- 変更:10進数で指定、5桁にパディング(例えば42の場合、00042)

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

CDN(Content Delivery Network)での利用を想定し、ANAME(Address-specific DNS Name Redirection)というCNAME RRと同様の機能を提供する、他のRRと共に指定可能な新しいRRを定義するための提案です(*4)。

(*4)
ANAMEが提案された背景とその目的については、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2017/0829IETF.html

今回のWGでは、前回までの議論を踏まえ、

ANAMEの機能を、権威DNSサーバーとフルリゾルバー(キャッシュDNSサーバー)の双方の仕様変更で実現する予定であること
それぞれの仕様を記述するため、現在の提案を二つに分割しようと考えていること

が発表されました。

本件はDNSプロトコルに大きな変更を加えるものであるため、活発な議論が交わされましたが結論には至らず、継続して作業を進めることとなりました。

RFC 8324の公開を受けての議論

今回のWGでは、DNSの再設計と置き換え、機能に関する明確な線引きについて問いかけたRFC 8324の発行を受け、PowerDNSの開発者のBert Hubert氏が「The DNS Camel, Or How many features can we add to this protocol before it breaks?」と題した発表を行いました。

発表では、

DNSに長年にわたり多数の機能が追加され、仕様が複雑化している
それにより、以下の状況が引き起こされている
- 機能間の衝突
- すべての仕様や機能を理解できる人の減少
- コードの複雑化
- 実装の品質とセキュリティレベルの低下
その原因として、DNSの実装開発者・フルリゾルバーの運用者・TLDやルートの権威DNSサーバーの運用者・標準化活動の推進者といった、主なDNS関係者の思惑と要求が、互いに反映されていないことが挙げられる
結果、機能の過剰(glut)が、DNS全体の停滞(statis)を引き起こす

という問題が提起され、この状況を打破するための方策として、

標準化の際に誰がその機能を欲するか、誰が便利になるのかを考えること
そのコストを誰がどう負担するのかも考えること
DNSの実装開発者やサーバー運用者のコミュニティが、より包括的にIETFの活動に関われるようにすること

が呼び掛けられました。

会場からは大きな反響があり、肯定的な内容を中心に活発な意見交換が行われました。また、RFC 8324の発行を受けた具体的な動きの例として、以下が紹介されました。

EDNS0に準拠しない応答を受け取った際の例外処理の廃止(*5)(draft-spacek-edns-camel-diet)
使われておらず、かつ廃止されていないRRの廃止(draft-sury-deprecate-obsolete-resource-records)
(*5)
今回のIEPG会合で、複数のオープンソースDNSサーバーの実装における対応スケジュールが発表されました。詳細は本報告の「IEPG会合における話題」をご参照ください。

dprive WGにおける話題

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

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

▽DNSプライバシーに関するサービス運用者の推奨事項(draft-dickinson-bcp-op)

本提案は、DNSプライバシーサービスの運用ポリシーとセキュリティ上の考慮事項について考察・まとめたもので、サービスの運用者に以下の三つの項目を提供することを目指しています。

DNS over TLS/DTLSの運用の指針
DNSプライバシーサービスの運用者における、データの取り扱いの概要
DNSSECのDPS(*6)に相当する「DNSプライバシーポリシーと運用ステートメント(DNS Privacy Policy and Practice Statements: DPPPS)」を作成するための枠組み
(*6)
DPS(DNSSEC Practice Statement)は、管理対象ドメイン名におけるDNSSECサービスの安全性や運用のポリシー、考え方、手順などについて網羅的にまとめた文書で、そのドメイン名のDNSSEC運用者が必要に応じて作成・公開します。

今回のWGでは、本提案は初版であり、まだ多くの作業項目があることが報告され、DNSプライバシーの運用には技術だけではなくポリシーも含まれるが、今後もIETFで議論を続けるべきかどうかが話し合われました。

会場からは、運用ポリシーの議論についてはIETFでも進めるのがよいというコメントがあり、また、提案の内容についてもサポートする意見が多く、今後も継続して作業を進めることになりました。

▽フルリゾルバーと権威DNSサーバー間におけるプライバシーの確保(draft-bortzmeyer-dprive-resolver-to-auth)

dprive WGではこれまで、スタブリゾルバーとフルリゾルバー間の通信におけるプライバシーの確保に関する標準化作業を進めてきました。

今回の提案は次の段階として、フルリゾルバーと権威DNSサーバー間の通信におけるプライバシーの確保を目標としています。そして、そのために必要な暗号化と認証の仕組みの標準化において考慮すべき点についてまとめています。

▽リチャーターに関する議論

dprive WGの当初の目標であった、スタブリゾルバーとフルリゾルバー間の通信のプライバシー確保に関する標準化作業は、ほぼ完了しています。それを受け、今後WGのチャーターを改定(リチャーター)して、次のステップであるフルリゾルバーと権威DNSサーバーの通信のプライバシー確保をどう進めていくかについての検討が進められました。

今回のWGでは、今後の作業に関するさまざまな論点や作業を進めるにあたっての懸念点について活発な議論が行われましたが結論には至らず、継続して議論を進めることとなりました。

doh WGにおける話題

dohはDNS over HTTPSに由来し、DNSの通信をHTTPSの通信路で実現するため、DNSクエリとレスポンスのエンコードを標準化することを目的としています。

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

▽DNS over HTTPS(draft-ietf-doh-dns-over-https)

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

(*7)
これまでのDNS over HTTPSの取り扱いについての概要は、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2017/1213IETF.html

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

WGでは、今回のIETFハッカソンで作成された五つの実装で相互接続を行った経験が紹介され、その結果を提案に反映し、継続して作業を進めることとなりました。

IEPG会合における話題

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

Additional Truncated Response(ATR)に関する計測結果

APNICのGeoff Huston氏から、IPフラグメンテーションを適切に受信できない場合の対策として提案されているATR(*8)について、実際のネットワークでどの程度の効果が期待できるかを計測した結果が発表されました。

(*8)
フラグメントされた応答を受け取れない場合にTCPでの再問い合わせを促すため、通常の応答の10ms後に、切り詰めが起こったことを意味するTCビットがセットされた短い応答を追加で返すようにする提案です(draft-song-atr-large-resp)。

計測の結果、DNS応答処理の失敗率がIPv4では12.5%から4.0%に、IPv6では20.8%から8.4%に減少したことが発表され、ATRの導入が一定の効果を発揮する可能性があることが示されました。

EDNS0に関する一時的な回避策(ワークアラウンド)の削除

ISCのOndrej Sury氏から、EDNS0対応したDNSクエリに対して不適切な応答を返すDNSサーバーに対応するためのワークアラウンドの処理を、複数のオープンソースDNSサーバーの実装から削除する計画が発表されました。

今回の計画は同氏が所属するISCに加え、CZ.NIC、NLnet Labs、PowerDNS.COM BVの連名で発表されており、それぞれが開発しているリゾルバーの実装であるBIND、Knot Resolver、Unbound、PowerDNS Recursorで、同時に実施される予定です。

今回の計画では、2019年2月1日にワークアラウンドの処理の削除を実施するとしており、DNSサーバーの実装者に向け、EDNS0に関する適切な応答の仕方は以下のいずれかであり、そのように実装すべきであることを呼び掛けています。

EDNS0を正しく実装し、適切に処理する
DNSの応答コード(RCODE)として、フォーマットエラーを意味するFORMERRを応答する

この計画は、前述したRFC 8324の公開とその後の議論を受けたものの一つであ り、サーバー実装をシンプルにすることで開発コストを軽減するための動きの 一環です。

次回のIETF Meetingについて

次回の第102回IETF Meeting(IETF 102)は2018年7月14日から20日にかけ、カナダのモントリオールで開催されます。

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