セキュリティ担当者は、何十年もの間、DNSサーバーに対するDNSクエリをUDPポート53のみを使用するように制限するように人々に助言してきました。 現実には、UDPポート53が受け入れられない場合、DNSクエリでもTCPポート53を使用できます。 DNSSECの差し迫った展開とIPv6の最終的な追加により、TCPとUDPポート53パケットの両方を転送するためのファイアウォールを許可する必要があります。

DNSは、攻撃者が偵察技術の一つとして使用することができます。, 標的のサーバーに含まれる公開情報は、攻撃者にとって貴重であり、攻撃に集中するのに役立ちます。 攻撃者は、さまざまな手法を使用して、クエリを通じてDNS情報を取得できます。 ただし、ハッカーは、権限のあるDNSサーバーからゾーン転送を実行して、より多くの情報にアクセスしようとします。 Digコマンドを使用すると、特定のゾーンファイルに関する情報をサーバから収集できます。,

dig @192.168.11.24 example.org -t AXFR

ゾーン転送はTCPポート53を介して行われ、DNSサーバーが攻撃者に重要な情報を漏らすのを防ぐために、TCPポート53は通常ブロックされます。 権限のあるDNSサーバーを保護する組織のファイアウォールがTCPポート53パケットを許可し、DNSサーバーが誰かへのゾーン転送を許可するように構成されている場 しかし、多くの組織を設定してそのDNSサーバーを防止ゾーンからの送迎意図しないDNSサーバー, これは、次に示すように、allow-transferコマンドのいずれかの形式を使用して、BINDゾーンファイルで設定できます。

allow-transfer {"none";}; allow-transfer { address_match_list }; allow-transfer {192.168.11.11;};

さらに、ほとんどの組織では、ファイアウォールを使用して、DNSサーバーとインターネットとの間のTCPポート53をブロックしています。 これは、DNSサーバーが誤って転送を許可した場合の二重保護です。

正当なDNSサーバーのみへのゾーン転送を許可するようにDNSサーバーを設定することは、常にベストプラクティスであり続けています。, ただし、DNSサーバーとの間でTCPポート53を拒否する方法は、いくつかの問題を引き起こし始めています。 DNSサーバーへのTCPとUDPポート53の両方の接続を許可するには、二つの良い理由があります。 一つはDNSSECで、もう一つはIPv6です。

DNSSECはより大きなDNS応答を作成します

私はIPジャーナルを読むのが大好きで、1998年の創刊号以来読んできました。

IPジャーナルの最近の版には、Secure64とTexas IPv6Task Forceの友人Stephan Lagerholmによる”Dnssecを実装するときの運用上の課題”というタイトルの記事がありました。, この記事では、組織がDNSSECを展開するために移動するときに発生する多くの注意点について説明しました。

言及された重要な問題の一つは、DNSSECによりDNS応答が512バイトより大きくなる可能性があることです。 DNSSEC（RFC4033、RFC4034、およびRFC4035で定義）では、クエリ応答に含まれる追加のキー情報のため、より大きなDNSメッセージを送信する機能が必要です。 TCPポート53は、DNS応答が512バイトより大きい場合に使用できます。, ただし、大きなDNSメッセージにTCPを使用するよりもUDPメッセージを使用する方が望ましいのは、TCP接続が各接続の計算リソースを消費する可能性がある DNSサーバを取得しく接続および使用するTCPを追加できすぎてオーバーヘッド。 この問題に対処するために、IETF RFC2671″Extension Mechanisms for DNS(EDNS0)”では、DNSSECおよびより大きなクエリ応答を可能にするためにUDPバッファサイズを4096バイトに拡張する方法, EDNS0をBIND9構成で有効にするには、次のBIND operationsステートメントを使用できます

edns-udp-size 4096 ;

DNSSECの認識は、2年前に開示された脆弱性と、米国政府がそれを実装しようとしていることに関する最近のニュースによって増加しています。 多くの組織では、DNSSECの展開を計画しています。 DNSSECは、主要なトップレベルドメイン(Tld)が署名されるようになった現在、より広く展開されています。 これでtld.orgが署名されました。 インターネットのルートゾーンの署名はわずか2カ月前の式典にはバージニア., ベリサインは、2011年までに.comと.netのためのDNSSECをサポートしたいと述べています。 Comcastは、最新のDNSSECステータスを最新に保つのに役立つDNSSECインフォメーションセンターサイトを作成しました。