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.