IETF 標準化動向 [第2弾] ～IETF109からIETF110にかけて DNS関連動向～
tech_team IETF インターネットの技術 他組織のイベントIETF 109以降のDNS関連動向についてお伝えします。これまでご紹介した通り(*1)(*2)、IETF 109および110は、IETF 107、108に引き続き、すべてオンラインによるリモート環境で会合が行われました。
(*1) 第109回IETF報告 [第1弾] 全体概要
https://blog.nic.ad.jp/2020/5612/
(*2) IETF標準化動向 [第1弾] ～IETF109からIETF110にかけて～
https://blog.nic.ad.jp/2021/6393/
IETF 109および110 でも従来通り、DNSに関する複数のワーキンググループ(WG)の会合が行われました。これまでと同様に、DNSの機密性やプライバシーをどのように確保するかを検討するdprive (DNS PRIVate Exchange) WG、複数あるリゾルバーの候補から信頼できるものを選び出す手法などについて検討するadd WG (Adaptive DNS Discovery)などが開催されました。
本稿では、それらの中から、DNSの運用に関するWGであるdnsop WGについてご紹介します。
dnsop WG報告
IETF109-DNSOP-20201117-0500
https://www.youtube.com/watch?v=fCtfE9vr6GQ
dnsop WGでは、前回のIETF108からIETF109までの間に、以下のRFCが発行されました。概要をご紹介します。
- RFC8906
- RFC8901
- RFC8914
- RFC8945
RFC8906 A Common Operational Problem in DNS Servers: Failure to Communicate (BCP)
(DNSサーバの応答において問題が発生しやすいケースとテストパターン)
https://tools.ietf.org/html/rfc8906
DNSはご存じの通り、問い合わせを行い、それに対して応答を返すことで動作するプロトコルです。
そのため、問い合わせに対して応答できなかったり間違った応答をするといったことは、運用上の問題を発生させるだけではなく、将来のDNSプロトコルの発展に対して長期的な障害を引き起こします。
RFC8906は、そうした問題が発生しやすい一般的なケースについて取り上げ、DNSオペレーターが問題を特定し修正するのに役立つ、さまざまなテストパターンが紹介されています。
8.1.1. Is the server configured for the zone?
Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set and without EDNS.
We expect the SOA record for the zone to be returned in the answer section, the rcode to be set to NOERROR, and the Authoritative Answer (AA) and Query/Response (QR) bits to be set in the header; the Recursion Available (RA) bits may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891]. Verify the server is configured for the zone:
dig +noedns +noad +norec soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section expect: flag: aa to be present expect: flag: rd to NOT be present expect: flag: ad to NOT be present expect: the OPT record to NOT be present
RFC8901 Multi-Signer DNSSEC Models (Informational)
(複数のDNSサービスプロバイダーによるDNSSECのための鍵管理の要件や運用)
https://tools.ietf.org/html/rfc8901
今日、複数のDNSサービスプロバイダーを使って権威サーバを運用し、ゾーンを提供することは珍しくありません。
そういった環境にDNSSECを導入する場合、プロバイダーの提供する機能によっては、課題が発生することがあります。例えば、プロバイダーが独自の鍵でDNSSEC署名を行う場合、自前での鍵管理以外に追加の鍵管理方法が必要になります。
RFC8901は、そうした状況でのモデルケースを考察して、鍵管理の要件や運用手法について提案しています。
2.1.1. Model 1: Common KSK Set, Unique ZSK Set per Provider
- The zone owner holds the KSK set, manages the DS record set, and is responsible for signing the DNSKEY RRset and distributing it to the providers.¶
- Each provider has their own ZSK set, which is used to sign data in the zone.¶
- The providers have an API that the zone owner uses to query the ZSK public keys and insert a combined DNSKEY RRset that includes the ZSK sets of each provider and the KSK set, signed by the KSK.¶
- Note that even if the contents of the DNSKEY RRset do not change, the zone owner needs to periodically re-sign it as signature expiration approaches. The provider API is also used to thus periodically redistribute the refreshed DNSKEY RRset.¶
- Key rollovers need coordinated participation of the zone owner to update the DNSKEY RRset (for KSK or ZSK) and the DS RRset (for KSK).¶
- (One specific variant of this model that may be interesting is a configuration in which there is only a single provider. A possible use case for this is where the zone owner wants to outsource the signing and operation of their DNS zone to a single third-party provider but still control the KSK, so that they can authorize and/or revoke the use of specific zone signing keys.)¶
RFC8914 Extended DNS Errors
(EDNS0を使った名前解決時のエラーコードの拡張)
https://tools.ietf.org/html/rfc8914
DNSのエラーは、従来の仕様では、ごく限られた数のステータスを通知することしかできませんでした。
特に、DNSSECを使用している場合、何らかの検証失敗が発生した時には、SERVFAILエラーを応答するのみということになっています。そのため、エラーを受信した側ではエラーの詳細が分かりませんでした。
SERVFAILエラーを受け取っただけでは、サーバの設定不具合なのか、DNSSECによるエラーなのかどうか区別できません。具体的には、DNSSEC検証処理中でSERVFAILエラーを受け取っても、DNSSEC署名されたゾーンの署名鍵がおかしいのか、署名が期限切れしているのか、どのような原因でエラーになったのか把握することができませんでした。
こういった問題はDNSSECに限りません。通常のDNS問い合わせ上のエラーについても同様です。
このような機能の不足を補うため、RFC8914が提案されました。
RFC8914では、EDNS0の拡張オプションを用いて、これまでよりも詳細なエラーを通知できるようにするものです。これにより、エラーを受け取ったクライアントは、エラーの状況を細かく判別できるようになります。
The “Extended DNS Error Codes” registry is a table with three columns: INFO-CODE, Purpose, and Reference. The initial content is as below.¶
Table 3 INFO-CODE Purpose Reference 0 Other Error Section 4.1 1 Unsupported DNSKEY Algorithm Section 4.2 2 Unsupported DS Digest Type Section 4.3 3 Stale Answer Section 4.4 and [RFC8767] 4 Forged Answer Section 4.5 5 DNSSEC Indeterminate Section 4.6 6 DNSSEC Bogus Section 4.7 7 Signature Expired Section 4.8 8 Signature Not Yet Valid Section 4.9 9 DNSKEY Missing Section 4.10 10 RRSIGs Missing Section 4.11 11 No Zone Key Bit Set Section 4.12 12 NSEC Missing Section 4.13 13 Cached Error Section 4.14 14 Not Ready Section 4.15 15 Blocked Section 4.16 16 Censored Section 4.17 17 Filtered Section 4.18 18 Prohibited Section 4.19 19 Stale NXDomain Answer Section 4.20 20 Not Authoritative Section 4.21 21 Not Supported Section 4.22 22 No Reachable Authority Section 4.23 23 Network Error Section 4.24 24 Invalid Data Section 4.25 25-49151 Unassigned 49152-65535 Reserved for Private Use Section 5.2
RFC8945 Secret Key Transaction Authentication for DNS (TSIG)
(ゾーンの更新に使うことのできる共有シークレットを使ったデータ認証)
https://tools.ietf.org/html/rfc8945
DNSは、平文での通信を行います。しかし、ゾーン転送や動的更新の仕組みであるDynamic Updateなどを使用する場合、通信相手を確認・認証したい状況があります。そういった状況で用いられるのがTSIGです。TSIGを用いることで通信相手を限定し、さらに通信経路途中での改ざんが検知できるようになります。
TSIGはRFC2845で標準化されており広く用いられてきましたが、2017年に脆弱性があることが発表されました(*3)。
その脆弱性を修正するため提案されたのが、このRFC8945です。
(*3) CVE-2017-3142 , CVE-2017-3143, CVE-2017-11104
1.2. Protocol Overview
Secret Key Transaction Authentication makes use of signatures on messages sent between the parties involved (e.g., resolver and server). These are known as “transaction signatures”, or TSIG. For historical reasons, in this document, they are referred to as message authentication codes (MACs).¶
Use of TSIG presumes prior agreement between the two parties involved (e.g., resolver and server) as to any algorithm and key to be used. The way that this agreement is reached is outside the scope of the document.¶
A DNS message exchange involves the sending of a query and the receipt of one of more DNS messages in response. For the query, the MAC is calculated based on the hash of the contents and the agreed TSIG key. The MAC for the response is similar but also includes the MAC of the query as part of the calculation. Where a response comprises multiple packets, the calculation of the MAC associated with the second and subsequent packets includes in its inputs the MAC for the preceding packet. In this way, it is possible to detect any interruption in the packet sequence, although not its premature termination.¶
The MAC is contained in a TSIG resource record included in the additional section of the DNS message.¶
dnsop WGで議論された継続中のInternet Draft (I-D)
本会合で議論された、継続中のWG Documentは以下の通りです。概要について紹介します。
- Delegation Revalidation by DNS Resolvers
draft-ietf-dnsop-ns-revalidation - Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
draft-ietf-dnsop-rfc5933-bis - Top-level Domains for Private Internets
draft-ietf-dnsop-private-use-tld - Fragmentation Avoidance in DNS
draft-ietf-dnsop-avoid-fragmentation
Delegation Revalidation by DNS Resolvers
https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-delegation-revalidation-00
本提案は、DNSの反復的名前解決の際に、権威サーバから子ゾーンへの参照(referral)を受け取った際の処理を、厳密にしようというものです。
これまでは、委任情報は権威のある子ゾーンのNSレコードが優先されるというものでしたが、仕様にあいまいな部分もありました。本提案では、明示的に子ゾーンへNSレコードを問い合わせ、その情報を用いて名前解決をしようというものです。
会場では、実装が複雑になるため導入したくないという意見や、上述のExtended DNS Errorsに取り入れてはどうかという意見がありました。結論として議論継続となりました。
Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-russian-gost-profile-for-dnssec-00
本提案は、DNSSECの署名アルゴリズムに、GOST R 34.10-2012およびGOST R 34.11-2012を導入しようという提案です。
GOST R 34.10-2012およびGOST R 34.11-2012は、それぞれRFC7091、RFC6986で標準化されていますが、DNSSECのDNS Security Algorithm (*4)には取り入れられていません。これを開発者向けに事例を紹介することで、実装を促し導入をスムーズにして、旧来のGOST R 34.10-2001を置き換えようとするものです。
会場では実装の普及度合いについて質問があり、それに対してOpenSSLやLinux kernelなどで採用事例があるため問題ないとの提案者からの回答がありました。結論としては議論継続となりました。
(*4) DNS Security Algorithm
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
Top-level Domains for Private Internets
https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-private-tld-00
現在、DNSの名前空間には、プライベート目的のドメインは存在しません。しかし、プライベートでの利用を目的としたドメインを使いたいという要望や実装がすでに存在しており、現状では一部で名前衝突が起きかねない状態になっています。
そのような問題を解決するため、プライベート目的のドメインとして利用できるように、ISO 3166で定義されているいくつかの “user-assigned code”(*5) を、明示的にTLDとして予約しようという提案です。
(*5) Glossary for ISO 3166
https://www.iso.org/glossary-for-iso-3166.html
会場からは、そのようなドメインの利用目的についてはポリシーに関する話であり、国際標準化機構(ISO)とICANNの間で話し合うべきであるといった意見がありました。また、提案が採用されたとしても、名前衝突が発生する可能性があるといった懸念もコメントとしてありました。本提案は継続議論となりました。
Fragmentation Avoidance in DNS
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-avoid-fragmentation-01
株式会社日本レジストリサービス(JPRS)の藤原和典氏により、DNSにおけるIPフラグメンテーションを回避するための提案についての発表がありました。
会場からは、フラグメント攻撃をTSIGで防御する手法が別に提案されているが、それに触れた方が良い、IPv6でのフラグメンテーションに対して効果があるのか？ などのコメントや意見がありました。結果として継続議論となりました。
新規の WG document
今回新しくWG documentとなったI-Dは以下の通りです。
- draft-hoffman-dnssec-iana-cons
- draft-bretelle-dnsop-recursive-iprange-location
- draft-reddy-dnsop-error-page
Revised IANA Considerations for DNSSEC
https://datatracker.ietf.org/doc/draft-hoffman-dnssec-iana-cons/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-iana-considerations-00
DNSSECに関わる多くのRFCにおいて、採用する技術や手法が”Standards”であることや、RFCとして標準化されていること(“RFC required”)を要求しています。しかし、そういった基準がはたして適しているのか、導入の障壁になっていないかどうかという問題提起のdraftです。
たとえば、DS レコードで使用するアルゴリズムは”standard required”となっていますが、上記でご紹介したdraft-ietf-dnsop-rfc5933-bisはまさしくDSレコードに新規のアルゴリズムを追加しようという提案であり、この問題に該当します。会場では、I-Dの見直しが必要であるという意見などが出ましたが、結論は出ませんでした。
Recursive Resolvers IP Ranges location distribution and discovery
https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-resolver-ip-ranges-01
問い合わせ元のIPアドレスによって、応答を変化させる技術があります。DNSでも、権威サーバの応答する内容を、問い合わせ元に合わせて変更させることがあります。それをより具体的に、フルリゾルバの位置(IPアドレスのレンジ、国や地域など)を、権威サーバに対して通知する機能を追加しようという提案です。会場からは、通知に使用するレコードが適切ではない、EDNS Client Subnet (*6)との整合性を考慮すべきであるとのコメントがありました。
(*6) インターネット用語1分解説～EDNS Client Subnetとは～
https://www.nic.ad.jp/ja/basics/terms/edns-client-subnet.html
DNS Access Denied Error page
https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
https://datatracker.ietf.org/meeting/109/materials/slides-109-dnsop-sessa-dns-access-denied-error-page-00
DNSフィルタリングは、セキュリティやペアレンタルコントール、法的機関からの要請などに用いられます。しかし現状では、フィルタによってブロックされた結果は、エンドユーザーにとって原因の良くわからないエラーとして通知されます。例えば、マルウェア感染が疑われるサイトにアクセスした際にブロックされたとしても、エンドユーザーの閲覧しているWebブラウザには、ドメイン名が存在しない、証明書の不一致などのエラー表示が行われます。
それを緩和するため、ブロッキングでのアクセス拒否なのか、単なるDNSやWebサーバ等の問題なのか判別できるように、DNSの応答メッセージにエラーになった原因の情報を含めようという提案です。
会場からのコメントは、まずはExtended DNS Errorsの実装を進めるべきである、EDNS0は通信経路の途中で変更される可能性がある、などのコメントがありました。
(著者コメント)
過去何年もの間、DNSの存在を前提としたさまざまな技術が提案・実装されています。そのため、DNSの安定的な運用が求められるとともに、その重要性は日々高まっています。特に、今回取り上げたRFCとなった仕様のうち、重要なものとなりそうなものとして、RFC8914 Extended DNS Errors (EDE)を挙げたいと思います。
これまでアクセス不能となる原因がどのようなものであっても、「サーバが見つかりませんでした」「証明書が無効です」のようなあいまいな通知内容だったものが、エンドユーザーへもう少し分かりやすいエラー内容を伝えることが可能になることが期待されるためです(*7)。また、DNSに依存するプロトコルはいくつも存在します。それらのエラー内容も伝えることが EDE によって可能になるかもしれません。それらの技術とDNSプロトコルが協調することで、より使いやすいインターネットになるのではないかと想像します。
(*7) 関連して、さっそく上記でご紹介した DNS Access Denied Error page のようなI-Dが提案されています。
IETF 110 での dnsop WG 報告
ここからは、IETF110のdnsop WGで行われたトピックについてご紹介します。
IETF110-DNSOP-20210311-1430 – YouTube
https://www.youtube.com/watch?v=zVLjC53zGV0
上記のIETF109からIETF110までの間に、以下のRFCが発行されました。概要をご紹介します。
RFC 8976 Message Digest for DNS Zones
https://datatracker.ietf.org/doc/html/rfc8976
RFC 8976は、ゾーン全体のハッシュ値を表すZONEMDと呼ばれる新しいリソースレコードを定義し、ゾーン転送やその他の方法でゾーン情報を受け取った受信者が、DNSSECと併せてそのゾーン情報の正当性や正確性を確認できるようにするものです。なお、DNSSECを用いない場合はチェックサムとして機能し、データの整合性のみが確認できます。
IETF110で議論されたドラフトは以下の通りです。この中からいくつかピックアップしてご紹介します。
- draft-ietf-dnsop-dns-catalog-zones
- draft-ietf-dnsop-dnssec-iana-cons
- draft-ietf-dnsop-avoid-fragmentation
- draft-hardaker-dnsop-nsec3-guidance
- draft-wisser-dnssec-automation
- draft-reddy-dnsop-error-page
- draft-arends-dns-error-reporting
- draft-arkko-dns-confidential
- draft-ietf-opsawg-mud-iot-dns-considerations
draft-ietf-dnsop-dns-catalog-zones
ゾーンの追加や削除は、ゾーンを提供するプライマリサーバおよびゾーン転送を受けるセカンダリサーバの双方で、それぞれでゾーンの設定変更が必要になります。その設定変更は作業が繁雑になったり、オペレーションミスにより障害が発生したりする原因になります。
この提案では、プライマリサーバがどのようなゾーンを提供しているか「カタログ」を表明できるようにして、ゾーンの追加・削除の作業を簡易化、さらに自動化できるようにしようとする提案です。
会場での議論では、カタログが変更された際の通知方法や、カタログのサイズの増大時への実装方法についてコメントがあり、継続議論となりました。
draft-ietf-dnsop-dnssec-iana-cons
上記 IETF 109でも議論になったドラフトの継続議論が行われました。新しい暗号アルゴリズム等、別途議論すべきというコメントなどが会場からありました。特に反対意見も無く、WG Last Callが呼びかけられました。
draft-ietf-dnsop-avoid-fragmentation
上記 IETF 109でもご紹介しました、株式会社日本レジストリサービス(JPRS)の藤原和典氏による、DNSにおけるIPフラグメンテーションを回避するための提案です。
IETF 110ではDNSで推奨されるUDPのパケットサイズについて議論が行われました。候補としては 1220、1232、1400などが上げられました。
会場からは特定の値を選択するのはおそらく不可能であろう、ネットワーク環境ごとによりよい値を選べるようサイズの範囲を提案してはどうか、などの意見が出されました。結果として継続議論となりました。
draft-hardaker-dnsop-nsec3-guidance
DNSSECにおいて、「存在しないレコード」を表明するNSEC3レコードについて、その導出方法に関する提案です。
NSEC3はRFC 5155で標準化されており、そこではハッシュ値の繰り返し計算回数の最大値を鍵長に合わせて150～2500回としています。本提案では、計算の負荷が大きすぎると言うことで最大回数を100回程度にしようという提案です。
会場からは、制限を超えたエラーはSERVFAILではなく署名なしの状態として取り扱うとよい、最大100回というのは適切であるのか、などのコメントがありました。
draft-reddy-dnsop-error-page
上記 IETF 109でご紹介したドラフト、draft-reddy-dnsop-error-pageの継続議論です。
DNSサーバーがフィルタリングなどによりクエリを遮断した場合、そのクエリがなぜブロックされたのかという理由がエンドユーザーには伝わらないため混乱を引き起こします。そういったユーザーに対して利便性を高めるため、エラー内容を通知しようという提案です。
会場からは、機能としてcaptive portalと同等であり、ブラウザベンダーと協調して議論すべきである、DNSOP WG以外でも意見を聞くべきである、などのコメントがありました。
(著者コメント)
前回のIETF 109に引き続き、DNSの運用上の問題解決を目的とした提案に加え、エンドユーザに対するエラー通知を改善しようとする提案がありました。現在、残念ながらexpireしてしまったためご紹介しませんでしたが、draft-arends-dns-error-reportingという、権威サーバ・キャッシュサーバ間でエラー内容を通知する提案も行われました。DNS運用者だけではなく、エンドユーザーにとってもDNSをより使いやすくする仕組みを取り入れようと、課題を洗い出し解決する手法について日々取り組みが行われています。