JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2018/12/13━ ◆ FROM JPRS 増刊号 vol.180 ◆ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ___________________________________ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ 第103回IETF Meeting(バンコク)報告 ~DNS関連WG、及び周辺会合における話題~ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 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の発行状況 前回の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をアプリケーションに実装する 際の具体的なポリシーと方策について記述しています。 (*1)EDNSは、RFC 6891で定義されているDNSの拡張方式で、バージョン 番号を示すためにEDNS0またはEDNS(0)と呼ばれます。EDNS(0)の詳 細は、JPRS用語辞典をご参照ください。 https://jprs.jp/glossary/index.php?ID=0147 (*2)パディング(padding) データの長さを調整するため、データの前後に意味を持たないデー タを追加すること。また、追加したデータ。 ▼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ではそ の論争と、テストベッドの運営者自身による見解も紹介されています。 (*3)Yeti DNS https://yeti-dns.org/ (*4)独自のルートサーバーを立ち上げ、ICANNの管理下にないドメイン名 空間を構築したものです。オルタネート・ルートの存在によって、 ドメイン名の一意性が保障できない可能性があるため、問題視され ています。 ▼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パ ケットをそのままの形で扱います。 (*5)RFC 2818で定義される、インターネット越しのHTTPコネクションを セキュアにするためにTLSを使うプロトコルです。 (*6)RFC 7858で定義される、HTTPSで用いられているTLS(Transport Layer Security)を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サーバーまたはクライアントの動作に関 する指針を提供します。 (*7)DNSを利用したDoS攻撃の一つです。送信元IPアドレスを偽った通常 のDNS問い合わせをDNSサーバーに送ることでDNSサーバーが応答パ ケットを攻撃対象に送り、サービス不能の状態に陥らせます。DNS リフレクター攻撃の詳細は、JPRS用語辞典をご参照ください。 https://jprs.jp/glossary/index.php?ID=0156 ■dnsop WGにおける話題 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)。 (*8)ANAMEが提案された背景とその目的の詳細については、過去のドメイン 名関連会議報告をご参照ください。 https://jprs.jp/related-info/event/2017/0829IETF.html なお、今回の提案から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)にするためのものとなっています。 (*9)QNAME minimisationの詳細は、過去のドメイン名関連会議報告をご参照 ください。 https://jprs.jp/related-info/event/2015/0421IETF.html なお、QNAME minimisationは、今回の提案からQuery Minimisationに名称が変 更される予定となっています。 今回のWGでは、主要なフルリゾルバーやパブリックDNSサービスにおける対応 状況を追記・更新したこと、予期した応答が得られなかった場合のフォール バックの戦略(Fallback strategies)については更なる議論が必要であるこ となどが報告され、継続して作業を進めることとなりました。 ▽ルートサーバーへのアクセス時間の短縮(draft-ietf-dnsop-7706bis) 本提案は2015年に発行された、RFC 7706を更新するものです。RFC 7706では、 リゾルバーと同じサーバーでルートゾーンのコピーを保持する権威DNSサー バーを動作させることでルートサーバーへのアクセス時間を短縮し、名前解決 を効率化する方法を記述しています(*10)。 (*10)RFC 7706の詳細については、過去のドメイン名関連会議報告をご参照く ださい。 https://jprs.jp/related-info/event/2014/1217IETF.html RFC 7706では、ループバックインタフェースを意識した実装方法が細かく定め られていましたが、それ以外の方法も含め、具体的な実装方法についてはそれ ぞれの実装者に委ねる形に、提案が修正されています。 発表では、リゾルバーが保持するルートゾーンのコピーに問題があった場合の 対応が課題として挙げられました。会場からは、インターネットのすべての ホームルーターがルートゾーンのコピーを保持することを想定した場合、技術 的に対応可能かどうかについて質問や確認がありました。 今後は、アクセス時間の短縮だけでなく安定性が求められる場合など、本件の ユースケースをより明確にする形で提案を修正することが報告され、継続して 作業を進めることとなりました。 ■「Root KSK futures」ミーティングの開催 IETF 103開催中の2018年11月7日と11月9日に、現在作業が進められているルー トゾーンKSKロールオーバーの今後に関する意見交換を目的とした「Root KSK futures」ミーティングが、ICANNのPaul Hoffman氏の主催で開催されました。 なお、このミーティングはIETFの公式プログラムではなく、非公式のSide Meetingでした(*11)。 (*11)Unofficial Side Meetings at IETF 103 https://trac.ietf.org/trac/ietf/meeting/wiki/103sidemeetings https://www.ietf.org/mail-archive/web/dnsop/current/msg24497.html このミーティングでは、ルートゾーンのKSKを今後どのように維持管理すべき であるかという問いかけ/アイデアの募集と、今回のルートゾーンKSKロール オーバーに関する情報共有・議論が行われました。議論内容としては、ルート ゾーンKSKロールオーバーそのものの必要性に関するものと、今回の作業にお いて実際に観測・発生した状況に関するものが中心でした。 ルートゾーンKSKロールオーバーそのものについては、今後も定期的な実施が 望ましいという意見が大勢を占めました。その理由として、鍵の危殆(きたい) 化やサーバーのハードウェアの変更などに対応するため、常日頃から鍵の更新 のオペレーションを経験しておくべきであることや、ルートゾーンにおいても アルゴリズムロールオーバーをいずれかのタイミングで実施すべきであり、そ れに備える必要があるといった点が指摘されました。 ロールオーバーで観測された内容については、障害の発生状況と鍵更新におけ る具体的なオペレーションに関する内容が報告・共有されました。APNICの Geoff Huston氏が実施した調査において、75のネットワークでエラーを検出・ 対応し、その中には100万人の利用者を持つISPも含まれていたことが報告され ました。 また、このミーティングを主催したPaul Hoffman氏からは、今回のルートゾー ンKSKロールオーバーに起因する障害事例や状況報告を求めており、情報があ る場合、ksk-rolloverメーリングリスト(*12)に共有してほしい旨が呼び掛 けられました。 (*12)ksk-rollover Info Page https://mm.icann.org/listinfo/ksk-rollover ■IEPG会合における話題 IEPG(Internet Engineering and Planning Group)は、IETF会合に先立って 日曜日午前に開催される会合で、インターネットの運用に関連するさまざまな テーマを取り扱っています。 ▼名前解決における権威DNSサーバーの選択 NLnet LabsでUnboundの開発を担当しているBenno Overeinder氏から、Unbound に実装されている権威DNSサーバー選択アルゴリズムの概要を紹介する発表が ありました。 フルリゾルバーが非再帰的問い合わせ(*13)を実行する際、あるゾーンの複 数の権威DNSサーバーのいずれを選択するかのアルゴリズムは標準化されてお らず、それぞれの実装により異なっています。 (*13)DNSにおいて、スタブリゾルバー(DNSクライアント)からの名前解決 の依頼(要求)に応じて名前解決を実行するための問い合わせです。 詳細は、JPRS用語辞典をご参照ください。 https://jprs.jp/glossary/index.php?ID=0174 名前解決の効率を向上させるため、フルリゾルバーは応答のRTT(*14)や応答 の受信におけるタイムアウトの制御(*15)といったさまざまな条件を加味し、 権威DNSサーバーの選択アルゴリズムを実装・決定しています。 (*14)通信相手にデータを送信してから応答が返ってくるまでの時間(通信の 往復時間)です。RTTの詳細は、JPRS用語辞典をご参照ください。 https://jprs.jp/glossary/index.php?ID=0195 (*15)Unboundにおけるタイムアウトの制御方法が、以下で公開されています。 NLnet Labs Documentation - Unbound - Unbound Timeout Information https://www.nlnetlabs.nl/documentation/unbound/info-timeout/ 発表では、Unboundが名前解決においてどのように権威DNSサーバーを選択して いるかが紹介され、DNS全体のパフォーマンスの向上とインターネットの安定 性確保のためには、適切なサーバーの選択が重要であることが示されました。 ■次回のIETF Meetingについて 次回の第104回IETF Meeting(IETF 104)は2019年3月23日から29日にかけ、 チェコのプラハで開催されます。 ◇ ◇ ◇ ◎関連URI - 103 Meeting Index https://www.ietf.org/how/meetings/103/ (IETF 103公式ページ) - IETF 103 meeting materials https://datatracker.ietf.org/meeting/103/materials.html (IETF 103発表資料一覧) - Domain Name System Operations (dnsop) https://datatracker.ietf.org/wg/dnsop/charter/ (dnsop WG公式ページ) - IEPG Meeting - November 2018 https://iepg.org/2018-11-04-ietf103/ (2018年11月4日のIEPG Meeting公式ページ) ━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━ ■会議報告:https://jprs.jp/related-info/event/ ■配信先メールアドレスなどの変更:https://jprs.jp/mail/henkou.html ■バックナンバー:https://jprs.jp/mail/backnumber/ ■ご意見・ご要望:from@jprs.jp 当メールマガジンは、Windowsをお使いの方はMSゴシック、macOSをお使いの方 はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。 当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、 ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。 また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、 リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに ご注意ください。 その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。 https://jprs.jp/mail/kiyaku.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 編集・発行:株式会社日本レジストリサービス(JPRS) https://jprs.jp/ Copyright (C), 2018 Japan Registry Services Co., Ltd.