第109回IETF Meeting報告

2020年11月16日から20日にかけ、第109回IETF Meeting（以下、IETF 109）が、オンラインで開催されました。新型コロナウイルスの感染拡大を受け、IETFMeetingは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]。

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

前回の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に登録します。

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の提供・利用におけるプライバシー・セキュリティ上の満たすべき要件について考察し、その情報を提供します。

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エラーに関する追加情報を提供するための、プロトコル拡張の方式を定義します。

現在の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]に相当する、運用におけるプライバシーステートメントの作成を支援するための枠組みも提供します。

▼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]の仕様を定義します。データエスクローは、ドメイン名レジストリの業務が別組織に移管されることになった際に、レジストリデータを円滑に移管するための仕組みです。

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

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レコードのうち、小さいものが使われます。

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

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

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

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

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

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

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

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

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件です。

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

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