web-dev-qa-db-ja.com

DNS再帰は安全ではありませんが、内部アプリケーションに必要ですか？

Windows Server 2008の管理では、サーバーは一部のドメインのDNS（ネームサーバー）をホストし、パブリックにアクセス可能な一部のアプリケーションをホストします。

セキュリティスキャンは、DNS構成が再帰的なクエリを許可するため、安全でないことを示しています。

再帰クエリを無効にしようとしましたが、いくつかの問題が発生しました（ローカルアプリから送信されたメールが配信されず、サードパーティのサイトに接続するローカルで実行されているアプリが接続のドメイン名を解決できなかったなど）。したがって、サーバー自体から発信されたDNS要求は、機能するために再帰クエリに依存しているようです。

サーバーで発生したDNSクエリが機能することを許可しながら、サーバーでホストされているDNSによる再帰クエリを無効にする方法はありますか？ローカルDNSサーバーで再帰クエリを無効にし、ネットワーク設定で送信DNSを外部（8.8.8.8など）に設定して、送信DNSクエリが最初にそこに行き、このサーバーのDNSが終了するだけなのかどうか疑問に思っています。実際にローカルでホストしているドメインのクエリを取得します。

御時間ありがとうございます！

windowswindows-server-2008domain-name-system
16
ilasno

インターネット全体に再帰的なルックアップ機能を提供しないことをお勧めします。そのため、信頼できるクエリにのみ応答するようにDNSサーバーを構成することは良いことです。TM。

表面的には、前の段落で達した結論は良いもののようです：is再帰的なルックアップを提供する権限があります。 DNSサーバープロセスは、サーバーコンピューターのTCP/IP設定で構成されたDNSサーバーを使用しませんNIC特に何でもです。むしろ、以下に基づいて要求を転送します（またはルートヒントを使用します）。 DNSサーバー構成。

サーバーで実行されているアプリケーションがドメインを照会しようとすると、そのマシンで実行されているDNSサーバーは要求に対して権限があり、最終的にはそのマシンで実行されているDNSサーバープロセスに到達し、照会に応答します。

11
Evan Anderson

サーバーで発生したDNSクエリが機能することを許可しながら、サーバーでホストされているDNSによる再帰クエリを無効にする方法はありますか？

MicrosoftのDNSサーバーではなく、そうではありません。

ISCのDNSサーバーであるBINDを使用すると、ビューを使って物事を回避できます。 MicrosoftのDNSサーバーにはそのようなメカニズムはありません。したがって、Microsoft DNSサーバーの特定のインスタンスについて、それがパブリックcontent DNSサーバーであるかサイトローカルproxy DNSサーバーであるかを選択する必要があります。それは物事をかわすことができず、異なる種類のサーバーが異なるDNSクライアントになりすますことはできません。

セキュリティテストサービス/ツールは非常に適切です。 isプロキシサービスを提供しないことのベストプラクティス— anyプロキシサービスの種類：HTTPプロキシサービス、DNSプロキシサービス、SMTPサブミッションサービスなど、残りのインターネット自分のサイトがありません。あなたは大いにすべき持っている個別のサーバー：登録したドメイン名に関するパブリックDNSデータをインターネット上のすべての人に公開するコンテンツDNSサーバー。ローカルプロキシDNSサーバー。これは、LANまたは組織のコンピューターに代わってクエリ解決の大まかな作業を実行します。これは、組織またはLAN上のマシンにのみアクセスできます。 MicrosoftのDNSサーバーでは、これは特に簡単ではありません。

お使いのマシンがドメインコントローラでもある場合、特に困難になります。あなたはこのマシンがインターネット全体から直接到達可能であると述べています。そのようなマシンがドメインコントローラーである場合は、ネットワーク構成を再考する必要がありますnow。プロキシDNSサービスだけでなく、非常に多くの内部サービスを公開することになります。それでは、これがドメインコントローラではないという前提に取り組みましょう。

これはドメインコントローラーではなく、単に メンバーサーバー であるため、マシンのDNS clientがマシン自身のDNSを使用する必要はありません。 サーバー（または、最初は別のドメインコントローラーのDNSサーバー）。これは、ドメインコントローラーの場合のプロキシDNSサービスの場合です。使用している場合、マシンのDNSサーバーでプロキシDNSサービスをオフにすることはできません。幸い、それはドメインコントローラーではなく、そのDNSクライアントは、それ自体ではなく、プロキシDNSサービス用に他のマシンを使用できます。

ただし、メンバーサーバーマシンのDNSクライアントはinternalプロキシDNSサーバーを使用する必要があります。 ISP、Google、またはActive DirectoryがLANで使用しているすべてのDNSデータを認識していないのような外部DNSサーバーを指すことはできません。ただし、マシンのDNSクライアントを1つ以上のドメインコントローラーのDNSサーバーに向けることができます。これは非常に単純であり、結局のところ、LAN上のすべてのワークステーションですでに実行しています。メンバーサーバーのDNSクライアントは、単に構成する必要がありますすべてのワークステーションのDNSクライアントのように。

マシンのDNSクライアントがマシン上で実行されているDNSサーバーをプロキシDNSサービスに使用していない場合、MicrosoftのDNSサーバーを構成して、いかなる形式のプロキシDNSサービスも誰にも提供しないようにします。

参考文献

14
JdeBP

Evanが彼の回答で述べたように、アプリケーションはサーバー上のDNSクライアントコンポーネントを使用する必要があります。これは、DNSサーバーコンポーネントから完全に独立しています。 DNSサーバーコンポーネントは、再帰を実行しないように構成でき、権限のあるDNSゾーンに対してのみ、送信されたクエリに応答できます。

アプリケーションは、関連するNICのTCP/IPプロパティで構成されたDNSサーバーを使用できます。これは、再帰を実行するすべてのDNSサーバー（GoogleのDNSサーバーなど）を使用するように構成できます。関連するNIC=のTCP/IPプロパティで構成されたDNSサーバーは、同じサーバーで実行されているDNSサーバーを指す必要はありません。

5
joeqwerty

最近同じ問題が発生し、DNSサーバーが増幅攻撃に使用されていました。しかし、私は他の内部サーバーのために再帰を維持する必要があります。

Ciscoルーターを使用している場合、考えられる修正は次のとおりです。外部DNSをCisco 7200VXRルータに移動し、特定のDNSゾーンにのみ応答するように設定しました。これは内部DNSサーバーにクエリを実行するため、2か所にすべてを入力する必要はありません。

以下は、私が使用したCisco構成のスニペットです。

ip dns view default
 dns forwarder 192.168.0.xx (internal DNS server)
 domain round-robin

ip dns view-list default
 view default 1
  restrict name-group 1

ip dns name-list 1 permit abc.com
ip dns name-list 1 permit def.com
ip dns name-list 1 permit anyotherdomainthatyouhost.com
ip dns name-list 1 permit 3.2.1.in-addr.arpa (needed for reverse PTR lookups)

interface fastethernet0/0 (the interface where the IP address is that will Host DNS)
 ip dns view-group default
 ip address 1.2.3.4 secondary (use the public facing IP you will use to Host DNS)

ip dns server

また、次のようなアクセスリストを使用して、ルーターへのDNSパケットを許可することを忘れないでください。

permit udp any Host 1.2.3.4 eq domain
0
Brain2000