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

メールマガジン「FROM JPRS」

バックナンバー：vol.193

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2020/12/23━
                    ◆ FROM JPRS 増刊号 vol.193 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                      第109回IETF Meeting報告
        ～オンライン会合の開催状況と、DNS関連WGにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2020年11月16日から20日にかけ、第109回IETF Meeting（以下、IETF 109）が、
オンラインで開催されました。新型コロナウイルスの感染拡大を受け、IETF
Meetingは2020年3月に開催されたIETF 107以降、オンラインでの開催が続いて
います。

今回のFROM JPRSでは、オンライン会合の開催状況、DNS関連RFCの発行状況、
及びDNS関連WGにおける話題について、以下の項目に沿ってお伝えします。

  ・オンライン会合の開催に関する話題
    - 開催の状況
  ・IETF 108以降のDNS関連RFCの発行状況
    - 特殊用途ドメイン名「ipv4only.arpa」の取り扱い（RFC 8880）
    - DNS-SD/マルチキャストDNSにおけるプライバシーとセキュリティ上の要
      件（RFC 8882）
    - 複数の署名者によるDNSSECの運用モデル（RFC 8901）
    - DNSサーバーにおける、通信の失敗を引き起こす運用上の問題
      （RFC 8906）
    - DNSにおけるエラーコードの拡張（RFC 8914）
    - DNSプライバシーサービスの運用者における推奨事項（RFC 8932）
    - TSIGの仕様修正（RFC 8945）
    - レジストリデータエスクローの仕様（RFC 8909）
  ・dnsop WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・dprive WGにおける話題
    - 議論された主な提案の内容と作業の進行状況
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■オンライン会合の開催に関する話題

▼開催の状況

今回のIETF 109も前回に引き続きフルアジェンダの形で開催され、世界各地か
ら1,000人以上が参加しました[*1]。なお、IETFハッカソンは本会合に先立ち、
11月9日から13日にかけ、オンラインで開催されました[*2]。

[*1] IETF | IETF 109 Highlights
     https://www.ietf.org/blog/ietf109-highlights/

[*2] IETF | IETF 109 Hackathon - Finding New Ways to Collaborate
     https://www.ietf.org/blog/ietf109-hackathon/

オンライン会合には、前回に引き続きMeetecho[*3]が使われました。

[*3] RTC Experts - Meetecho
     https://www.meetecho.com/

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

前回のIETF 108以降に発行された、DNS関連のRFCの内容をご紹介します。なお、
RFC 8909はレジストリ技術に関するRFCですが、本項で併せて紹介します。

▼特殊用途ドメイン名「ipv4only.arpa」の取り扱い
  ・RFC 8880: Special Use Domain Name 'ipv4only.arpa'
    （Standards Track、draft-cheshire-sudn-ipv4only-dot-arpa）

「ipv4only.arpa」はRFC 7050で定義され、DNS64[*4]の存在とIPv6・IPv4間の
プロトコル変換に利用されるIPアドレスを検出する際に使われます。RFC 8880
は「ipv4only.arpa」の取り扱いにおいて必要な特別な処理について補足し、
特殊用途ドメイン名[*5]としてIANAに登録します。

[*4] RFC 6147で定義される、AレコードからAAAAレコードを合成するための仕
     組みです。NAT64と組み合わせることで、IPv4アドレスのみを持つサーバー
     へのIPv6ネットワークからのアクセスを実現します。

[*5] Special-Use Domain Names
     https://www.iana.org/assignments/special-use-domain-names/

RFC 8880では、DNS64で使われる特別なIPアドレス「192.0.0.170」と
「192.0.0.171」の、逆引き用のドメイン名「170.0.0.192.in-addr.arpa」と
「171.0.0.192.in-addr.arpa」も、特殊用途ドメイン名としてIANAに登録しま
す。

RFC 8880は、既存のRFC 7050を更新します。

▼DNS-SD/マルチキャストDNSにおけるプライバシーとセキュリティ上の要件
  ・RFC 8882: DNS-Based Service Discovery (DNS-SD) Privacy and
    Security Requirements（Informational、draft-ietf-dnssd-prireq）

RFC 8882は、DNS-SD[*6]/マルチキャストDNSの提供・利用におけるプライバ
シー・セキュリティ上の満たすべき要件について考察し、その情報を提供しま
す。

[*6] RFC 6763で定義される、提供・利用可能なサービスをDNSを用いて発見・
     通知する手法です。

DNS-SDでは、これまでローカルネットワーク上でマルチキャストDNSを用いて
実現していたサービス発見を、広域ネットワークで実施することになります。
RFC 8882では、そのために必要なプライバシーとセキュリティ上の要求仕様、
特に、モバイルデバイスが公共のネットワークでDNS-SDを利用する際の取り扱
いについて考察しています。

▼複数の署名者によるDNSSECの運用モデル
  ・RFC 8901: Multi-Signer DNSSEC Models
    （Informational、draft-ietf-dnsop-multi-provider-dnssec）

RFC 8901は、DNSSECにおいて、あるゾーンに複数の署名者（signer）が存在す
る場合の運用シナリオと鍵管理の要件について考察し、その結果をまとめてい
ます。

この結果を活用することで、DNSSECをサポートする複数のプロバイダーの利用
が可能になり、DNSサービスの信頼性を高めることができます。

RFC 8901では、いくつかのモデルケースが紹介されています。例として、二つ
のプロバイダー間で、KSKとZSKがいずれも独立に管理される場合のモデルケー
スを示します。

  ・それぞれのプロバイダーは、自身のKSKとZSKを持つ。
  ・それぞれのプロバイダーは、ゾーン管理者が他のプロバイダーのZSKを、
    自身のDNSKEY RRsetにインポートするためのAPIを提供する。
  ・DNSKEY RRsetは、それぞれのKSKで個別に署名される。
  ・ゾーン管理者は、それぞれのプロバイダーのKSKに対応するDS RRsetを、
    親ゾーンに登録する。これにより、親ゾーンには二つのプロバイダーのDS
    RRsetが登録される。
  ・鍵の更新において、DS RRset（KSKの場合）とDNSKEY RRset（ZSKの場合）
    を更新するため、ゾーン管理者の協調的な参加が必要である。

▼DNSサーバーにおける、通信の失敗を引き起こす運用上の問題
  ・RFC 8906: A Common Operational Problem in DNS Servers: Failure to
    Communicate
    （Best Current Practice、draft-ietf-dnsop-no-response-issue）

DNSにおいて、サーバーが応答しなかったり不正な応答を返したりした場合、
通信の失敗による、運用上の問題を引き起こします。RFC 8906は、こうした問
題を引き起こし得る問い合わせの種類・やりとりのパターン・運用上の状況に
ついて解説し、運用者が問題を特定して修正する際の手順についても提案しま
す。

▼DNSにおけるエラーコードの拡張
  ・RFC 8914: Extended DNS Errors
    （Standards Track、draft-ietf-dnsop-extended-error）

RFC 8914は、EDNS0[*7]を用いてDNSエラーに関する追加情報を提供するための、
プロトコル拡張の方式を定義します。

[*7] RFC 6891で定義されるDNSの拡張方式で、バージョン番号を示すために
     EDNS0またはEDNS(0)と呼ばれます。詳細については、JPRS用語辞典をご
     参照ください。
     JPRS用語辞典｜EDNS0（イーディエヌエスゼロ）
     https://jprs.jp/glossary/index.php?ID=0147

現在のDNSSECでは検証でエラーが発生した場合、従来の名前解決エラーと同様、
SERVFAILを返します。しかし、SERVFAILはサーバー側で名前解決エラーが発生
したことのみを示しており、その原因を示す追加情報は含まれません。

RFC 8914により、EDNS0を用いてエラーコードを拡張するためのオプションと、
情報を返すための拡張エラーコードが定義され、DNSエラーに関する追加情報を
クライアントに返せるようになります。

▼DNSプライバシーサービスの運用者における推奨事項
  ・RFC 8932: Recommendations for DNS Privacy Service Operators
    （Best Current Practice、draft-ietf-dprive-bcp-op）

RFC 8932は、DNSプライバシーサービスをサポートしたフルリゾルバー（キャッ
シュDNSサーバー）の運用者における、運用・ポリシー・セキュリティ上の推奨
事項について解説・提示します。

RFC 8932では、DNSSECにおけるDPS[*8]に相当する、運用におけるプライバシー
ステートメントの作成を支援するための枠組みも提供します。

[*8] DPS（DNSSEC Practice Statement）
     管理対象ドメイン名におけるDNSSEC運用のポリシー、考え方、手順など
     について網羅的にまとめた文書で、そのドメイン名のDNSSEC運用者が必
     要に応じて作成・公開します。DPS作成のための枠組みは、RFC 6841で定
     義されています。

▼TSIGの仕様修正
  ・RFC 8945: Secret Key Transaction Authentication for DNS (TSIG)
    （Standards Track、draft-ietf-dnsop-rfc2845bis）

RFC 8945は、TSIGの仕様を定義します。

TSIGはDNSの通信（トランザクション）に電子署名を付加し、通信の安全性を
高めるための仕組みです。TSIGを利用することで、ゾーン転送、DNS NOTIFY、
Dynamic Updateなどにおいて通信相手を認証し、通信路におけるデータの改ざ
んを検知できます。

TSIGの仕様は従来、RFC 2845で定義されていました。しかし、2017年に公開さ
れた3件の脆弱性（CVE-2017-3142、CVE-2017-3143、CVE-2017-11104）により、
RFC 2845の仕様を厳密に実装した場合、セキュリティ上の問題が発生すること
が判明しました。RFC 8945は、この問題を修正しています。

RFC 8945は、既存のRFC 2845とRFC 4635を置き換えます。RFC 8945による更新
はセキュリティ上の修正のみであり、RFC 2845に従って作られた実装と、相互
運用性が確保されています。

▼レジストリデータエスクローの仕様
  ・RFC 8909: Registry Data Escrow Specification
    （Standards Track、draft-ietf-regext-data-escrow）

RFC 8909は、ドメイン名レジストリにおけるデータエスクロー[*9]の仕様を定
義します。データエスクローは、ドメイン名レジストリの業務が別組織に移管
されることになった際に、レジストリデータを円滑に移管するための仕組みで
す。

[*9] JPRS用語辞典｜エスクロー
     https://jprs.jp/glossary/index.php?id=0068

gTLDでは、ICANNとの契約によりデータエスクローの履行が義務付けられていま
す。

■dnsop WGにおける話題

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

▼議論された主な提案の内容と作業の進行状況

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

JPRSの藤原和典が第一著者となっている、DNSにおけるIPフラグメンテーション
（断片化）を回避するための提案です。

参加者からは、「フラグメントパケットの差し替えによるDNS応答の偽装を防
ぐことについてはTSIGを利用する別の提案（draft-andrews-dnsop-defeat-
frag-attack）があるため、それに触れるとよい」「TSIGはフルリゾルバーと
権威DNSサーバーの間の通信では普及しておらず、IPフラグメンテーションの
発生を回避する本提案側の筋がよいので支持する」などのコメントがあり、継
続して作業を進めることとなりました。

▽DNSSECによる委任情報の保護
  （draft-fujiwara-dnsop-delegation-information-signer）

JPRSの藤原和典が著者となっている、委任情報をDNSSECで保護する方法を提供
する提案です。

DNSSECでは、親ゾーンに設定される委任情報（NSレコードとグルーレコード）
は、保護の対象になっていません。本提案では、DNSSECの信頼の連鎖を構築す
るためのDSレコードを流用して、委任情報をDNSSECで保護できるようにします。

本発表の中で、DNSSECはなぜ委任情報を保護しない形で標準化されたのかにつ
いて、発表者の藤原が確認を求めました。それに対し、当時dnsext WGの共同
チェアであったOlaf Kolkman氏から、既存のDNSへの変更を最小限に留めるた
めであった旨、説明がありました。

参加者からは、「名前解決対象のドメイン名でDNSSECを有効にしていれば委任
先の検証でエラーになるため、委任情報を保護するメリットはないのではない
か」「すべての委任情報にDSレコードが追加されるため、多数の委任情報を保
持するTLDの権威DNSサーバーのゾーンサイズが増えてしまうのではないか」
「本提案はDSレコードの使い方として参考になった」などのコメントがあり、
継続して作業を進めることとなりました。

▽リゾルバーによる委任情報の再検証
  （draft-ietf-dnsop-ns-revalidation）

リゾルバーが委任元（親）から受け取った委任情報を評価し直し、委任先（子）
の情報を再取得・使用するように名前解決の手順を変更する、プロトコル拡張
の提案です。

委任情報（親のNSレコード）は権威を持たない情報であり、委任先の権威を持
つ情報（子のNSレコード）の内容を優先すべきであると、RFC 2181で定められ
ています。本提案ではこれをより確実に実現するため、委任元から受け取った
NSレコードをそのまま使わず、委任先からNSレコードを取得し直し、その情報
を使って名前解決を実行するように、名前解決の手順を変更します。幽霊ドメ
イン名脆弱性[*10]を防ぐため、NSレコードのTTL値は、親のNSレコードと子の
NSレコードのうち、小さいものが使われます。

[*10] 「ghost domain names（幽霊ドメイン名）」脆弱性について
      https://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html

本提案は、Unboundに「harden-referral-path」として実装されている機能と、
同様の処理内容になります（デフォルトでは無効）。

参加者からは、本提案は名前解決の実装・動作を複雑にするのではないかとい
う懸念が寄せられ、継続して作業を進めることとなりました。

▽プライベート用TLD
  （draft-ietf-dnsop-private-use-tld）

プライベート用TLDとして使えるようにするため、ISO 3166[*11]がユーザー割
り当て用コード（user-assigned codes）としている文字列を明示的に予約する
提案です。

[*11] JPRS用語辞典｜ISO 3166
      https://jprs.jp/glossary/index.php?ID=0144

ISO 3166では、利用者が独自に使ってよい文字列を「ユーザー割り当て用コー
ド」として予約しています。これらの文字列は、TLDとして割り当てられること
はありません。

本提案ではこの特性を生かし、これらの文字列を明示的に予約することで、
RFC 1918で定義されるプライベートIPアドレスと同じように使える、プライベー
ト用TLDを提供しています。提案では、使用を推奨する文字列を一つに特定せず、
それらのいずれかをプライベート用TLDとして使えることのみを示しています。

参加者からは、「このような提案はIETFからではなくISOからICANNにされるべ
きではないか」「同じプライベート用TLD、例えば.zzを家庭内と職場の両方で
使っていた場合、VPNで家庭から職場に接続すると名前衝突が起こるのではな
いか」といったコメントがありました。

後者のコメントに対しては、セカンドレベルドメインにユニークなラベルを指
定することで衝突を回避できるのではないか、というコメントがあり、本提案
は継続して作業を進めることとなりました。

■dprive WGにおける話題

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

当初の目的であった、スタブリゾルバーとフルリゾルバー間の通信のプライバ
シー確保に関する標準化作業は、DNS over TLS（DoT）とDNS over HTTPS（DoH）
の標準化により完了しています。現在、WGでは次の段階として、フルリゾルバー
と権威DNSサーバーの間や、権威DNSサーバー間の通信を暗号化するための作業
が進められています。

▼議論された主な提案の内容と作業の進行状況

▽TLS上でのゾーン転送
  （draft-ietf-dprive-xfr-over-tls）

権威DNSサーバー間のゾーン転送をTLSで保護することで、プライバシーを確保
する提案です。TLSは通信相手の認証も提供するため、DNSの通信に電子署名を
付加して相手を認証するTSIGの機能も実現できます。

本プロトコルはXFR-over-TLS（XoT）と名付けられ、従来のAXFR、差分ゾーン
転送（IXFR）の双方を、AXoT、IXoTとしてサポートします。

参加者からは特に反対意見は出ず、標準化に向けた作業が継続されることとな
りました。

▽フルリゾルバーと権威DNSサーバーの間の通信におけるプライバシーの確保
  （draft-ietf-dprive-phase2-requirements）

フルリゾルバーと権威DNSサーバーの間の通信におけるプライバシーの確保の
ための要求事項に関する検討が集中的に進められました。会合では結論は出さ
れず、継続して議論を進めることとなりました。

現在の提案に記載されている要求事項は、以下の11件です。

  1.  各サーバーにおいて、段階的かつ独立な導入が可能であること

  2.  フルリゾルバーが接続先の権威DNSサーバーについて、暗号化サポート
      の有無を判断できること

  3.  権威DNSサーバーが接続元のフルリゾルバーに対し、暗号化サポートの
      有無を示せること

  4.  既存の権威DNSサーバーを変更することなく、2.をサポートできること

  5.  接続の暗号化はフルリゾルバーと権威DNSサーバーの双方が整合性を検
      証できた場合にのみ行われ、診断のために容易に分析できること

  6.  各サーバーの実装者は、運用者が状況を監視・調査できるように、接続
      の暗号化やその他のDNSプライバシー技術の使用について、調整できる
      ようにすること

  7.  ドメイン名の管理者は、接続の暗号化をするかどうか、する場合にどの
      プロトコルをサポートするか、暗号化を必須とする／暗号化されない接
      続へのダウングレードを可能とするか、といったオプションを指定でき、
      外部に示せること

  8.  ドメイン名の管理者は、権威DNSサーバーごとに暗号化に関する設定を
      変更できること

  9.  権威DNSサーバーは、管理するゾーンごとに暗号化に関する設定を変更
      できること

  10. 暗号化サポートの指定はDNSプロトコルにより実行され、DNS以外のプロ
      トコルに依存しないこと

  11. 暗号化にTLSを使う場合、TLS 1.3またはそれより後のバージョンをサ
      ポートし、それより前のバージョンにダウングレードしないようにする
      こと

■次回のIETF Meetingについて

次回の第110回IETF Meeting（IETF 110）は2021年3月6日から12日にかけ、オ
ンラインで開催される予定となっています。

          ◇                     ◇                     ◇

◎関連URI

  - IETF | IETF 109 Online
    https://www.ietf.org/how/meetings/109/
    （IETF 109公式ページ）

  - IETF 109 preliminary & interim materials
    https://datatracker.ietf.org/meeting/109/materials.html
    （IETF 109発表資料一覧）

  - Domain Name System Operations (dnsop)
    https://datatracker.ietf.org/wg/dnsop/charter/
    （dnsop WG公式ページ）

  - DNS PRIVate Exchange (dprive)
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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), 2020 Japan Registry Services Co., Ltd.