View on GitHub

DNS flag day 2020

English (US) Le Français 日本語 Español 中文（中国）

内容

次回予告

次回の DNS Flag Day は、 2020 年 10 月 1 日に予定されています。 その内容は、 IP パケットのフラグメンテーション (fragmentation) が引き起こす、 運用上のまたはセキュリティの問題に特化したものになる予定です。

問題点、 2020 年 10 月 1 日に予定されている技術的な変更、そして予定日の前にあなたのシステムをテストする方法の全般的な説明が本ページに掲載されています。

計画に関する重要な変更については dns-announce メーリングリスト (英語) を購読する、 または Twitter の @dnsflagday (英語) をフォローすることで受け取ることができます。

確定した日付

2020 年 10 月 1 日

DNS Flag Day 2020

DNS コミュニティは、相互運用性を持続させ、性能に影響を与える問題を解消するために議論を行っています。 これは業界のメーリングリストや、 DNS-OARC 30 のパネルディスカッション (セッションの録画 (英語) と 発表資料 (英語)) といったカンファレンスで行われています。

DNS Flag Day 2020 の計画に関する提案は、 2019 年 10 月に RIPE78 にて CZ.NIC の Petr Špaček 氏と ISC の Ondřej Surý 氏から行われました。 (セッションの録画 (英語) と 発表資料 (英語)) この年は、 IP フラグメンテーションが引き起こす問題にフォーカスします。

IP フラグメンテーションは、現在のインターネットでは正しく動作するか信頼できないものです。 また、 UDP で 大きなサイズの DNS メッセージが送信された際に、転送の失敗を引き起こす原因になりえます。 たとえ IP フラグメンテーションが正しく動作したとしても、セキュリティの面では不十分でしょう。 なぜなら、フラグメントされた DNS メッセージの 一部 を偽装することは理論的に可能であり、 受信側で簡単にそれを検知する方法はないからです。

最近、 Axel Koolhaas 氏 と Tjeerd Slokker 氏 によって発表された論文とプレゼンテーション Defragmenting DNS - Determining the optimal maximum UDP response size for DNS では、 NLnet Labs と共同で RIPE Atlas のプローブを利用して現実世界のデータが調査されました。 その結果として、 IPv4 と IPv6 で、またシナリオ (訳注: スタブリゾルバーとフルサービスリゾルバー) によって異なる値が提案されています。 環境に応じた値に設定することは、環境を把握している運用者にとっては現実的なことですので、 DNS ソフトウェアのデフォルト値としては、最小で安全なサイズである 1232 を反映するべきでしょう。

これらの問題を解決するには、下記の全てを行う必要があります。 a) UDP で送信する DNS メッセージについて、一般的なネットワークリンクでフラグメンテーションが起きないようなサイズに制限するようサーバーを設定する b) DNS 応答のサイズが大きく、前述の制限したバッファーサイズを超えてしまう場合には、 DNS サーバーで UDP から TCP に切り替えられるようにする

メッセージサイズに関する検討

IP フラグメンテーションを避けつつ TCP をなるべく使わないような DNS メッセージサイズの最適値は、 ネットワークのエンドポイント同士をつなぐ物理的なリンクの最大転送単位 (Maximum Transmission Unit: MTU) に依存するでしょう。 残念なことに、 DNS サーバーソフトウェアの実装者がその情報にアクセスできる標準的な仕組みはまだありません。 標準的な仕組みが提供されるようになるまでは、 EDNS バッファーサイズが現在の一般的なネットワークリンクでフラグメンテーションを引き起こさないよう十分に小さなサイズに デフォルトで 設定されていることを推奨します。

1232 バイトの EDNS バッファーサイズは、現在のほぼすべてのネットワークにおいてフラグメンテーションを回避することができます。 この値は IPv6 の仕様で必須とされている 1280 バイトの MTU 値に基づいていて、さらに IPv6 ヘッダーと UDP ヘッダーのために 48 バイトを引いた値です。そして、前述の調査結果にも基づいています。

この推奨値は、より良い情報が得られない場合の デフォルトの 値に関するものであることに留意してください。 運用者の方は、管理しているネットワークがより大きなデータフレームをサポートしていて、 IP フラグメンテーションのリスクがないことが確実であれば、より大きな値を設定しても構いません。 DNS サーバーのベンダーは、カーネルから MTU に関するより良い情報を得られる場合には、 より大きな(または、より小さな)パケットサイズを使っても構いません。

対応: 権威DNSサーバーのオペレーター

権威DNSサーバーの運用者の方は、サーバーが TCP (53 番ポート) での DNS 問い合わせにも応答できるようにすることで、 対応することができます。 TCP/53 をブロックする製品もありますので、 ファイアウォールも忘れずに確認してください 。

加えて、 EDNS バッファーサイズをフラグメンテーションを引き起こさないサイズにネゴシエートするように、 サーバーを設定することも行うべきです。 ここでの推奨値は 1232 バイトです。

権威DNSサーバーは、問い合わせで指定された EDNS バッファーサイズを超える大きさで応答 してはいけません!

お持ちのドメインを下記に入力して “テスト!” をクリックすることで、サーバーを確認することができます。 このテストは ISC の EDNS Compliance Tester を内部で使っていて、それに含まれる edns512udp テストが成功するかを確認しています。 加えて、他のテストで一般的に標準規格に準拠していることを確認しています。

あなたのドメインをテストします


対応: フルサービスリゾルバーのオペレーター

フルサービスリゾルバー (キャッシュ DNS サーバー) 側でも、権威 DNS サーバーで求められていることと同じです。 TCP (53 番ポート) での DNS 問い合わせにも応答すること、そしてフラグメンテーションされないように EDNS バッファーサイズとして 1232 バイトを設定してください。 TCP の DNS に問題がないよう、ファイアウォールも忘れずに確認してください。

そして、これが最も大切なことですが、 フルサービスリゾルバーが切り詰められた UDP 応答 (TC=1 がセットされたもの) を受け取った場合、 TCP で再度問い合わせを行わなければ なりません!

最新情報! このチェッカーは、お使いのブラウザー・システム・ ISP のフルサービスリゾルバーをテストします。 テスト用の権威 DNS サーバーに直接問い合わせるフルサービスリゾルバーが TCP をサポートしている時にだけ名前解決できる URL の画像を読み込むことで確認します。 詳細は、このチェッカーが利用している Check My DNS (英語) をご覧ください。

お使いのフルサービスリゾルバーをテストします


対応: DNS ソフトウェア製品のベンダー

DNS ソフトウェア製品のベンダーとしては、 標準規格に準拠する ことが重要です。 また、一般的なネットワークリンクでフラグメンテーションされないような EDNS バッファーサイズのデフォルト値 (1232 バイト) を設定することも重要です。

関連する標準規格は RFC 7766 、 RFC 6891 section 6.2.3. 、そして RFC 6891 section 6.2.4. などがあります。

この試みの動機については、 IETF のインターネットドラフト intarea-frag-fragile section 6.1 と IETF のインターネットドラフト iab-protocol-maintenance にて解説されています。

テスト方法

ドメインの管理者の方、または権威 DNS サーバーの管理者の方は、 ドメインをテストする Web ベースのツールが公開されています。 対応: 権威DNSサーバーのオペレーター を参照してください。

クライアントやフルサービスリゾルバーの運用者のための Web ベースのテストツールは、 対応: フルサービスリゾルバーのオペレーター を参照してください。

他の方法として、コンソールで下記のコマンドを入力することでもテストできます:

$ dig +tcp @auth_IP yourdomain.example.
$ dig +tcp @resolver_IP yourdomain.example.
$ dig @resolver_IP test.knot-resolver.cz. TXT

上記の DNS 問い合わせはすべて成功するはずです。 また +tcp というオプションなしでコマンドを実行したときと同じ応答が返ってくるはずです。

DNS サービスの提供者の方は、権威 DNS サーバーやフルサービスリゾルバーを下記のように EDNS バッファーサイズのデフォルト値を変更してテストすることができます:

変更前に何の問題もなくサービスできていれば、上記の設定変更を適用しても影響はありません。 TCP で応答していない場合には、一部の問い合わせが失敗するようになるでしょう。

誰が行っているの?

DNS Flag Day の試みは、 DNS のソフトウェアやサービスの提供者からなるコミュニティによって主導されています。 また、 The DNS Operations, Analysis, and Research Center (DNS-OARC) からサポートを受けています。 前述のコミュニティのほとんどは DNS-OARC のメンバーでもあります。

DNS Flag Day に関する技術的な質問については、 dns-operations メーリングリスト (英語) を購読してください。

最新情報を得る

報道関係のお問い合わせについては、 media (at) dns-oarc.net にご連絡ください (英語) 。 件名に “DNS Flag Day” を含めてください。

協力者

FAQ

過去の DNS Flag Day

過去に行われた DNS Flag Day のリストは下記の通りです:

2019 DNS Flag Day は成功裏に終わりました。 名前解決に時間がかかるなどの世界中のインターネット利用者に影響を及ぼす問題に対して、 インターネットコミュニティの参加者は連携して解決に当たりました。 インターネットをより良くするために協調して尽力した全てのオペレーターに対して謝意を表します。

過去に行われた、または将来行われる予定の DNS Flag Day の概要はこの動画などで確認できます。 https://youtu.be/mH_elg9EUWw?t=649 (英語)