私はローカルネットワーク内のdebian 8サーバーでDNSとDHCPサーバーを実行しています。
問題は、クライアントがDHCPサーバーを介して間違った/予期しない順序でネームサーバーを取得することです。
DHCP サーバーの構成:
subnet 192.168.10.0 netmask 255.255.255.0 {
option routers 192.168.10.1;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.10.1, 8.8.8.8, 8.8.4.4;
option time-offset -18000;
default-lease-time 21600;
max-lease-time 43200;
}
そのうち192.168.10.1がDNSとDHCPサーバーです。
クライアントのローカルインターフェイス用にリストされたネームサーバー:
IP4.DNS[1]: 8.8.8.8
IP4.DNS[2]: 8.8.4.4
IP4.DNS[3]: 192.168.10.1
クライアントはisc-dhcp-clientを持つUbuntu 17.10です。
編集:/etc/dhcp/dhclient.confの内容
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;
DHCPサーバーから正しいネームサーバーの順序を取得するにはどうすればよいですか?
必要な順序は、ローカルネームサーバーを最初に使用することです。
したがって:
IP4.DNS[1]: 192.168.10.1
IP4.DNS[2]: 8.8.8.8
IP4.DNS[3]: 8.8.4.4
答え1
クライアントがDNSサーバーの順序を制御しようとするよりも、内部DNSサーバーのみを通知する方がきれいです。これは、内部サーバーが満足できない要求を特定のパブリックDNSサーバーのセットに転送するように構成されている場合に可能です。
たとえば、私のBIND9設定(IP 192.168.2.1
)には次のものがあります。
options {
...
forwarders {
208.67.220.220;
208.67.222.222;
8.8.8.8;
8.8.4.4;
}
...
}
あるいは、(@ RuiFRibeiroのおかげで)ゾーンブロックを使用してルートネームサーバーと通信することもできます。
zone "." IN {
type hint;
file "root.hint"
}
(あなたのディストリビューションでは代わりにdb.root
使用できますroot.hint
)。
forwarders
両方の構成でサーバーが要求された名前のIPを解決できない場合は、適切なIPを見つけるために他のサーバー(定義済みサーバーまたはルートネームサーバーなど)に接続しようとします。つまり、常にローカルサーバーを最初に試して、失敗した場合は別のサーバーを使用してください。
もしそうなら、オプションはdhcpd.conf
簡単です
option domain-name-servers 192.168.2.1;
dhcpd
複数の冗長ローカルDNSサーバーを構成する場合、サーバーはすべて同じように機能するため、順序を気にせずに構成内の各サーバーを指定できます。
答え2
一部のクライアント側のDHCPデーモン最適化がDNSサーバーにパブリックIPアドレスを最初に提供するという事実は驚くべきことではありません。
しかし、注文に対するあなたの主張を考慮すると、次のようになります。
他のDNSビューや回答を提供するためにDNS応答の順序に頼ることはお勧めできません。
そのような決定をオンプレミスインフラストラクチャのクライアントに委ねると、少なくとも必要に応じて、特に否定的なDNSキャッシュがある場合、予測不能な動作が発生する可能性があります。また、DNS トラフィックが増えます。また、階層にDNSサーバーをロードし、内部ドメインについて質問します。
インターネットと内部専用サーバーを使用したり、ビューを使用したり、少なくとも2つの内部DNSサーバーを保持したりするなど、慎重にDNSインフラストラクチャを設計することをお勧めします。
TLDR DHCPを介して「世界」の異なる視点を持つ複数のDNSサーバーを提供しても、サービスの信頼性が向上するわけではなく、むしろその逆です。