Substituindo algumas entradas de DNS no BIND para redes internas

Question

Eu tenho uma rede interna com um servidor DNS rodando BIND, conectado à internet através de um único gateway. Meu domínio "example.com" é gerenciado por um provedor de DNS externo. Algumas das entradas nesse domínio, como "host1.example.com" e "host2.example.com", bem como a entrada de nível superior "example.com", apontam para o endereço IP público do gateway. / p>

Gostaria que os hosts localizados na rede interna resolvessem "host1.example.com", "host2.example.com" e "example.com" para endereços IP internos em vez do endereço do gateway. Outros hosts como "otherhost.example.com" ainda devem ser resolvidos pelo provedor de DNS externo.

Eu consegui fazer isso para as entradas host1 e host2, definindo duas zonas de entrada única no BIND para "host1.example.com" e "host2.example.com". No entanto, se eu adicionar uma zona para "example.com", todas as consultas para esse domínio serão resolvidas pelo meu servidor DNS local e, por exemplo, consultar "otherhost.example.com" resulta em um erro.

É possível configurar o BIND para substituir apenas algumas entradas algumas de um domínio e para resolver o resto recursivamente?

    

Answer 1

O melhor método é através da zona de política de resposta no Bind 9.8.1 ou mais recente. Ele permite que você substitua registros únicos em zonas arbitrárias (e não é necessário criar um subdomínio inteiro para isso, apenas o único registro que você deseja alterar), ele permite substituir CNAMEs etc. Outras soluções, como Unbound não podem substituir CNAMEs .

link

EDITAR: Vamos fazer isso corretamente então. Vou documentar o que fiz com base no tutorial vinculado acima.

Meu sistema operacional é o Raspbian 4.4 para o Raspberry Pi, mas a técnica deve funcionar sem qualquer alteração no Debian e no Ubuntu, ou com um mínimo de alterações em outras plataformas.

Vá para onde seus arquivos de configuração do Bind são mantidos em seu sistema - aqui está em /etc/bind . Crie lá um arquivo chamado db.rpz com o seguinte conteúdo:

$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2015112501   ; serial
                          1h           ; refresh
                          30m          ; retry
                          1w           ; expiry
                          30m)         ; minimum
                   IN     NS    localhost.

localhost       A   127.0.0.1

www.some-website.com    A        127.0.0.1

www.other-website.com   CNAME    fake-hostname.com.

O que isso faz?

• ele substitui o endereço IP para www.some-website.com pelo endereço falso 127.0.0.1 , enviando efetivamente todo o tráfego desse site para o endereço de loopback
• envia tráfego para www.other-website.com para outro site chamado fake-hostname.com

Qualquer coisa que possa entrar em um arquivo de zona Bind que você pode usar aqui.

Para ativar essas alterações, há mais algumas etapas:

Edite named.conf.local e adicione esta seção:

zone "rpz" {
  type master;
  file "/etc/bind/db.rpz";
};

O tutorial linkado acima diz para você adicionar mais coisas ao zone "rpz" { } , mas isso não é necessário em configurações simples - o que eu mostrei aqui é o mínimo para que ele funcione no seu resolvedor local.

Edite named.conf.options e algures na secção options { } adicione a opção response-policy :

options {
  // bunch
  // of
  // stuff
  // please
  // ignore

  response-policy { zone "rpz"; };
}

Agora reinicie o Bind:

service bind9 restart

É isso. O servidor de nomes deve começar a substituir esses registros agora.

Se você precisar fazer alterações, edite apenas db.rpz e reinicie o Bind novamente.

Bônus: se você quiser registrar as consultas DNS no syslog, pode ficar de olho nos procedimentos, editar named.conf.local e verificar se há uma seção logging que inclua estas declarações:

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

Reinicie o Bind novamente e pronto.

Teste-o na máquina que executa o Bind:

dig @127.0.0.1 www.other-website.com. any

Se você executar uma escavação em uma máquina diferente, apenas use @ the-ip-address-of-Bind-server em vez de @ 127.0.0.1

Eu usei essa técnica com grande sucesso para substituir o CNAME por um site em que estava trabalhando, enviando-o para um novo balanceador de carga da AWS que eu estava testando. Um Raspberry Pi foi usado para executar o Bind, e o RPi também foi configurado para funcionar como um roteador WiFi - assim, conectando dispositivos ao SSID em execução no RPi, eu obteria as substituições de DNS que eu precisava para testar.

    

Answer 2

O servidor DNS recursivo Não consolidado tem a capacidade de substituir registros de recursos individuais.

Veja as definições de configuração local-zone e local-data no manual , por exemplo:

local-zone: "example.com." transparent
local-data: "foo.example.com. IN A 192.168.1.1"

A configuração transparent no local-zone diz para fazer pesquisas recursivas normais para quaisquer nomes não fornecidos com local-data .

    

Answer 3

Você pode querer olhar para o "dnsmasq", que permite fazer algumas coisas bem inteligentes com resolução de ajustes.

    

Answer 4

O que você está procurando é o DNS dividido, que é definido por Webopedia como:

In a split DNS infrastructure, you create two zones for the same domain, one to be used by the internal network, the other used by the external network. Split DNS directs internal hosts to an internal domain name server for name resolution and external hosts are directed to an external domain name server for name resolution.

Essencialmente, você precisará fazer uma cópia do seu arquivo de zona externa e apoiá-lo em seu servidor DNS interno, em seguida, alterar ou adicionar os registros necessários especificamente para a sua rede interna. Essa é uma configuração bem comum, embora possa ser difícil manter os registros "externos" sincronizados entre os dois servidores DNS. Se você criar ou alterar um registro no servidor público, ele também precisará ser criado ou alterado no servidor privado.

Isso pode ser implementado independentemente da implementação do servidor DNS que você usa. Na maioria das configurações, você terá um servidor DNS que serve a rede externa e outro que serve a rede interna. Com o BIND, como possivelmente outras implementações, você pode ter ambas as versões da região no mesmo servidor através do uso da instrução "allow-query" dentro da seção de zona do arquivo named.conf.

Outra possibilidade no BIND (e eu nunca tentei isso) seria definir seu domínio exemplo.com no servidor DNS interno com apenas os registros que você usa internamente. Em seguida, defina uma instrução "forward" com o argumento "first" (em conjunto com "forwarders"). Em teoria, isso iria perguntar ao servidor DNS externo (como definido em "encaminhadores" para uma resposta, que não teria seus registros internos e retornaria uma resposta de falha. Em seguida, o servidor interno procuraria por uma resposta. certeza se isso funcionaria, mas é um pensamento.

    

Answer 5

No BIND, chego a esses resultados definindo uma zona usando o nome do host desejado. A abordagem é boa se você quiser apenas substituir alguns hosts.

Minha declaração de zona é assim:

zone "override.example.com" {
        type master;
        notify no;
        file "zone-config/override.example.com";
};

Minha definição de zona é assim:

$TTL 4H
@       IN      SOA     ns.override.example.com.    root.override.example.com. (
                        2009072215      ; Serial
                        3600            ; Refresh
                        600             ; Retry
                        604800          ; Expire
                        3600    )       ; Minimum
;
                NS      ns
        IN      NS      ns.override.example.com.
        IN      A       192.168.1.100
ns      IN      A       192.168.1.100

Portanto, se eu consultar example.com no DNS da intranet e no ISP, recebo o mesmo IP, mas, se eu consultar override.example.com, obtenho resultados diferentes se o DNS da intranet (principal) estiver acessível.

    

Answer 6

Você já está no caminho certo.

Nos seus servidores DNS internos, você precisará definir uma zona para cada host de exceção imediatamente abaixo do "exemplo.com". Para minimizar essas exceções, é uma prática comum nomear todas as máquinas internas "hosta.internal.example.com", com o servidor DNS enviando a maioria das consultas para servidores DNS externos, mas autoritativo para a zona "internal.example.com". (Uma vez que você passa por uma pequena operação, geralmente há um servidor DNS para o qual os clientes são direcionados e um DNS autoritativo separado para o qual esses servidores são direcionados para "internal.example.com".)

Normalmente, é somente quando um host deve estar acessível externamente e internamente que as exceções que você descreve são criadas. Mesmo assim, você pode querer usar "host1.example.com" de fora e "host1.internal.example.com" de dentro. Os hosts internos são configurados para procurar nomes em "internal.example.com". Há situações em que o que você já está fazendo é apropriado, como se o certificado para um servidor identificasse o servidor como "host1.example.com", caso em que você deseja que seja o nome ao qual os clientes se conectam.

    

Answer 7

Use dnsmasq torna isso realmente fácil. link Atua como o servidor dns, mas obtém respostas do servidor dns local. O bom é que você pode substituir registros de domínio único sem mexer com arquivos de zona

    

Answer 8

Na verdade, há outra maneira, ainda que talvez um pouco diferente, de fazer isso. Eu tenho a mesma situação, eu tenho um domínio que é usado externamente e internamente, e eu tenho hosts externos estáticos e dinâmicos. Os únicos realmente dolorosos são os dinâmicos externos. A solução talvez não seja a mais elegante, mas implementável com um pequeno script. Principalmente eu estou fazendo meu próprio script DNS dinâmico com a API do meu provedor de DNS dinâmico, eu corro este script pelo cron, a cada 5 minutos:

1) obtenha meu IP externo. mudou? Sem saída.

2) IP alterado, chamar API do dyndns-provider, com o novo endereço IP,

3) sed o db.mydomain.com com o IP externo

4) reiniciar o bind.

Funciona de maneira muito confiável para minha rede doméstica