Настроить DNS-сервер для интерфейса nic (eth0 / eth1)?

Как бы вы настроили сервер имен DNS для интерфейса NIC (eth0 vs eth1) на RHEL / Centos 6?

Например.

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> / и т.д. / sysconfig / сетевые сценарии / ifcfg-eth0

DNS1: 19.168.0.2> / и т.д. / sysconfig / сетевые скрипты / ifcfg-eth1

Однако эти значения игнорируются, и всегда по умолчанию используется параметр в resolv.conf «nameserver 10.0.0.2». Когда eth0 не работает, соединения отправляются через eth1 ... однако DNS больше не может разрешить, поскольку он пытается достичь 10.0.0.2 .

Как мне заставить его уважать настройки DNS в ifcfg, а не настройки по умолчанию для resolv.conf?
Или как мне настроить другой DNS-сервер для eth0 и eth1?
Есть ли лучший способ справиться с этим?

Обновлено

У нас есть два VLAN, каждый из которых имеет собственный DNS-сервер в соответствующей подсети. Они обрабатывают поиск локального DNS (example.loc, guest.app и т. Д.), А также переадресацию при необходимости.

Это два отдельных сервера в двух разных физических местах. Если возможно, я бы предпочел не запускать один сервер в двух подсетях (одна обрабатывает конфиденциальные данные).

Если eth0 должен был выйти из строя, мне нужно, чтобы eth1 продолжал выполнять запросы DNS.

Я думал о добавлении двух IP-адресов в resolv.conf, а затем позволял ему отключиться, если он не может достичь сервера в первой подсети, но это кажется неэлегантным (необходимость ждать, пока первый сервер истечет с каждым запросом DNS, когда eth0 вниз).

Вы не можете легко делать то, что хотите.

Или как мне настроить другой DNS-сервер для eth0 и eth1?

Поиск имени хоста происходит через стандартные системные библиотеки и никоим образом не связан с конкретным «соединением». Фактически, когда происходит запрос DNS, там является нет подключения, потому что ваше приложение даже не выяснило адрес, к которому оно будет подключаться (именно поэтому оно в первую очередь использует DNS).

Как мне заставить его уважать настройки DNS в ifcfg, а не настройки по умолчанию для resolv.conf?

Решатель Linux имеет только одну глобальную конфигурацию (/etc/resolv.conf). Нет никаких настроек для каждого интерфейса, домена или соединения. Настройки в /etc/sysconfig/network-scripts/... используются только для заполнения /etc/resolv.conf, и обычно, если вы укажете DNS1 и DNS2 в этих файлах последним появится интерфейс, который вы видите в /etc/resolv.conf.

Есть ли лучший способ справиться с этим?

Можете ли вы рассказать нам, чего вы на самом деле пытаетесь достичь? Мы могли бы предложить лучшие решения, если вы расскажете нам больше о своей конкретной ситуации.

Запрос DNS в основном либо

"какой IP-адрес host1.domain1.com" или
"какое имя хоста 192.168.0.5."

Таким образом, во время «запроса» неизвестно, какая карта Ethernet будет задействована. Что ты мог разумно запросом будет «все запросы, заканчивающиеся на 'domain1.com', должны идти на 192.168.0.2, а все остальные запросы должны идти на 10.0.0.2».

И аналогично: «Все запросы обратного DNS, соответствующие 192.168.0.0/24, должны идти на 192.168.0.2, а остальные - на 10.0.0.2».

Как сказал larsks, Linux не поддерживает такую конфигурацию. Однако вы можете запустить свой собственный минимальный DNS-сервер, который реализует вышеуказанную логику и перенаправляет запросы на соответствующий «настоящий» DNS-сервер.

Я считаю, что dnsmasq может это сделать (см. Как настроить dnsmasq для пересылки нескольких DNS-серверов?). Но прежде чем я это обнаружил, я накатил свой собственный в 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()

Ответ на все ваши три вопроса сейчас systemd-разрешено (курсив мой):

Запросы поиска направляются на доступные DNS-серверы и интерфейсы LLMNR в соответствии со следующими правилами:

Поиск специального имени хоста «localhost» никогда не направляется в сеть. (Некоторые другие специальные домены обрабатываются таким же образом.)

Имена с одной меткой направляются на все локальные интерфейсы, способные к многоадресной IP-рассылке, с использованием протокола LLMNR. Поиски адресов IPv4 отправляются только через LLMNR на IPv4, а поисковые запросы адресов IPv6 отправляются только через LLMNR на IPv6. Поиск локально настроенного имени хоста и имени хоста «шлюза» никогда не направляется на LLMNR.

Имена с несколькими метками направляются на все локальные интерфейсы, на которых настроен DNS-сервер, а также на глобально настроенный DNS-сервер, если он есть. Поиск адресов из диапазона адресов локальной ссылки никогда не направляется в DNS.

Если поиск направлен на несколько интерфейсов, возвращается первый успешный ответ (таким образом эффективно объединяются зоны поиска на всех совпадающих интерфейсах). Если поиск завершился неудачно на всех интерфейсах, возвращается последний неудачный ответ.

На маршрутизацию поиска можно повлиять путем настройки доменных имен для каждого интерфейса. См. Systemd.network (5) для подробностей. Поиск имени хоста, оканчивающегося на одном из доменов интерфейса, направляется исключительно на соответствующие интерфейсы.