目次:
4月、オランダのハッカーが、これまでに見られた最大の分散型サービス拒否攻撃と呼ばれるもので逮捕されました。 スパム対策組織であるSpamhausで攻撃が行われ、欧州連合のITセキュリティ機関であるENISAによると、Spamhausのインフラストラクチャの負荷は毎秒300ギガビットに達し、以前の記録の3倍に達しました。 また、大きなインターネットの混雑を引き起こし、世界中のインターネットインフラストラクチャを妨害しました。
もちろん、DNS攻撃はめったにありません。 しかし、Spamhaus事件のハッカーは標的を傷つけることしか意図していませんでしたが、攻撃の大きな影響は、インターネットインフラストラクチャの大きな欠陥であるドメインネームシステムと呼ばれるものも多く指摘しています。 その結果、コアDNSインフラストラクチャに対する最近の攻撃により、技術者とビジネスマンはソリューションを奪い合っています。 あなたはどうですか？ 自分のビジネスのDNSインフラストラクチャを強化するためのオプションと、DNSルートサーバーの動作方法を知ることが重要です。 それでは、いくつかの問題と、企業が自分自身を守るためにできることを見てみましょう。 （DNSの詳細については、「DNS：すべてを支配する1つのプロトコル」を参照してください。）
既存のインフラ
ドメインネームシステム（DNS）は、インターネットが忘れていた時代のものです。 しかし、それは古いニュースにはなりません。 サイバー攻撃の絶え間なく変化する脅威に伴い、DNSは長年にわたって多くの精査を受けてきました。 DNSは初期の段階では、DNSクエリの送信者または受信者の身元を確認するための認証形式を提供していませんでした。
実際、長年にわたって、非常にコアなネームサーバー、つまりルートサーバーは、広範囲にわたるさまざまな攻撃を受けていました。 最近では、それらは地理的に多様であり、政府機関、商業団体、大学などのさまざまなタイプの機関によって運営されており、整合性を維持しています。
驚いたことに、過去にいくらか成功した攻撃もあります。 たとえば、ルートサーバーインフラストラクチャに対する障害攻撃は、2002年に発生しました（それについてのレポートはこちらをご覧ください）。 ほとんどのインターネットユーザーに目立った影響はありませんでしたが、13のオペレーティングルートサーバーのうち9つに影響を与え、高度に専門的でターゲットを絞ったため、FBIと米国国土安全保障省の注目を集めました。 専門家によると、それが1時間以上続いた場合、結果は壊滅的なものになり、インターネットのDNSインフラストラクチャの要素がほとんど役に立たなくなる可能性がありました。
インターネットのインフラストラクチャのこのような不可欠な部分を打ち負かすことは、成功した攻撃者に大きな力を与えるでしょう。 その結果、ルートサーバーインフラストラクチャのセキュリティ保護の問題に多大な時間と投資が費やされています。 （ルートサーバーとそのサービスを示すマップをここで確認できます。）
DNSの保護
コアインフラストラクチャの他に、自社のビジネスのDNSインフラストラクチャが攻撃と障害の両方に対してどれだけ堅牢であるかを考慮することも同様に重要です。 たとえば、ネームサーバーは完全に異なるサブネットまたはネットワークに常駐することが一般的です（RFCにも記載されています）。 つまり、ISP Aが完全に停止し、プライマリネームサーバーがオフラインになった場合でも、ISP Bはそれを要求するすべてのユーザーにキーDNSデータを提供し続けます。
ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、企業が独自のネームサーバーインフラストラクチャをセキュリティで保護できる最も一般的な方法の1つです。 これらは、ネームサーバーに接続しているマシンが正しいことを確認するためのアドオンです。 DNSSECでは、要求の送信元を特定する認証、およびデータ自体が途中で変更されていないことを確認することもできます。 ただし、ドメインネームシステムのパブリックな性質により、使用される暗号化はデータの機密性を保証せず、インフラストラクチャの一部が何らかの記述の失敗に苦しむ場合の可用性の概念もありません。
RRSIG、DNSKEY、DS、NSECレコードタイプなど、これらのメカニズムを提供するために、多くの構成レコードが使用されます。 （詳細については、12のDNSレコードの説明をご覧ください。）
RRISGは、クエリを送信するマシンと送信するマシンの両方でDNSSECが利用可能な場合に使用されます。 このレコードは、要求されたレコードタイプと一緒に送信されます。
署名された情報を含むDNSKEYは次のようになります。
ripe.netはDNSKEYレコードを有する257 3 5 AwEAAXf2xwi4s5Q1WHpQVy / kZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk + Y7vZCvSN1AcYy0 / ZjL7cNlkc3Ordl2DialFHPI6 UbSQkIp3l / 5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i958WZJ6LI0pOTNK + BIx8u98b + EVr7C08dPpr9V6Eu / 7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtmJxDT067oJoNBIK + gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XSCm5sNxrRk =
DS（委任署名者）レコードは、信頼チェーンを認証するために使用され、親ゾーンと子ゾーンがより快適に通信できるようにします。
NSEC、または次の安全なエントリは、本質的にDNSエントリのリスト内の次の有効なエントリにジャンプします。 これは、存在しないDNSエントリを返すために使用できるメソッドです。 これは、構成されたDNSエントリのみが本物であると信頼されるようにするために重要です。
NSEC3は、辞書スタイルの攻撃を軽減するために改善されたセキュリティメカニズムであり、RFC 5155で2008年3月に承認されました。
DNSSECレセプション
多くの支持者はDNSSECの展開に投資していますが、批判者がいないわけではありません。 クエリがハイジャックされ、DNSクエリを生成する人に無意識のうちに誤ってフィードされる可能性がある中間者攻撃などの攻撃を回避する能力にもかかわらず、既存のインターネットインフラストラクチャの特定の部分との互換性の問題が疑われています。 主な問題は、DNSSECは通常、帯域幅をあまり消費しないUser Datagram Protocol（UDP）を使用するのに対して、DNSSECはより高い伝送制御プロトコル（TCP）を使用してデータをやり取りし、信頼性とアカウンタビリティを向上させることです。 古いDNSインフラストラクチャの大部分は、1日24時間、週7日間、何百万ものDNS要求で満たされているため、トラフィックを増やすことができない場合があります。 それでも、DNSSECはインターネットインフラストラクチャを保護するための主要なステップであると多くの人が考えています。
人生で何も保証されていませんが、あなた自身のリスクを考慮するのに少し時間をかけることは、将来の多くの高価な頭痛を防ぐかもしれません。 たとえば、DNSSECを展開することにより、主要なDNSインフラストラクチャの一部に対する信頼を高めることができます。
