第112回IETF Meeting報告

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

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

• オンライン会合の開催に関する話題
  - 開催の状況
  - 全体会議の日程移動
• IETF 111以降に発行されたDNS関連のRFC
  - TLSのDNSSECチェーン拡張（RFC 9102）
  - DNSのクラスとリソースレコードタイプのためのYANGタイプ（RFC 9108）
  - arpaトップレベルドメインのルートからの分離（RFC 9120）
  - QNAME minimisationの仕様の更新（RFC 9156）
  - DNSSECにおけるIANAに関する考慮点の改訂（RFC 9157）
• dnsop WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• dprive WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• add WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• 次回のIETF Meetingについて

▼開催の状況

前回に引き続き、今回のIETF 112もフルアジェンダの形でオンライン開催され、世界各地から1,300人以上が参加しました。会合の時間は、当初の開催予定地であったスペインのマドリードの時間帯（UTC+1）を基準にしてスケジュールされました。

▼全体会議の日程移動

今回のIETF 112では会議に先立ち、全体会議（Plenary）の日程を本会議の前の2021年11月3日に移動する旨が発表されました[*1]。

その理由として、オンライン開催では1日のミーティング時間が短く、スケジュールが競合しやすくなるため、時間の長い全体会議を本会議と別日程とすることで、スケジュールを確保しやすくするためである旨が示されています。

前回のIETF 111以降に発行された、DNS関連のRFCの内容をご紹介します。

▼TLSのDNSSECチェーン拡張

• RFC 9102: TLS DNSSEC Chain Extension
  （Experimental: draft-dukhovni-tls-dnssec-chain）

RFC 9102は、TLSAレコード[*2]のDNSSEC検証に必要な情報を、TLS[*3]のオプションとして提供するためのプロトコル拡張です。なお、本RFCはIETFのWGで標準化されたものではなく、実験（Experimental）仕様となっています。

本RFCでは、DS・DNSKEY・RRSIGなど、DNSSEC検証に必要なリソースレコード（以下、RR）の情報をWebサーバーからクライアントにまとめて送付することで、DNS問い合わせをすることなく、TLSAレコードのDNSSEC検証を実現するための仕様を定義しています。

▼DNSのクラスとリソースレコードタイプのためのYANGタイプ

• RFC 9108: YANG Types for DNS Classes and Resource Record Types
  （Standards Track、draft-ietf-dnsop-iana-class-type-yang）

RFC 9108は、DNSのRRをデータモデリング言語YANG（ヤン）で取り扱うためのモジュール「iana-dns-class-rr-type」を導入します。

YANGは構成と状態データをモデル化し、機器の操作や非同期通知の形式を指定可能にすることで管理を支援するための言語で、RFC 7950で定義されています。当該モジュールを導入することでDNSのRRをYANGで取り扱うことが可能になり、権威DNSサーバー、リゾルバー、ゾーンデータの設定・管理に、YANGを活用できるようになります。

▼arpaトップレベルドメインのルートからの分離

• RFC 9120: Nameservers for the Address and Routing Parameter Area("arpa") Domain
  （Informational、draft-iab-arpa-authoritative-servers）

RFC 9120は、ルートサーバーで管理されているarpaゾーンをルートサーバーから分離することについて定めています。本RFCはarpaゾーンを管理するIAB[*4]が、今後の方針として公開したものです。

arpaはARPANET[*5]からの移行用のTLDとして、1985年に創設されました。その後、2001年に発行されたRFC 3172で、通信プロトコルの内部で使われるインフラストラクチャドメインとして再定義されました。

本RFCではarpaゾーンを管理する権威DNSサーバーをns.arpaゾーン内にa.ns.arpa、b.ns.arpa...という形で準備し、arpaゾーンの管理をルートサーバーから分離することで、ルートサーバーの管理ポリシーに影響されない形でarpaゾーンを管理可能にする旨の方針を定めています。

本RFCはarpaゾーンの管理ガイドラインを定めた、RFC 3172を更新します。

▼QNAME minimisationの仕様の更新

• RFC 9156: DNS Query Name Minimisation to Improve Privacy
  （Standards Track、draft-ietf-dnsop-rfc7816bis）

RFC 9156は、QNAME minimisationの仕様を定義します。QNAME minimisationはプライバシー保護の観点から、フルリゾルバー（キャッシュDNSサーバー）の名前解決アルゴリズムを変更するための仕組みです[*6]。

QNAME minimisationの最初のバージョンは、2016年にRFC 7816として公開されました。本RFCは実験（Experimental）仕様となっていたRFC 7816を置き換え、標準化過程（Standards Track）として再定義します。

QNAME minimisationは、既に主要なフルリゾルバーやパブリックDNSサービスでサポートされ、標準で有効にされています。本RFCではこれまでの運用から得られた知見を反映する形で、DNS問い合わせにおける推奨事項が一部変更されています。

▼DNSSECにおけるIANAに関する考慮点の改訂

• RFC 9157: Revised IANA Considerations for DNSSEC
  （Standards Track、draft-ietf-dnsop-dnssec-iana-cons）

RFC 9157は、DNSSECにおけるIANAに関する考慮点（IANA Considerations）の内容を改訂し、これまでStandards Track（標準化過程）RFCの発行が必要であったDSレコードとNSEC3[*7]で使われるハッシュアルゴリズムの割り当てを、それ以外のRFCの発行においても可能とします。これにより、これらの割り当て要件と、他のDNSSECアルゴリズムの割り当て要件の間の差異を解消します。

RFC 9157はNSEC3不在証明を定義したRFC 5155、DNSSECの暗号アルゴリズムの割り当てを定めたRFC 6014、及びDNSSECの暗号アルゴリズムの実装要件と使用ガイドラインを定めたRFC 8624を更新します。

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

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

▽DNSを使った検証方式の調査
（draft-sahib-domain-verification-techniques）

DNSを使った管理権限の検証方式に関する調査結果と、利用時の推奨事項をまとめた提案です。

DNSを使った検証方式は、独自ドメイン名を用いたサーバー証明書の発行やホスティングサービスの設定など、サービス提供者が利用者のドメイン名に関連付けるサービスを提供する際、利用者がそのドメイン名の管理権限を有しているかの確認に使われます。

具体的には、利用者が自分のドメイン名の権威DNSサーバーにサービス提供者が指定した検証用RR（TXT・CNAME）を追加・編集し、サービス提供者がそれを確認することで、ドメイン名の管理権限を検証します。本提案の推奨事項として、複数の検証用RRがゾーン頂点に設定されることでDNS応答が大きくなるのを避けるため、サービスごとに特定のprefixed names[*8]を使うことと、信頼性向上のためDNSSECを適用すべきである旨を挙げ、今後、検証用のRRの公開期間に関する検討を進める予定である旨が発表されました。

WGでは「本提案は重要なので進めるべき」という意見や「提案がターゲットとする層を明確にするのがよい」というコメント、「協力者として一緒に作業を進めたい」という申し出などがあり、継続して作業を進めることとなりました。

▽NSEC3パラメーター設定のガイダンス（draft-ietf-dnsop-nsec3-guidance）

DNSSECのNSEC3による不在証明について、現在の運用状況に基づくNSEC3パラメーターの設定に関するガイダンスを提供する運用方式の提案です。本提案は過去のdnsop WGでも議論されています[*9]。

NSEC3では外部からゾーン列挙[*10]をしにくくするため、ハッシュ計算を繰り返し実行します。提案では、繰り返し回数が多い場合にフルリゾルバーのパフォーマンスが低下し、名前解決に影響を及ぼす可能性があることを懸念し、権威DNSサーバーとフルリゾルバーの設定・動作について、以下を推奨する旨が発表されました。

• 権威DNSサーバーで設定する繰り返し回数の推奨値を0（繰り返さない）とし、ソルト[*11]は値を毎回変更する場合にのみ設定する
• フルリゾルバーでDNSSEC検証を実施する繰り返しの最大数を100とし、100を超える場合はDNSSEC検証を実施せず、101から500までは安全ではない（Insecure）と扱い、501以上は攻撃とみなしSERVFAILとして扱う

WGでは「信頼の連鎖が構築されているのにInsecureやSERVFAILとして扱うのは、かえって安全性を損なうのではないか」というコメントがあり、継続して作業を進めることになりました。

▽DNSフィルタリングされた理由を利用者に伝える仕組み
（draft-wing-dnsop-structured-dns-error-page）

管理者のポリシーによってDNSフィルタリングされた理由を、利用者に伝える仕組みを定義するための提案です。

DNSフィルタリングは、セキュリティ上の理由やペアレンタルコントール、執行機関からの要請など、さまざまな理由で実施されることがあります。本提案ではEDNS0[*12]を使い、フィルタリングされた理由と詳細情報を取得するためのURIを、利用者に伝える仕組みを提供します。

WGでは「エラー情報の提供方法としてWebアクセスが前提となっているが、アプリケーションはWebに限らないのではないか」というコメントや「フィルタリングを支援する仕様を標準化することは、検閲に協力することになるのではないか」という懸念のコメント、それに対し「何をなぜフィルタリングしたかを利用者に開示する『よい検閲』を支援するため、この仕組みが必要なのではないか」などのコメントがあり、継続して作業を進めることとなりました。

▽DNSカタログゾーン（draft-ietf-dnsop-dns-catalog-zones）

権威DNSサーバーに設定するゾーンの設定情報をゾーンファイルの形で配布できる「カタログゾーン」の仕様を定義する、機能拡張の提案です。

カタログゾーンとして設定情報を管理・配布することで、複数の権威DNSサーバーへのゾーンの追加・削除やゾーン情報の変更を、DNSソフトウェアの実装によらない形で管理できます。カタログゾーンは当初BINDに実装され、現在では複数のDNSソフトウェアでサポートされています[*13]。

WGでは、カタログゾーンを設定するドメイン名について「arpa配下に作成するのがよいのではないか」というコメントや、それに対し「専用のTLDがよい」「自身のドメイン名のサブドメインとするのがよい」などのコメントがありました。

カタログゾーンには既に複数の実装と運用実績があり、大まかな仕様も固まっているため、細部が合意された時点で、ワーキンググループラストコール（WGLC）が実施される見込みです。

dpriveはDNS PRIVate Exchangeに由来しており、通信の暗号化によってDNSトランザクションにおける機密性（confidentiality）を提供し、プライバシーを確保することを目的としています。

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

最近のdprive WGではフルリゾルバーと権威DNSサーバー間の通信の暗号化について、継続的な議論が進められてきました。現在、WGでは暗号化に用いるサーバー証明書の検証方法、フルリゾルバー側での暗号化の有無の検出方法、権威DNSサーバー側でのサーバー証明書の情報の設定方法など、本件に関するさまざまな課題の検討が進められています。

▽暗号通信が可能かをフルリゾルバー側から検出・記憶する仕組み
（draft-dkgjsal-dprive-unilateral-probing）

権威DNSサーバーとの通信時に暗号通信が可能かをフルリゾルバー側から検出・記憶することで、暗号化による名前解決の遅延や悪影響を最小限に留めることを目的とした提案です。

提案では、名前解決の際に通信先の権威DNSサーバーが暗号通信に対応しているかをフルリゾルバー側から検出し、暗号通信ができた場合はその方式、できなかった場合はその事実を権威DNSサーバーのIPアドレス単位で記憶することで、opportunistic（日和見）[*14]方式を用いた、より簡便な暗号化方式への対応を図っています。

WGでは、フルリゾルバー側の記憶はIPアドレス単位ですることになっているが、サーバー証明書の検証は本来ネームサーバーホスト名単位であるため、整合性がとれないのではないかというコメントがあり、継続して作業を進めることになりました。

▽DSレコードによるグルーの提供
（draft-schwartz-ds-glue、draft-dickson-dnsop-ds-hack）

DNSSECの信頼の連鎖の構築・検証に用いるDSレコードを拡張し、フルリゾルバーと権威DNSサーバーの間の通信の暗号化に必要な情報を、親ゾーンに登録・設定可能にするための提案です。本提案は、既存のDNSやドメイン名登録システムへの影響を最小限に留めながら、フルリゾルバーと権威DNSサーバーの間の通信の暗号化を実現することを目的としています。

親ゾーンに登録・設定される委任情報（NSレコード・グルーレコード）は権威を持たない情報であり、DNSSECでは保護されません。そのため、本提案では権威を持つ情報として親ゾーンに登録されるDSレコードにこれらの情報をエンコードして格納できるようにし、DNSSECで保護されるようにします。

現在、WGでは本件に関する複数の方式が提案・比較検討されている段階であり、合意形成には至っておらず、標準化には今後かなりの期間を要することが予想されます。

addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プライベートネットワーク・VPNを含むさまざまなネットワーク環境において、DNSクライアントがリゾルバーを発見・選択するための技術的な仕組みの作成を目的としています。

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

▽リゾルバーの構成を検出するための仕組み
（draft-ietf-add-ddr）

クライアントがDNS経由で暗号化リゾルバー[*15]の構成を検出する仕組みである「Discovery of Designated Resolvers（DDR）」を定義する提案です。

WGでは前回からの変更点として、構成の検出に使用するSVCBレコードの内容・参照を最新の提案に合わせて更新したこと、クライアントがDDR以外の方法で暗号化リゾルバーを検出可能である旨の記述を追加したこと、使用する用語を一部変更したことなどが発表され、現時点における残課題の内容が共有・議論されました。

本提案は残課題の解決後にWGLCが実施され、IESGに送付される見込みとなっています。

▽DNSフォワーダー経由でのDDR（draft-schwartz-add-ddr-forwarders）

DDRによる暗号化リゾルバーの検出について、クライアントとフルリゾルバーの間にDNSフォワーダーが存在する場合の問題点の指摘と、問題解決のために取りうる緩和策に関する情報をまとめた提案です。

一般的なホームルーターにはDNSフォワーダーの機能が実装されており、広く普及しています。これらのDDRを認識して実装されていないレガシーDNSフォワーダーは、DNS問い合わせ・応答を転送する際、送信元のIPアドレスを自らのものに付け替えます。

一方、DDRによる暗号化リゾルバーの検出ではその暗号化リゾルバーのサーバー証明書の検証が必要であり、レガシーDNSフォワーダーによってIPアドレスが書き換えられた場合、サーバー証明書の検証に失敗します。そのため、レガシーDNSフォワーダー経由で動作するクライアントは、DDRによる暗号化リゾルバーの検出を利用できないことになります。

WGでは、数多くの利用者がレガシーDNSフォワーダー経由でインターネットを利用しており、現在のDDRではそれらの利用者をカバーできないことが懸念されること、コンシューマー向けのホームルーターは長期間にわたって使われる場合が多く、状況の改善には長い時間を要することが問題点として指摘され、継続して議論を進めることとなりました。

▽暗号化リゾルバーを検出するためのDHCP及びIPv6 RAのオプション
（draft-ietf-add-dnr）

クライアントが暗号化リゾルバーをローカルネットワーク内で検出できるようにするため、DHCPv4/v6、及びIPv6 RAに新しいオプションを定義する、プロトコル拡張の提案です。

今回のWGでは、IETF 110・111[*16]までに仕様に関する議論がほぼ終了し、関連文書であるDDRも残課題の解決後にWGLCが実施される見込みとなったことから、WGLCが実施される予定である旨が発表されました。

次回の第113回IETF Meeting（IETF 113）は、2022年3月19日から25日にかけて開催される予定です。

IETF 113は新型コロナウイルス感染症の状況から、当初予定のタイのバンコクでは開催できず、オンサイトの参加者比率を50%と想定した別の開催地を検討中であり、今年中に決定予定である旨が発表されています[*17]。

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