View on GitHub

DNS flag day 2020

English (US) Le Français Nihongo Español 中文(中国)

はじめに(謝辞)

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

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

内容

次回予告

次回の DNS flag day は、現在計画中です。 その内容は、 IP パケットのフラグメンテーション (fragmentation) が引き起こす、 運用上のまたはセキュリティの問題に特化したものになる予定です。

新しい情報については dns-announce メーリングリスト (英語) を購読する、 または Twitter の @dnsflagday (英語) をフォローすることで受け取ることができます。

DNS Flag Day 2020

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

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

IP フラグメンテーション、とりわけ、大きなサイズの DNS メッセージに関するものは、現在のインターネットにおける問題となっています。 フラグメンテーションが正しく動作したとしても、 DNS を保護するには不十分なのです。

これらの問題は、フラグメンテーションが起きないような EDNS バッファーサイズを尊重し、 かつ EDNS バッファーサイズが十分に大きくないときには UDP から TCP に切り替えることを DNS に許容することで解決できます。

注意: まだ確定ではありません

このウェブサイト自身や、 DNS flag day 2020 に関するいくつかの点はまだ作業中です。

いずれにせよ、技術的な要件は明確です。 つまり、オペレーターや開発者は DNS flag day 2020 に向けてテストを行ったり、 システムを修正することで備えておくことができます。

ご意見やご提案をお持ちの方は、 dns-operations メーリングリスト (英語) で行われている議論に参加してください。

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

権威DNSサーバー側では、 TCP (53 番ポート) での DNS 問い合わせにも応答することで、 対応することができます。 ファイアウォールの設定も忘れずに確認して下さい!

加えて、 EDNS バッファーサイズをフラグメンテーションされないサイズに設定することも行うべきです。 推奨値は 1220 バイト近辺になりますが、議論中です。

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

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

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


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

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

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

フルサービスリゾルバーのクライアントのためのテストは現在開発中です。

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

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

関連する標準規格は主に RFC 7766RFC 6891 section 6.2.3. 、そして RFC 6891 section 6.2.4. です。

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

テスト方法

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

クライアントやフルサービスリゾルバーのためのテストツールについては現在作業中です。 準備ができたら、このページで公開する予定です。

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

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

上記の DNS 問い合わせはすべて成功するはずです。 また +tcp というオプションなしでコマンドを実行したときと同じ応答が返ってくるはずです。 DNS サービスの提供者の方は、 TCP (53 番ポート) での DNS 問い合わせに応答するかどうか権威 DNS サーバーやフルサービスリゾルバーをテストし、 必要に応じて下記のように EDNS バッファーサイズのデフォルト値を変更することができます:

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

過去のflag day

過去に行われた flag day のリストは下記の通りです:

誰が行っているの?

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