DNSSECは、複雑なトピックであり、さらに物事を混乱させるのは、DNSレコードに署名するためのいくつかの標準的なセキュリティアルゴリズムが、IANAによって定義されていることです。アルゴリズム13は、Elliptic Curve Digital Signing Algorithm（ECDSA）の変形版である。現在、使用されているドメインは0.01%未満ですが、ECDSAによって、DNSSECの普及のための最後の2つの障壁であるゾーン列挙とDDoS増幅を排除できたと主張したいと思います。
この記事を読み終えると、以下のことができるようになります。
記事のリンクをコピーする
DNSSECは、複雑なトピックであり、さらに物事を混乱させるのは、DNSレコードに署名するためのいくつかの標準的なセキュリティアルゴリズムが、IANAによって定義されていることです。アルゴリズム13は、Elliptic Curve Digital Signing Algorithm（ECDSA）の変形版である。現在、使用されているドメインは0.01%未満ですが、ECDSAによって、DNSSECの普及のための最後の2つの障壁であるゾーン列挙とDDoS増幅を排除できたと主張したいと思います。
ゾーン列挙はライブ署名によって防止されるが、これはECDSAの高速署名生成によってのみ計算上効率的である。また、楕円曲線はRSAに比べ、鍵や署名が非常に小さくなるため、DNSの問い合わせに対する応答も小さくなる。これにより、DNSを利用したDDoS攻撃の増幅率を大幅に低減することができます。
DNSSECは、NSECおよびNSEC3レコードを通じて、認証済みの不在証明を導入しています。しかし、DNSSECの複雑さと考慮事項で述べたように、NSECとNSEC3は共に攻撃者によるゾーンウォーキングを可能にします。この問題を解決するには「DNSSECホワイト・ライ」（RFC4470および4471で説明されている）と呼ばれる巧妙なテクニックを使用しますが、これはDNSSECレコードが「オンザフライ署名」されている場合にのみ実装できるものです。
RSAは、プロトコルで定義された唯一の必須アルゴリズムであるという理由もあり、DNSSECで最も広く使われている署名アルゴリズムです。残念ながら、RSAによるライブ署名は非常に高価なものになります。
ECDSAのパフォーマンスの向上には目を見張るものがあります。ECDSA署名の生成には、同等のRSA署名の10分の1の計算量で済みます。そのため、ライブ署名（およびDNSSECのホワイト・ライ）が、大規模でも実現可能になります。
DNSSECベータ版（署名したドメインは1,000未満）を提供している間、Cloudflareは、毎秒数万件のDNSSECクエリーに応答してきました。これは1日10億回以上のクエリに相当し、必要なRRSIGのレコードをすべてオンザフライで署名していることが分かります。RSAの10倍の速さの署名アルゴリズムを持つことは、DNSSECサーバーの負荷を考えると大きな違いをもたらします。
ECDSAに取り組み始めた頃、私たちはOpenSSLの実装にGoを使用していました。私たちが行っているすべての署名を考慮すると、署名生成の最適化は重要な優先事項でした。そこで、ECDSAの実装を低水準のアセンブリで書き直したところ、Goに比べて20倍以上もの高速化を実現しました。このコードはオープンソース化されており、暗号コミュニティ全体で私たちの最適化を利用できるように、Go 1.7に取り込まれる予定です。詳細を読む
Cloudflareは、世界最大のマネージドDNSプロバイダーです。当社が本当に望まないのは、DNSSECサーバーを分散型サービス拒否（DDoS）攻撃の増幅ベクトルに変えてしまうことです。DNSSECサーバーにレコードを要求するたびに、そのレコードに関連付けられた署名と、その署名を検証するために使用される公開鍵が返されます。これは膨大な情報量になる可能性があります。
DNSSECクエリの応答サイズを可能な限り小さくすることは、攻撃しようとしている者からDNSインフラストラクチャが悪用されることを防ぐための重要な要件です。ECDSAの鍵や署名のサイズが小さいことは、この目的に大きく貢献します。
ECDSAで128bitのセキュリティを実現するには256bitの鍵が必要ですが、同等のRSA鍵は3072bitです。これは、鍵だけで12倍の増幅率ということになります。暗号鍵のサイズが異なる理由については、こちらのブログ記事で詳しく解説しています。
しかし、ほとんどのRSA鍵は3072ビットではないため、12倍の増幅率は最も現実的な数字とは言えないかもしれません。DDoS増幅の現実的な最悪のシナリオであるネガティブレスポンス（NSECレコード）について見てみましょう。Cloudflare（ECDSA署名とDNSSECのホワイト・ライを使用）の後にあるドメインの場合、一般的なDNSSECの応答は377バイトです。これを、ECDSAまたはDNSSECのホワイト・ライを使用していないドメインの1075バイトと比較します。
他のすべての大規模なDNSSEC実装がRSA署名に依存しているという事実を考慮すると、攻撃者が当社のDNSSECインフラストラクチャをDDoSの攻撃ベクトルとして利用するのは魅力的ではありません。
ECDSAはDNSSECの主要な問題を解決するものの、世界のDNSSECコミュニティではほとんど活用されていないのが現状です。ルートDNSゾーンとAlexa one millionでのECDSAの採用状況を簡単に見てみました。
まず、私たちはルートDNSゾーンを調査してトップレルドメインがどのDNSSECアルゴリズムを使用しているかを確認しました。次の表は、ルートゾーンファイル内のDSレコードで指定されたセキュリティアルゴリズムを示したものです：
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
同様の分析をAlexa one millionについても行ったところ、世界のインターネットトラフィックの整合性の取れた断面が得られました。
| アルゴリズム | 署名されたDSレコードの数 |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (ECDSA Curve P-256 with SHA-256) | 23 |
最も驚くべき事実は、1,000,000件のWebサイトのうち、任意の容量でDNSSECをサポートしているWebサイトはわずか15,643件しかないということです。その1.5％のうち、アルゴリズム13で署名しているのはわずか23ゾーンだけに留まります。そして、そのアルゴリズム13を使用しているゾーンの半分以上が、Cloudflareネットワークの背後にあります。つまり、Cloudflare以外でECDSAを使用しているゾーンは、Alexa one millionのうち10数件以下ということになります。これは、Roland van Rijswijk-Deij et alらの調査結果である、.com、.netおよび.org内の署名付きドメインの99.99%がRSAを使用しているというものを裏付けています。
では、アルゴリズム13はDNSSECの大きな問題を解決しているにも関わらず、なぜ使用率が低いのでしょうか？RSAはDNSSECとともに、プロトコルの初期から導入されています。ECDSAは新しい暗号アルゴリズムであり、リゾルバ、レジストラ、レジストリはまだ追いついていません。
ECDSAにはトレードオフがないわけではありません。Roland van Rijswijk-Deij et alによると、ECDSA検証をサポートしているリゾルバは80%に過ぎないとのことです。この数は増加傾向にありますが、この使用率では今すぐDNSSECインターネット全体をECDSAに切り替えた場合、毎日何百万人ものインターネットユーザーに対するDNSSEC検証が失敗し、検証されていないDNSレコードを返すことになります。
さらに、ECDSA署名の作成はRSAより高速ではあるものの、署名の検証は実際にはかなり低速になります。Roland van Rijswijk-Deijらは、我々がOpenSSLに貢献したECDSAの最適化をもってしても、ECDSAは1024ビットRSA（ゾーン署名鍵に最もよく使われるアルゴリズム）よりも6.6倍遅いことを示しました。DNSリゾルバーに過負荷をかけると、インターネット全体が遅くなる可能性があるため、これは深刻な問題です。
このAlgorithm 13の議論には、非常に重要な注意点が一つあります。何らかの立場でDNSSEC対応しているWebプロパティはわずか1.5%しかないという点です。すべてのレジストラがDNSSECに対応しているわけではなく、対応の追加は容易ではありません。レジストラは、まずユーザーがDSレコードをアップロードできるようにし、そのレコードをレジストリにアップロードする必要があります。当社はこれを自動プロセスにすることにより、登録者がDSレコードをアップロードする必要さえなくそうとしていますが、それでもレジストラの介入は必要です。
そのような中での明るい知らせは、私たちが正しい方向へ向かっているということです。過去12ヶ月の間、DNSSECは全般的にかなりの成長を遂げてきました。また、公開されているDNSSECのベータ版からユニバーサルDNSSECの発表までの3週間の間にレジストリ、Hover、OVH、Metaname、Internet.bs、.NZが、アルゴリズム13をサポートするようになりました。
私たちは、DNSSECが現代のWebにとって不可欠な技術であり、ECDSAによってグローバルなDNSSECの採用が現実的なものになると考えています。願わくば、今後も大小さまざまなレジストラやレジストリでアルゴリズム13がサポートされることを望みます。