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


メールマガジン「FROM JPRS」

バックナンバー:vol.180

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━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.