DNSプロトコルのここ数年のトピック紹介

ANYクエリーに対してRRsetをすべて返すわけではない

2019年1月に「RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」が公開されました。

このRFCでは、DNSレスポンダー（DNSレスポンスを送信するホスト）は、ANYクエリー（クエリータイプANY）に対して利用可能なRRset（リソースレコードセット）をすべて返すのではなく、次のような応答を返せるようになりました。

• すべてのRRsetの中から1個あるいはサブセットを返す。
• HINFOレコードを返す。
• イニシエーター（DNSリクエストを送信するホスト）が欲しい内容を類推して応答を返す。

次の例はフルリゾルバーへの実際のクエリーの例です。応答コードとしてNOTIMP（Not Implemented）が返されています。

$ dig @1.1.1.1 cloudflare.com ANY
中略
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 34873

次の例は権威サーバーへの実際のクエリーの例です。HINFOレコードが返されています。

$ dig +norec +noall +answer @ns3.cloudflare.com. cloudflare.com ANY
cloudflare.com.     3789    IN  HINFO   "RFC8482" ""

また、権威サーバーやフルリゾルバーのソフトウェアではANYクエリーに対して、TCPにフォールバックさせたり、1個のRRsetのみを返したりするようなオプションが用意されているものもあります。

結論としては、ANYクエリーに対しては期待したような回答を必ずしも返すとは限らなくなったということです。そのため、調査のためにANYクエリーを利用すると想定していない応答が返ってきて、調査にならないことがあるので、ANYクエリーを使わない方がよいでしょう。

これに至る経緯は次の通りです。

ANYクエリーはアプリケーション用途としてはqmail以外ではほとんど使われていなく、DNSリフレクション攻撃（DNSリフレクター攻撃、DNSアンプ攻撃）に悪用されることがほとんどです。

そのため、DNSプロバイダーによっては、ANYクエリーに対して、TCPフォールバックさせたり、レートリミットをかけたりしていました。

そのような状況の中で、2015年にCloudflare社がANYクエリーに対してRRsetを返さないようにしました。

• Deprecating the DNS ANY meta-query type (The Cloudflare Blog)

その後、Internet Draftとしても提案され、先に紹介した「RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」が公開されたわけです。

RFC 8482が公開された後に、Cloudflare社のブログでは次のようなエントリーが公開されました。ANYクエリーに対するとてもよいまとめになっているのでご興味ある方はご覧ください。

• RFC8482 - Saying goodbye to ANY (The Cloudflare Blog)

注記: ANYクエリーを利用するアプリケーションとしてはqmailが知られています。対応パッチが当たっていない場合はメール送信に問題がでることがあります。

期限切れになったキャッシュを利用してDNSの耐障害性を向上させる

2020年に「RFC 8767 Serving Stale Data to Improve DNS Resiliency」が公開されました。

DDoS（分散サービス不能）攻撃やネットワーク障害などにより、ドメイン名のゾーンを管理している権威サーバーにアクセスできなくなることがあります。このとき、クライアント端末（PCやモバイルデバイス）が利用しているフルリゾルバーは、そのドメイン名に対するRR（リソースレコード）のキャッシュデータを持っていれば、クライアント端末にキャッシュデータを回答として返します。しかし、キャッシュデータがTTLの期間を過ぎて期限切れになっていたら、権威サーバーにクエリーを行いますが、権威サーバーの応答が無いため、名前解決に失敗します。その結果として、ユーザーはそのドメイン名のサービスを利用できなくなります。

このようなときに、ユーザーがサービスを利用できなくなるのを回避するために、フルリゾルバーが期限切れになったキャッシュデータを利用して回答する手法（serve-stale）をこのRFCは定義しています。 期限切れになったキャッシュデータはすぐに破棄されるわけではないため、このように利用することができるのです。

このRFCに書かれていますが、「stale bread is better than no bread.」（古くなったパンでもないよりまし）ということで、古くなったキャッシュデータでも利用して役に立てようという話です。

ちなみに、パブリックDNSサービスによっては、以前から同様な仕組みが採用されていました。 以前、DDoS（分散サービス不能）攻撃が発生したときに、とあるパブリックDNSサービスに対して攻撃の被害を受けているドメイン名のクエリーを行ったら、TTLが0で回答が返ってきたのを観測したことがあります。

DNS Cookie

2016年に「Domain Name System (DNS) Cookies」が公開されました。

DNS Cookieは軽量なDNSトランザクションセキュリティーの仕組みです。 クライアントとサーバー間のリクエストとレスポンスに、Client CookieとServer Cookieと呼ばれる小さなデータを埋め込むことにより、DNSトランザクションの簡易的な認証を行います。 DNS Cookieを利用することで、DNSアンプ攻撃、DDoS攻撃、キャッシュポイズニング攻撃への限定的な保護機能を提供します。

JPRSの阿波連さんの次の資料の15ページ目からDNS Cookieについての説明が掲載されているので参考になると思います。

• BIND9.9から9.11へ移行のポイント(権威DNSサーバー編) (DNS Summer Day 2018資料) (PDF)

DNS over TCPはいつでも利用できる

2010年に「RFC 5966 DNS Transport over TCP - Implementation Requirements」が公開され、2016年にこれを置き換える「RFC 7766 DNS Transport over TCP - Implementation Requirements」が公開されました。

DNSにおけるTCPの利用は、ゾーン転送とTCPフォールバックのときにのみ利用できるという認識を持っている人も多いかと思います。 しかし、RFC 5966およびRFC 7766において、通常のクエリーの際にもTCPを利用できるようになりました。

プライバシー保護

DNSのプライバシーを保護するためのRFCがいくつか公開されています。

• DNS Privacy Considerations (IETF, 2015年公開)
• DNS Query Name Minimisation to Improve Privacy (IETF, 2016年公開)
• The EDNS(0) Padding Option (IETF, 2016年公開)
• Specification for DNS over Transport Layer Security (TLS) (IETF, 2016年公開)
• DNS over Datagram Transport Layer Security (DTLS) (IETF, 2017年公開)
• Usage Profiles for DNS over TLS and DNS over DTLS (IETF, 2018年公開)
• Padding Policies for Extension Mechanisms for DNS (EDNS(0)) (IETF, 2018年公開)
• DNS Queries over HTTPS (DoH) (IETF, 2018年公開)

この中でも注目を集めているのは、権威サーバーに渡すクエリーの情報を最小限にするQNAME Minimisation、およびスタブリゾルバー（クライアントホスト）とフルリゾルバー間の通信のプライバシーを保護するDNS over TLS (DoT)とDNS over HTTPS (DoH)です。 フルリゾルバーのソフトウェアではこれらの仕様をサポートしているものもあります。また、OSがDoTをサポートし、ウェブブラウザーがDoHをサポートする動きがあり、一部はすでに実装されています。

IIJの其田さんと山口さんによる資料が参考になると思います。

• DNSとプライバシー (DNS Summer Day 2019資料) (PDF)
• DoH/DoT入門 (JPNIC, Internet Week 2019資料) (PDF)
• DoH/DoT Update (DNS Summer Day 2020資料) (PDF)

DNS用語集

2015年に「RFC 7719 DNS Terminology」が公開され、2019年にそれを置き換える「RFC 8499 DNS Terminology」が公開されました。

このRFCはDNS用語集になります。 後述する日本語訳から引用すると次の背景があります。

ドメイン名システム(DNS)は、文字通り何十もの異なるRFCで定義されている。DNSプロトコルの実装者と開発者、及びDNSシステムの運用者に使用される用語は、DNSが最初に定義されて以来数十年の間に時々変化してきた。本文書は、DNSで使用されている多数の用語の定義を単一の文書で与えるものである。

日本語訳がJPRSにより公開されております。

• RFC 8499 日本語訳 (JPRS)

まとめ

DNSプロトコルに関するここ数年のトピックをいくつか紹介しました。

なお、JPRS執筆陣による書籍『DNSがよくわかる教科書』では、1,2年前までの情報もキャッチアップされているので、DNSについて学び直したい人にもお勧めです。上述したDNS CookieやDNSプライバシーについての説明も掲載されています。