代替DNSサーバーが解決できない

代替DNSサーバーが解決できない

Linux で DNS サーバーをフォワーダーとして構成しました。
組織のメイン DNS サーバーにのみ DNS クエリを転送します。

Windows クライアント (組織のブランチ) では、プライマリ DNS は独自の DNS サーバーに設定され、
代替は自分の DNS サーバー (フォワーダー DNS) に設定されています。

自分の DNS サーバーが代替として設定されている場合は、解決できません。
ただし、自分の DNS サーバーがプライマリとして設定されている場合は、解決が機能します。

代替 DNS として設定されている場合に、自分の DNS サーバーを機能させるにはどうすればよいですか?

答え1

基本的なDNSリゾルバ(Windowsクライアントのものなど)は、設定された各DNSサーバーは、知るべきすべての情報を知っているか、または知ることができる。あるサーバーが何かが存在しないと言った場合、別のサーバーにセカンドオピニオンを求めても意味がありません。

DNS サーバーは、情報の取得元に関してより柔軟に構成できます。多くの DNS サーバーは、選択的に要求を転送するように構成できます。「要求がドメイン に関するものであればX.Y.example、サーバー A に転送し、その他の に関するものであればY.example、サーバー B に転送し、それ以外の場合はインターネットの DNS サーバーに問い合わせて自分で解決を試みます。」

しかし、これは DNS 解決を設定する通常の方法ではありません。


プライマリDNSサーバーの情報がドメインに関する情報でありY.example、DNSサーバーがサブドメインに関する情報を持っている場合X.Y.example、プライマリDNSサーバーはいわゆるグルーレコードドメインの情報にY.example次のような内容が記載されています。

X.Y.example.            IN NS <your.DNS.server.name.>

また、DNS サーバーがY.exampleドメイン内にある場合 (つまり、X.Y.exampleドメインの一部、またはY.exampleドメインもしくはそのサブドメインの一部である場合) は、次のことも考慮してください。

<your.DNS.server.name.> IN A <your DNS server IP address>

NSレコードは、プライマリDNSサーバーに、ドメインに関する情報を取得するためにDNSサーバーに問い合わせるよう指示しますX.Y.example。これは、DNS委任Aレコードは接続先のアドレスを指定するためのものです。グルーレコード


ネームサーバーの情報が無関係なドメインに関するもの (例 ) である場合Z.other.example、次の 3 つのオプションがあります。

  • プライマリ ネーム サーバーは、ドメインのコンテンツの完全なコピーをダウンロードしZ.other.example、定期的に DNS サーバーをチェックして自動的に最新の状態に維持できるように、DNS サーバーと特別な関係を持つ場合があります。これは通常、関係と呼ばれますmaster/slave。サーバーは のマスター権限を持ちますZ.other.exampleが、プライマリ DNS サーバーはそのドメインのコンテンツを完全に把握しており、ダウンロードしたデータに基づいて権威を持って応答できます。

BIND の場合、サーバーは次のようになります。

options {
    allow-transfer { <IP address of primary DNS server>; };
    # The next line is not absolutely necessary but speeds up propagation of updates:
    also-notify { <IP address of primary DNS server>; }; 
    <... any other options here...>
}; 

プライマリ サーバーには次のものが含まれます。

zone "Z.other.example" { 
    type slave; 
    masters { <IP address of your DNS server>; };
};

そして、これは組織の主要なDNSサーバーはスレーブサーバーになりますドメインZ.other.exampleのみ他のドメイン/ゾーンでは、これは効果がありません。

通常、このような関係は、プライマリDNSサーバーがZ.other.exampleドメインのNSレコードにも記載される可能性があることを意味しますが、そんなことしなくてもいいドメインがプライマリ DNS サーバーのユーザーの内部使用のみを目的としている場合。

  • または、プライマリ DNS サーバーは、条件付きでクエリを転送するように構成できます。「リクエストが Z.other.example に関するものであれば、他の操作は行わずに DNS サーバーに転送します」。これは、たとえば、パブリック NS レコードで存在を明らかにしてはならない組織の内部 DNS ドメインで行われることがあります。

このため、プライマリ サーバーには次のものが必要です。

zone "Z.other.example" { 
    type forward;
    forwarders { <IP of your DNS server>; };
    forward only;
}; 
  • または、特別な構成がない場合は、DNS サーバーがZ.other.exampleドメインを見つけるために NS レコードのチェーンが存在する必要があります。
    • exampleルートDNSサーバーには、トップレベルドメインのDNSサーバーを指すNSレコード(および対応するAレコード)が必要です。
    • ドメインサーバーには、第2レベルドメインexampleのDNSサーバーを指すNSレコードが必要です。other.example
    • ドメインの DNS サーバーother.exampleには、 を担当する DNS サーバーを指す NS レコードが必要ですZ.other.example

これにより、プライマリ DNS サーバーは、インターネット上の他のドメインと同様に、ドメインを見つけることができるようになります。


DNSサーバーにドメインにいくつかの追加レコードを提供させたい場合はY.exampleそれはうまくいきません。

DNS サーバーが特定のドメイン (委任されたサブドメインがある場合は除く) に対して権限を持っている場合、そのドメインの内容について常に完全な知識を持っている必要があります。権限のある立場にある DNS サーバーには、「おそらく」というものはありません。プライマリ DNS サーバーが権限を持ち、それY.exampleについて問い合わせたときに、X.Y.exampleそのドメインのレコードがなく、一致するサブドメイン委任がない場合、その応答は「そのようなホスト/ドメインはありません」という人間の言葉で表現されます。

「私は Y.example について知るべきことはすべて知っていますが、XYexample のようなものは絶対に存在しません。」


プライマリサーバーがドメインのクエリを拒否し、クライアントが代わりに代替DNSサーバーに問い合わせるようにすることは技術的には可能かもしれませんが、私は強くそれを勧めません

このような設定は最初はうまくいっているように見えるかもしれませんが、特にネームサーバーのどちらかが一時的にアクセス不能になったときに予期しない形で失敗する傾向があります。多くの人がこのような設定を試して失敗しています。学習経験は、困難な時期に苦痛を伴うトラブルシューティングセッションを伴う傾向があります。ないあなたが選択した方法、および/または、問題の解決を支援するよう警告された、より経験豊富な DNS 管理者からの顔面を手で覆う方法。

関連情報