朝から昼寝

ITや家計、身近なことの整理

[お知らせ]
当サイトは、2024年1月1日に
新URL(happynap.net)に引っ越しました





このページの内容は、最新ではない場合がありますので、新URLをご確認ください。






当サイトには広告を含みます。"オススメ"として紹介している商品やサービスは、個人的にそう思えたものだけです。
共感、興味をもっていただけるものがあればご利用ください (広告掲載ポリシー)。

DNS over TCP未対応の環境が数%あるらしい

DNS ネットワークサービス 標準、規格、仕様 [IT]

年末年始のAmazon

happy-nap.hatenablog.com

↑ 人気

概要

RFC7766(2016年)にてTCP単独でのDNSクエリ送信が可能(MAY)となりましたが、今後のDNS動向においてもDNS over TCPが重要になりそうです。
本記事は、PAM2022というカンファレンスで採択された論文のうち"Assessing Support for DNS-over-TCP in the Wild"で参考にしようと思った点をまとめておくものです。

本記事の目的

  • DNS over TCPの普及状況を把握する。
  • (参考)TCPコネクション再利用時の競合状態について把握する。


目次

基本

DNS over TCPの位置づけ

DNS over TCPは、53/tcpを使用したDNS通信のことです。
従来、DNS over TCPは主にTCPフォールバックの際に使用されるものでしたが、現在は最初のDNSクエリ送信時点で使用して良いことになっています。

  • RFC7766(2016年)
    TCP単独でDNSクエリを送信して良い(MAY)ことになっています("5. Transport Protocol Selection")。
  • それ以前(RFC1123の6.1.3.2、1989年)
    DNSクエリは最初にUDPで送信されなければならず(MUST)、そのDNSレスポンスがtruncate(TC bitが有効)されていた際にTCPで再問合せすべきとされていました(SHOULD)。このTCPによる再問合せをTCPフォールバックと呼びます。
    あるいは、ほとんど無いと思いますが、個別の合意により全ての通信でTCPを使用して良い(MAY)ことにはなっていました。
  • (RFC5966(2010年)もありますが省略します)

DNSメッセージのtruncate

DNSメッセージのtruncateは、基本的にUDP経由で送信されたDNSメッセージのサイズが512バイトの制限を超える場合に発生します。
このようなメッセージはUDP経由ではやり取りできないので、DNS over TCPや、EDNS0による拡張といった方法が必要です。

  • RFC791 "3.1. Internet Header Format"
    (IPではヘッダ64バイトを含む576バイトまでの通信を保証)
  • RFC1035 "2.3.4. Size limits"、"4.2.1. UDP usage"

あるいは、DNSサーバがリゾルバに対して何らかの理由でTCPによる再問合せをさせたい場合、意図的にTCビットが有効な応答を返すという動作は(プロトコルとしては)あり得ます。

DNSの動向

2022年に発行されたRFC9210(DNS Transport over TCP - Operational Requirements)では、DNS over TCPの重要性について説明されています("3. DNS-over-TCP Requirements")。
DNSメッセージサイズの増加(DNSSEC等)、今後のDNS関連技術の発展、DoS攻撃の緩和策、全てにおいてDNS over TCPは今までと同等かそれ以上に重要とされています。

身近なDNS通信では、DNS over TLS(DoT)、DNS over HTTPS(DoH)の活用が進む中、従来のもの(非DoT、非DoH)と混在するネットワーク環境が形成されつつあります。
このようにDNS通信のパターンが多様化するという意味でも、やはりDNS over TCPは中核的な技術要素の1つと言えるでしょう。
例えば、様々なパターンのDNS通信を分析する場面や、TCPコネクション再利用等について考慮する場面で重要になってくると思われます。

DoTとTCPコネクションの再利用

DoT(RFC7858)では、TCPコネクションの再利用についてはDNS over TCP(RFC7766)に従うべき(SHOULD)と記載があります。

To avoid excess TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver.
…
"Proper management of established and idle connections is important to the healthy operation of a DNS server. An implementor of DNS over TLS SHOULD follow best practices for DNS over TCP, as described in [RFC7766]."
RFC7858 "3.4. Connection Reuse, Close, and Reestablishment"より

RFC7766では、"6.2. Recommendations"の中に、"6.2.1. Connection Reuse"や"6.2.1.1. Query Pipelining"に記載があります。
パフォーマンスやリソース効率の向上のため、1つのTCPコネクションの中で複数のDNSクエリおよびDNSレスポンスをやり取りすることを指しています。

DNS over TCPとセキュリティ

セキュリティ面では、RFC9210ではコネクション指向のDNS通信がセキュリティやプライバシーを向上させる可能性や、その他セキュリティに対する考慮事項についての言及があります。
例えば、UDP-based flooding attacksが近年最も一般的なDNSに対する攻撃手法であるとしつつ、TCPによる短いDNS通信が増えることでIPフラグメンテーション攻撃の可能性があり得るとの記載があります。

Furthermore, there has been research that argues connection-oriented DNS transactions may provide security and privacy advantages over UDP transport [TDNS]. In fact, the standard for DNS over TLS [RFC7858] is just this sort of specification. Therefore, this document makes explicit that it is undesirable for network operators to artificially inhibit DNS-over-TCP transport.
RFC9210 "3. DNS-over-TCP Requirements"より


Historically, operators have been wary of TCP-based attacks, but in recent years, UDP-based flooding attacks have proven to be the most common protocol attack on the DNS. Nevertheless, a high rate of short-lived DNS transactions over TCP may pose challenges.In fact, [DAI21] details a class of IP fragmentation attacks on DNS transactions if the IP Identifier field (16 bits in IPv4 and 32 bits in IPv6) can be predicted and a system is coerced to fragment rather than retransmit messages.
RFC9210 "8. Security Considerations"より

DNS over TCPの普及状況に関する論文

DNS over TCPの普及状況に関し、"Assessing Support for DNS-over-TCP in the Wild(世に出回っている DNS-over-TCP へのサポートの評価)"という論文がありました。
これは、PAM2022というカンファレンスで採択された論文の1つのようです。

著者の1人がAkamaiの従業員のようで、そのためか実際のCDN環境のログ等も含めた広範な調査結果がまとめられています。
以下よりPDFや動画を参照できます。

論文における調査結果からは、以下のような内容が分かります。

  • 数%のリゾルバがTCPフォールバックに対応していない
  • 数%の権威DNSサーバが、TCP経由のDNSクエリに応答しない

詳細は後述します。

詳細

論文の中で参考にしようと思った点

論文を全てきちんと読めた訳ではありませんが、整理しておきたいポイントを記載します。

興味深いのは、実在する10万以上のリゾルバ、1,000万以上のドメイン(の権威DNSサーバ:ADNS)に対する調査を行っている点です。
特に、インターネットに公開されていない組織内のリゾルバに対する調査手法に関しては、迷惑行為にもなり得るようなものも含まれており、色んな意味で参考になります。

※本記事には、論文中の図は転載していないので、詳細については論文自体を参照願います。

調査内容

  • リゾルバに対するTCPフォールバックサポート状況の調査
  • ADNSに対するDNS-over-TCPサポート状況の調査

DNSクエリの一般的な傾向

  • ほぼUDP
    主要CDNにおけるDNSクエリのログのうち、TCPによるものはわずか0.02%
  • ほぼIPv4
    DNSクエリのうち、IPv4とIPv6の比率は11:1

リゾルバに対するTCPフォールバックサポート状況の調査

  • 調査方法
    • オープンリゾルバスキャンによる調査
      どこからでもアクセス可能なリゾルバの振る舞いを調査
    • エンタープライズリゾルバスキャンによる調査
      調査用に加工した電子メールを調査対象リゾルバを有するドメイン宛に送信することで組織内のリゾルバの振る舞いを調査(Fig. 2)
      (後述の"Ethical Considerations"に補足あり)
    • RIPE Atlas経由での調査
      RIPE Atlasとは大規模なインターネット測定プラットフォームのこと

以下、調査結果等に関するポイントです。

  • TCPフォールバックに対応していないリゾルバ
    • 主要CDNのADNSへのクエリの66.2%分のリゾルバを調査し、そのうち2.7%～4.8%(クエリ数ベースで1.1%～4.4%)がTCPフォールバックに対応していない(約3,000～5,000)

TCPフォールバックに対応していないということは、TCPフォールバックが必要となった際(ADNS側がDNS over TCPを強制しようとした場合も含む)に、目的のコンテンツにアクセスできない(その名前解決ができない)ということを意味しています。膨大なトラフィックを扱う環境では、この数%の損失は大きなものになります。

ADNSに対するDNS-over-TCPサポート状況の調査

  • DNS-over-TCPに対応していないADNS
    • 主要CDNにおける名前解決サービスによって扱われているドメインのうち、5%以上のドメインのADNSに対するTCPクエリが失敗(約500,000)
    • 著名Webサイトのドメインでも3%以上でTCPクエリが失敗(35)

TCPによるDNSクエリに応答できないということは、リゾルバがTCP接続のみを使用する方針とした際に、目的のコンテンツにアクセスできない(その名前解決ができない)ということを意味しています。リゾルバの場合と同様、膨大なトラフィックを扱う環境では、この数%の損失は大きなものになります。

競合状態によるTCPパイプラインの失敗

エッジケースとして以下のような現象についての説明があります。

  • "race condition(競合状態)"によりTCPコネクションの再利用(パイプライン)が失敗する動作

    • DNSサーバ側のタイムアウト設定とDNSクライアント側のTCPコネクションの再利用の動作のギャップによる現象
    • 多くのリゾルバはコネクションを再利用しようとするが、多くのADNSは応答送信の直後にコネクションを閉じる(6.2)
    • プロトコルレベルでの解決が必要と考えられる(6.2)

  • 競合状態の発生例(Fig. 9)

    • 1つ目のDNSクエリ/レスポンスをやり取り後、2つ目のDNSクエリがクライアントから送信されサーバに届く前に、サーバがコネクションクローズしてしまうと、2つ目のクエリに対して応答できず、クライアント側は再試行を行うため名前解決完了までに多くの時間がかかってしまう
    • 影響としては、名前解決の遅延(再試行する分、UDPに比べ遅延することになる)

  • 論文内で言及されている"Our ADNS"では、以下の設定

    • (1)新規TCPコネクション開始後、2秒以内にクエリを受信しなければタイムアウト
    • (2)既存TCPコネクションは5秒以内に次のクエリを受信しなければタイムアウト
    • 上記設定はBIND9等のDNSサーバ実装のデフォルト値よりは短いが、RFC7766の推奨には準拠(“it is RECOMMENDED that the default server application-level idle period be on the order of seconds”)

  • EDNS0 edns-tcp-keepaliveオプション(6.1)

    • EDNS0 edns-tcp-keepaliveオプションはRFC7828で定義
    • クライアントからのedns-tcp-keepaliveの通知に基づきTCPコネクションのタイムアウト時間がネゴシエートされ、サーバがそのネゴシエートされた時間よりわずかに長く接続を維持すると、競合状態を軽減できる

  • この問題は、DoT、DoH、DNS-over-QUICにも当てはまる(6.2)

    • DoT、DoH、DNS-over-QUICはDNS-over-TCPから接続再利用ポリシーを明示的に継承する(6.2)
    • (DoTについては前述のとおりRFC7858に説明があるが、DoH、DNS-over-QUICの方は継承に関する仕様が記載されているか不明)

Ethical Considerations(7)

  • 測定による悪影響をできるだけ抑えようとしている点について説明あり

  • エンタープライズリゾルバスキャンによる調査では、論文内に手順が記載されているが、この調査方法は、電子メールを受け取った側の組織にとっては迷惑行為にもなり得る

    • 実際この調査に対して14件の苦情や問い合わせがあった模様