RHEL/Centos 6のNIC(eth0 vs eth1)インターフェースごとにDNSネームサーバーをどのように構成しますか?
例
eth0はサブネット10.0.0.1/24にあります
eth1はサブネット192.168.0.1/24にあります
Eth0経由で送信されるすべての要求は、DNSサーバー10.0.0.2を使用する必要があります。
Eth1経由で送信されるすべての要求は、DNSサーバー192.168.0.2を使用する必要があります。
私は追加しました:
DNS1:10.0.0.2>/etc/sysconfig/network-scripts/ifcfg-eth0
DNS1:19.168.0.2>/etc/sysconfig/network-scripts/ifcfg-eth1
ただし、これらの値は無視され、常にデフォルトでresolv.conf "nameserver 10.0.0.2"の設定になります。eth0がダウンしている場合、接続はeth1を介して送信されます。ただし、DNSは10.0.0.2に到達しようとしているため、解決できません。 。
Resolv.confのデフォルトではなく、ifcfgのDNS設定を尊重するにはどうすればよいですか?
または、eth0とeth1に異なるDNSネームサーバーを構成するにはどうすればよいですか?
これを処理するより良い方法はありますか?
更新済み
2つのVLANがあり、それぞれにそれぞれのサブネット上に独自のDNSサーバーがあります。これらは、ローカルDNS(example.loc、guest.appなど)のルックアップを処理し、必要に応じて転送します。
これらは、2つの別々の物理的な場所にある2つの別々のサーバーです。可能であれば、2つのサブネットにまたがって1つのサーバーを実行したくない(1つは機密データを処理する)。
Eth0がダウンした場合、eth1が引き続きDNS要求を行うことができるようにする必要があります。
2つのIPをresolv.confに追加し、最初のサブネットのサーバーに到達できない場合はフォールオーバーさせることを考えましたが、これは洗練されていないようです(eth0のときに最初のサーバーがすべてのDNSクエリでタイムアウトするのを待つ必要があります)ダウン)。
やりたいことは簡単にはできません。
または、eth0とeth1に異なるDNSネームサーバーを構成するにはどうすればよいですか?
ホスト名の名前の検索は、標準のシステムライブラリを介して行われ、特定の「接続」に関連付けられることはありません。実際、DNSクエリが発生した時点ではisは接続されていません。これは、アプリケーションが接続先のアドレスを把握していないためです(これは、最初にDNSを使用している理由です)場所)。
Resolv.confのデフォルトではなく、ifcfgのDNS設定を尊重するにはどうすればよいですか?
Linuxリゾルバーには、単一のグローバル構成(/etc/resolv.conf
)のみがあります。インターフェースごと、ドメインごと、接続ごとの設定はありません。 /etc/sysconfig/network-scripts/...
の設定は/etc/resolv.conf
への入力にのみ使用されます。通常、これらのファイルでDNS1
およびDNS2
を指定すると、最後に表示されるインターフェースが表示されます/etc/resolv.conf
。
これを処理するより良い方法はありますか?
実際に達成しようとしていることを教えていただけますか?特定の状況について詳しく教えていただければ、より良い解決策を提案できる可能性があります。
DNS要求は基本的には
そのため、「リクエスト」時に、どのイーサネットカードが関与するかがわかりません。あなたができることは、「「domain1.com」で終わるすべてのリクエストは192.168.0.2に行き、他のすべてのリクエストは10.0に行くはずです。 .0.2」
同様に、「192.168.0.0/24に一致するすべての逆引きDNS要求は192.168.0.2に行き、残りは10.0.0.2に行く必要があります。」
ラースクが言ったように、Linuxはそのような構成をサポートしていません。ただし、上記のロジックを実装し、リクエストを適切な「実際の」DNSサーバーに転送する独自の最小限のDNSサーバーを実行することもできます。
Dnsmasqがこれを行うことができると思います( 複数のDNSサーバーを転送するようにdnsmasqを構成する方法 を参照してください)。しかし、そのことに気付く前に、Twistedで自分自身をロールバックしました。
from twisted.internet import reactor
from twisted.names import dns
from twisted.names import client, server
class Resolver(client.Resolver):
def queryUDP(self, queries, timeout=None):
if len(queries) > 0 and (str(queries[0].name).endswith('.domain1.com'):
self.servers = [('192.168.0.2', 53)]
else:
self.servers = [('10.0.0.2', 53)]
return client.Resolver.queryUDP(self, queries, timeout)
resolver = Resolver(servers=[('10.0', 53)])
factory = server.DNSServerFactory(clients=[resolver])
protocol = dns.DNSDatagramProtocol(factory)
reactor.listenUDP(53, protocol, interface='127.0.0.1')
reactor.listenTCP(53, factory, interface='127.0.0.1')
reactor.run()
3つすべての質問に対する答えは次のとおりです systemd-resolved (鉱山を強調):
ルックアップ要求は、次のルールに従って、使用可能なDNSサーバーとLLMNRインターフェイスにルーティングされます。
特別なホスト名「localhost」の検索は、ネットワークにルーティングされません。 (他のいくつかの特別なドメインは同じ方法で処理されます。)
単一ラベル名は、LLMNRプロトコルを使用して、IPマルチキャストが可能なすべてのローカルインターフェイスにルーティングされます。 IPv4アドレスのルックアップはIPv4のLLMNRを介してのみ送信され、IPv6アドレスのルックアップはIPv6のLLMNRを介してのみ送信されます。ローカルに構成されたホスト名と「ゲートウェイ」ホスト名の検索は、LLMNRにルーティングされません。
マルチラベル名は、DNSサーバーが構成されているすべてのローカルインターフェイスと、グローバルに構成されているDNSサーバー(存在する場合)にルーティングされます。リンクローカルアドレス範囲からのアドレス検索は、DNSにルーティングされません。
ルックアップが複数のインターフェースにルーティングされる場合、最初に成功した応答が返されます(したがって、一致するすべてのインターフェースのルックアップゾーンが効果的にマージされます)。すべてのインターフェースで検索が失敗した場合、最後に失敗した応答が返されます。
ルックアップのルーティングは、インターフェースごとのドメイン名を設定することによって影響を受ける場合があります。詳細については、systemd.network(5)を参照してください。インターフェイスごとのドメインの1つで終わるホスト名のルックアップは、一致するインターフェイスに排他的にルーティングされます。