nem todos os servidores de nomes são procurados

Question

Portanto, tenho vários servidores de nomes no meu /etc/resolv.conf , mas em relação à ordem em que aparecem, posso ou não resolver meus nomes de host da VPN corporativa: quando o DNS da VPN precede o meu local, eu sou capaz de resolver hosts corporativos. Quando meu servidor de nomes local é o primeiro, não sou capaz de resolver hosts corporativos.

Eu não acho que seja o comportamento intencional, já que todos os servidores de nomes devem ser testados, antes de jogarem em mim NXDOMAIN ?

Como eu faria todos os servidores de nomes ativos (não retornando na primeira falha), de modo que a ordem não importasse?

    

Answer 1

No DNS, a mensagem NXDOMAIN não é exatamente uma falha. É, ou pelo menos é suposto ser, informação perfeitamente válida que o domínio que você pediu não existe. Erros seriam algo como "Eu não sei" ou "Eu não tenho permissão para dizer" ou "[silêncio morto até o tempo limite]".

Em /etc/resolv.conf , a expectativa é que todos os servidores de nomes configurados sejam iguais. Ou seja, todos devem ter o mesmo acesso às informações de DNS: todos devem conseguir resolver qualquer nome que você precisa resolver.

Se isso não for verdade, o estilo tradicional /etc/resolv.conf do Unix será insuficiente. Muitos tentaram alcançar o que você procura alterando a ordem dos servidores DNS no arquivo, mas todos falharam: isso simplesmente não funciona dessa maneira.

Em vez disso, você normalmente precisará configurar um resolvedor / cache / proxy de DNS que possa ser configurado com algumas regras como "se o nome que você precisa resolver pertencer a um desses domínios", pergunte a um desses servidores; se o nome estiver em esse domínio, use esse servidor e, para todo o resto, use aqueles servidores. "

Por exemplo, você pode configurar dnsmasq e escrever algo assim em dnsmasq.conf :

no-resolv
server=/corporate-domain.com.example/10.1.2.3
rev-server=10.1.0.0/16,10.1.2.3
server=/google.com/8.8.8.8
server=9.9.9.9

Isso significaria:

• ignore /etc/resolv.conf (para evitar loops)
• use o servidor de nomes 10.1.2.3 para resolver quaisquer nomes no corporate-domain.com.example domain e quaisquer consultas inversas para endereços IP na rede 10.1.0.0/16
• use 8.8.8.8 para resolver quaisquer nomes no domínio google.com
• para todo o resto, use 9.9.9.9.

Quando você tiver o dnsmasq configurado dessa forma, configure o /etc/resolv.conf com nameserver 127.0.0.1 apenas para redirecionar todas as solicitações DNS locais para o local dnsmasq .

Se o seu servidor de nomes local for BIND, você poderá fazer o mesmo usando as declarações de zona de type forward :

zone "corporate-domain.com.example" {
    type forward;
    forwarders { 10.1.2.3; };
};

zone "1.10.in-addr.arpa" {
    type forward;
    forwarders { 10.1.2.3; };
}; 

zone "google.com" {
    type forward;
    forwarders { 8.8.8.8; 8.8.4.4; }; 
};

options {
    forwarders { 9.9.9.9; };
    forward only;
};

Isso alcança exatamente os mesmos resultados que a configuração dnsmasq acima, mas a sintaxe de configuração do BIND é um pouco mais detalhada.

    

Answer 2

Como uma alternativa para tentar alterar a ordem do DNS ou abordagens semelhantes:

Se você estiver controlando a VPN, em vez de permitir que o cliente decida com qual servidor DNS conversar (tipo), poderá interceptar solicitações DNS na porta 53 / UDP e na porta 53 / TCP e redirecionar essas solicitações para um servidor DNS de sua escolha.

Dessa forma, quando dentro da VPN, você pode forçar os clientes a conversarem com um servidor DNS capaz de resolver os hosts corporativos.

Exemplo: usei alguns servidores VPN com cerca de 400 usuários de BYOD VPN que usavam seus computadores pessoais e telefones.

Como nosso país se envolve em censura no nível do DNS, muitos inserem manualmente 8.8.8.8 como seus servidores preferidos de DNS.

Normalmente, os sintomas desses usuários eram que eles não conseguiam abrir endereços particulares corporativos.

Eu tive algumas escolhas:

• o helpdesk retiraria o endereço 8.8.8.8, e os usuários os inseririam dispostos ou distraídos quando desejassem visitar um endereço na lista negra, e nós estaríamos de volta ao quadrado 0;
• OU Eu poderia interceptar chamadas de DNS na VPN, independentemente dos endereços DNS em que eles estivessem falando, e redirecionar as consultas DNS para os endereços de servidores DNS corporativos.