Configurar um servidor DNS por interface nic (eth0 / eth1)?

Question

Como você configuraria um servidor de nomes DNS por interface de NIC (eth0 vs eth1) no RHEL / Centos 6?

Por exemplo,

eth0 is on subnet 10.0.0.1/24

eth1 is on subnet 192.168.0.1/24

Any requests sent over eth0 should use DNS server 10.0.0.2.

Any requests sent over eth1 should use DNS server 192.168.0.2.

Eu adicionei:

DNS1: 10.0.0.2 > / etc / sysconfig / network-scripts / ifcfg-eth0

DNS1: 19.168.0.2 > / etc / sysconfig / network-scripts / ifcfg-eth1

No entanto, esses valores são ignorados e sempre são padronizados no arquivo resolv.conf "nameserver 10.0.0.2" Quando o eth0 está inativo, as conexões são enviadas através do eth1 ... no entanto, o DNS não pode mais ser resolvido, já que ele está tentando acessar o 10.0.0.2.

• Como posso fazer com que ele respeite as configurações de DNS no ifcfg em vez de um padrão para o resolv.conf?

• Ou como configuro um servidor de nomes DNS diferente para eth0 vs eth1?

• Existe uma maneira melhor de lidar com isso?

Atualizado

Temos duas VLANs, cada uma com seu próprio servidor DNS em sua respectiva sub-rede. Eles tratam de pesquisas de DNS local (example.loc, guest.app etc), bem como o encaminhamento quando necessário.

Estes são dois servidores separados em dois locais físicos separados. Se possível, prefiro não executar um servidor entre as duas sub-redes (uma lida com dados confidenciais).

Se a eth0 for desativada, preciso que a eth1 continue a fazer solicitações de DNS.

Pensei em adicionar dois IPs ao resolv.conf e, em seguida, deixá-lo fallover caso não consiga acessar o servidor na primeira sub-rede, mas isso parece deselegante (ter que esperar o tempo limite do primeiro servidor a cada consulta DNS quando eth0 está em baixo).

    

Answer 1

Você não pode fazer com facilidade o que deseja.

Or how do I configure a different DNS Name Server for eth0 vs eth1?

A pesquisa de nome para um nome de host acontece por meio de bibliotecas de sistema padrão e não é associada de forma alguma a uma "conexão" específica. Na verdade, no momento em que a consulta DNS acontece, não há conexão, porque seu aplicativo nem sequer descobriu o endereço ao qual vai se conectar (e é por isso que está usando o DNS no primeiro lugar).

How do I get it to respect the DNS settings in ifcfg rather than a default for resolv.conf?

O resolvedor Linux tem apenas uma configuração global única ( /etc/resolv.conf ). Não há configuração por interface, por domínio ou por conexão de qualquer tipo. As configurações em /etc/sysconfig/network-scripts/... são usadas apenas para preencher /etc/resolv.conf e, geralmente, se você especificar DNS1 e DNS2 nesses arquivos, a última interface a ser criada será o que você vê em /etc/resolv.conf .

Is there a better way of handling this?

Você pode nos dizer o que você está realmente tentando realizar? Podemos sugerir soluções melhores se você puder nos contar mais sobre sua situação específica.

    

Answer 2

Uma solicitação de DNS é basicamente

1. "qual é o endereço IP de host1.domain1.com" ou
2. "qual é o nome do host de 192.168.0.5."

Portanto, não há como saber na hora do "pedido" qual placa Ethernet será envolvida. O que você poderia perguntar razoavelmente seria "todas as solicitações terminadas em 'domain1.com' devem ir para 192.168.0.2 e todas as outras solicitações devem ir para 10.0.0.2."

E, da mesma forma, "Todas as solicitações de DNS reverso correspondentes a 192.168.0.0/24 devem ir para 192.168.0.2, e o restante deve ir para 10.0.0.2."

Como disse larsks, o Linux não suporta tal configuração. No entanto, você pode executar seu próprio servidor DNS mínimo que implementa a lógica acima e encaminha solicitações para o servidor DNS "real" apropriado.

Eu acredito que o dnsmasq pode fazer isso (veja Como configurar dnsmasq para encaminhar vários servidores DNS? ). Mas antes que eu descobrisse, eu fiz o meu em 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()

    

Answer 3

A resposta para todas as suas três perguntas agora é systemd-resolved (ênfase minha):

Lookup requests are routed to the available DNS servers and LLMNR interfaces according to the following rules:

Lookups for the special hostname "localhost" are never routed to the network. (A few other, special domains are handled the same way.)

Single-label names are routed to all local interfaces capable of IP multicasting, using the LLMNR protocol. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are only sent via LLMNR on IPv6. Lookups for the locally configured host name and the "gateway" host name are never routed to LLMNR.

Multi-label names are routed to all local interfaces that have a DNS sever configured, plus the globally configured DNS server if there is one. Address lookups from the link-local address range are never routed to DNS.

If lookups are routed to multiple interfaces, the first successful response is returned (thus effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces, the last failing response is returned.

Routing of lookups may be influenced by configuring per-interface domain names. See systemd.network(5) for details. Lookups for a hostname ending in one of the per-interface domains are exclusively routed to the matching interfaces.