DNS にはいくらかのリスクがあるが、直接的に反射や増幅につながるものではないんだ。それについては EDNS0 メッセージサイズ拡張が誤解の元になっている。俺に説明させてくれ。
身元が確認されていないパケットの交換は、無認証で反射や増幅を利用できる DDoS 攻撃者に悪用されがちだ。例えば (ping に用いられる) ICMP が悪用されやすい。TCP SYN パケット を使うと 40 個までの SYN-ACK パケットをそんなものを要求していない被害者のところへ誘導することができる。もちろん、NTP や SSDP、uPNP そして DNS を含むすべての UDP サービスはこの攻撃に脆弱性がある。
多くの侵入検知、侵入防護、ロードバランサ製品は帯域一杯 (line rate) のトラフィックについていくことができずにボトルネックになる。多くのルータもスイッチもやはり帯域一杯では動作できない。回線の隘路になるこれらのボトルネックたちが、輻輳 DDoS 攻撃の現実のターゲットになる。どこかのファイアウォールを攻撃すれば、回線がまだ帯域一杯でなくとも必要なトラフィックはそこを通り抜けられなくなる。そしてファイアウォールをスローダウンさせるのは (大きなメッセージや EDNS0 や DNSSEC で増大させることのできる) bits per second の総量ではなくて、むしろ packets per second の総量なのだ。
DNSSEC が大きなメッセージサイズであるがゆえ、そしてそれが直感的にいい感じの話であるがゆえに、それは単に間違いなのだが、いかに DNSSEC が DDoS を酷いものにするかという多くの都市伝説が生まれた。しかし、この伝説にわずかな理があるとしても、本当の答えはどこかに他にある。[なぜなら DNSSEC はいつも EDNS0 を使うが、EDNS0 は DNSSEC 以外でも使われうるのだ]。そして DNSSEC 以外の多くの普通の応答は DNSSEC より大きいだろう。SPF ポリシーや DKIM 鍵を応答する TXT レコードをみてみろ。あるいは単にたくさんの Aレコードセットや MX レコードセットもそうだ。攻撃に DNSSEC はいらないし、DNSSEC に DDoS リスクの焦点をあてるのはエネルギーの浪費なんだってば。
そりゃ DNSSEC にはリスクはあるよ! 使うの難しいし、正しく使うのはもっと難しい。DNSSEC はゾーンデータの変更や、登録管理業務や、新しいサーバのインストールなど新しい仕事をしばしば要求する。すべてはちゃんとテストされて文書化されなきゃいけないし、何かまずいことが起きたら DNS や DNSSEC 技術を疑って調べなきゃいけない。そして君がゾーン署名者としてそれらをすべてちゃんとやったとして、たどり着く結論は、君のオンラインコンテンツとシステムは君の顧客にとって余計に脆いものになっているってことだ。末端のサーバ運用者にとって、結論は、誰のコンテンツもシステムも君にとって脆いものになっているだろうってことだ。これらのリスクはしばしば利益に勝る。唯一の利益は DNS データが途中で改ざんされるのを防ぐことだけだからだ。攻撃はその利益を守る努力に甲斐があるほどあるものでもない。俺たちはみんな (訳注: みんなって誰よ?) いつの日か新たな応用に適用されて、DNSSEC がユビキタスになるのを望んでいるんだ。だけれど真実は、今日、DNSSEC は全くのコストであり、利益はなく、高いリスクを孕んでいるってこった。
君が DNSSEC を使いたくないのであれば好きにするがいい。しかし、DNSSEC の問題が DDoS 増幅の役割を持っているからだと思わせれているのはやめろ。DNSSEC は DDoS 増幅の役割を担わせられる必要はない。それにはもっとほかに簡単なよい方法がある。君が DNSSEC を使いたくないのであれば、まだクールエイド (訳注: アメリカ人の好きなジュース) を飲んだことがなくて、最初に動く人じゃなく最後に腰をあげる人になりたいからなんだから好きにするがいいさ。
時に「権威サーバ」と呼ばれる DNS コンテンツサーバは DNS 反射増幅の悪用を防止しなければいけない。なぜなら DNS は UDP を使うし、UDP は送信元偽装パケットで悪用されうるからだ。この手の悪用から君の DNS コンテンツサーバを守る方法は、UDP をブロックしたり、(TC フラグを 1 にするトリックで) TCP を強制したり、ANY query をブロックしたり、DNSSEC を選択しなかったりすることではない。これらは何の助けにもならない。君には BIND や Knot や NSD などいくつかのオープンソースな実装があり完全に自由な技術である DNS Response Rate Limit (DNS RRL) が必要なんだ。君はファイアーウォールでは DNS 反射問題を解決できない。(RRL 付きの) DNS サーバ自身のようなコンテンツアウェアなミドルボックスだけが、リクエストが攻撃か攻撃ではないかを正確に判断することができるのだ。もう一度強く言わせてくれ: DNS RRL はフリーであり、すべての権威サーバはそれを動作させなければいけないんだ。
最後に、俺の偏見をぶちまけさせてくれ。俺は BIND 8 の大部分を書いたし、EDNS0 を発明したし、DNS RRL を共同発明した。俺は 20 歳そこそこの 1988 年から DNS の仕事をしてきて、誤解された問題への中途半端な解決にわずかなわずかな忍耐力しかない小難しい 50 歳そこそこのジジイになってしまった。もしこのメッセージが「この野郎ども、俺のシマから出て行け」(訳注: "hey you kids, get offa my lawn!" アメリカでは知られたフレーズらしい) くらいにしか聞こえなかったら、どうか俺を許してくれ。
