☰

DNSルーティングに関する一般的な質問

tag-icon • tag-icon domain-name-system active-directory domain-controller internal-dns
DNSルーティングに関する一般的な質問

質問。私は Windows AD ドメインを持っていますが、1 つだけ謎があります。それは、Windows ドメイン / DNS サーバーはどのようにして Windows ドメイン外のドメインの検索を行っているのかということです。

シンプルなホーム ネットワークでは、DNS 要求のルーティングは簡単に理解できます。

Generic Example: Client machine -> (defined DNS or from DHCP) -> 
                ->Router / Gateway -> (usually ISP DNS) -> DNS root servers -> Internet
Specific Example: 192.168.1.101 -> 192.168.1.1 -> 8.8.8.8 -> DNS root servers -> Internet

対照的に、現在 AD ネットワークに表示されているパスは次のとおりです。

Client Machine -> Windows Domain / DNS -> ??????? -> DNS root servers -> Internet

ドメイン サーバーのネットワーク設定を確認すると、DNS は代替 DNS サーバー (セカンダリ ドメイン サーバー)、それ自体、およびループバックに設定されており、他には何も設定されていません。

インターネットは機能しているので、Windows ドメイン サーバーは上流のサーバーから DNS 情報を取得できるほど賢いのですが、これはどこでどのように定義されるのでしょうか?

答え1

DC が外部ネーム サーバーを照会する方法はいくつかあります。

  1. ルートヒント
  2. グローバルフォワーダー
  3. 明示的に定義されたスタブゾーン、委任、または条件付き転送ゾーン
  4. 確認した DC のネットワーク インターフェイスの設定。

私は #1 か #2 を推測します。質問にはネットワーク設定の確認のみが含まれていますが、DC 上の DNS マネージャーは確認しましたか?

上記のすべてが空白の場合は、意図しない問題が発生しているため、Wireshark を使用して発信 DNS クエリを追跡する必要があります。

答え2

DNS は 2 つのまったく異なる部分から構成されています。1 つの部分はデータの公開を担当し、もう 1 つの部分はクライアントからの DNS 要求を受け入れ、データを収集してそれらの要求に応答する役割を担っています。データの公開の役割を果たす DNS サーバーは、技術的に正しい名前ではありませんが、多くの場合「権威」サーバーと呼ばれます。個人的には「DNS コンテンツ サーバー」という名前を好みますが、この用語はあまり広く使用されていません。クライアントからの要求を受け入れて応答するサーバーは、多くの場合「解決」サーバーと呼ばれます。

これは、HTTP サーバーと HTTP プロキシの動作と非常によく似ています。HTTP サーバーはデータを公開し、HTTP プロキシはクライアント (ブラウザー) からの要求を受け入れ、サーバーに接続してクライアントが要求したデータを収集します。Web ブラウザーと DNS クライアントの違いは、DNS クライアントはコンテンツ DNS サーバーに単独で接続できないことです。DNS クライアントは、しなければならないDNS 解決サーバーを使用しますが、Web ブラウザは HTTP プロキシがなくても完全に機能します。

DNS 情報は階層的かつ分散的に格納されるため、1 つのクエリに応答するには、おそらく世界中にある複数の DNS コンテンツ サーバーからの情報が必要になります。DNS クライアントが「www.serverfault.com」のアドレスを知りたい場合は、その要求を DNS 解決サーバーに送信するだけで済みます。その後、その DNS 解決サーバーは、世界中の DNS サーバーに接続するという実際の作業を実行する必要があります。

まず、解決DNSサーバーはクエリ全体をルートサーバー（コンテンツDNSサーバー）に送信します。ルートサーバーは完全な回答を持っていませんが、するどの DNS コンテンツ サーバーが ".com" ドメイン内の名前についてより詳しい情報を持っているかは、DNS リゾルバによって認識されます。そのため、DNS リゾルバは、クエリ全体を ".com" コンテンツ DNS サーバーの 1 つに送信します。そのサーバーも完全な回答を持っていませんが、どの DNS コンテンツ サーバーがドメイン内の名前についてより詳しい情報を持っているかは認識していますservervault.com。解決 DNS サーバーは、クライアントに完全な回答を提供するまで、世界中のコンテンツ DNS サーバーに問い合わせを続けます。もちろん、解決 DNS サーバーは途中で情報をキャッシュします。つまり、キャッシュから ".com" コンテンツ DNS サーバーの場所がわかっている場合は、 ".com" ドメイン内のクエリごとにルート コンテンツ DNS サーバーに接続しません。

「フォワーダー」とは、世界中のコンテンツ DNS サーバーに問い合わせて自ら応答するのではなく、クライアントのクエリを別の (事前設定された) 解決 DNS サーバーに送信する解決 DNS サーバーです。ホーム ルーターには解決 DNS サーバーが搭載されていることが多く、ISP の解決 DNS サーバーをフォワーダーとして使用するように設定されています。

2 つの異なる役割 (コンテンツの提供と解決の両方) が 1 つの DNS サーバーにまとめられると、混乱が生じる可能性があります。これは、Active Directory でほぼ発生することです。Active Directory では、DNS を使用して、特定のサービスが見つかる場所に関する情報を公開します。たとえば、ドメイン内のクライアントがad.example.comドメインの Kerberos パスワード変更サーバーに接続する場合、 という SRV レコードの DNS 要求を発行します_kpasswd._tcp.ad.example.com。この DNS 要求は、他の DNS 要求と同様に、クライアントで構成されている解決 DNS サーバーに送信されます。次に、解決 DNS サーバーは、要求に応答しようとします。

ここで少し混乱することがあります。DNS 解決サーバーは、特定の Active Directory ドメインの一部であることを認識している可能性があります。つまり、そのドメイン内の名前に対する受信クエリを認識できるということです。リゾルバーがそのようなクエリを受信した場合、外部の DNS サーバーには接続しませんが、Active Directory データベースからの情報で直接応答できます。受信クエリがドメイン内の名前に対するものではない場合、リゾルバーはコンテンツ DNS サーバーに接続して質問に回答しようとするか、(フォワーダーを使用するように構成されている場合) 別の DNS 解決サーバーにクエリを送信するだけです。これが、シナリオで発生する可能性が高いことです。

さらに混乱を招くのは、動的更新です。重要なドメインでは、サービスは静的ではありません。ドメイン コントローラが追加または削除される可能性があります。同じことがワークステーションにも当てはまります。つまり、これを反映するために DNS の情報を更新する必要があります。動的更新は、クライアントが DNS で公開されている情報を変更できるようにするプロトコルです。クライアントは、新しい情報を送信できるコンテンツ DNS サーバーを調べるために、解決 DNS サーバーにクエリを送信します。Active Directory 統合 DNS インフラストラクチャの場合、解決 DNS サーバーはデータベース自体にアクセスできる可能性があります。その場合、解決 DNS サーバーはクライアントに、情報自体を更新できることを伝えます。

関連情報