Substituindo algumas entradas DNS no BIND para redes internas


39

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

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 gateway. Outros hosts como "otherhost.example.com" ainda devem ser resolvidos pelo provedor DNS externo.

Consegui fazer isso nas 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 servidor DNS local e, por exemplo, ao consultar "otherhost.example.com" resultará em um erro.

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



11
"É possível configurar o BIND para substituir apenas algumas entradas de um domínio?" Não, não com BIND. Use um subdomínio.
Bortzmeyer

11
O Unbound parece fazer exatamente o que eu pedi, então estou definindo a resposta de Alnitak como a resposta aceita. Mas, no final, vou seguir o conselho de bortzmeyer e não substituir a entrada de domínio. Obrigado por todas as respostas!
Remy Blank

11
O Bind agora pode fazê-lo com a zona de política de resposta. Veja minha resposta abaixo. Outras soluções como Unbound não podem substituir CNAMEs. Com zonas de política no Bind, você não precisa fazer subdomínios; você pode simplesmente substituir registros individuais à vontade.
Florin Andrei

Respostas:


18

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 há necessidade de criar um subdomínio inteiro para isso, apenas o único registro que você deseja alterar), permite substituir CNAMEs, etc. Outras soluções, como Unbound, não podem substituir CNAMEs .

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html


EDIT: Vamos fazer isso corretamente então. Documentarei o que fiz com base no tutorial vinculado acima.

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

Vá para onde os arquivos de configuração do Bind são mantidos no seu sistema - aqui está /etc/bind. Crie lá um arquivo chamado db.rpzcom 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?

  • substitui o endereço IP pelo endereço www.some-website.comfalso 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.comoutro site chamadofake-hostname.com

Qualquer coisa que possa entrar em um arquivo de zona de ligação, você pode usar aqui.

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

Edite named.conf.locale adicione esta seção:

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

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

Edite named.conf.optionse em algum lugar da options { }seção adicione a response-policyopção:

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

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

Agora reinicie o Bind:

service bind9 restart

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

Se você precisar fazer alterações, basta editar db.rpze reiniciar o Bind novamente.

Bônus: se você deseja registrar consultas DNS no syslog, para acompanhar os procedimentos, editar named.conf.locale verificar se há uma loggingseção que inclua estas instruções:

logging {
    // stuff
    // already
    // there

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

Reinicie o Bind novamente e é isso.

Teste-o na máquina executando o Bind:

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

Se você executar o dig em uma máquina diferente, use @ o endereço IP do Bind-server em vez de @ 127.0.0.1

Usei essa técnica com grande êxito para substituir o CNAME de um site no qual eu 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 - portanto, ao conectar dispositivos ao SSID em execução no RPi, recebia as substituições de DNS necessárias para o teste.


11
Observe que o BIND RPZ não pode (ainda) substituir registros únicos por QTYPE - ele substituirá todos os registros de um nome de proprietário específico. Isso significa que, se você deseja substituir o registro A de um domínio, mas não o registro MX, por exemplo, não pode. Você também deve colocar o registro MX na zona RPZ e mantê-lo sincronizado com a zona real.
Alnitak

2
Obrigado por quebrar isso como você fez. Muito útil.
sruffell

Existem advertências? Estou tentando fazer isso em um pfsense, mas não posso "falsificar" nenhum resultado, ele ainda informa o endereço real. Acredito que segui as instruções à risca.
Lenne

@ Lenne Deve funcionar. Editei a postagem e adicionei uma sugestão para testar as alterações.
Florin Andrei

@ Lenne, o pacote pfSense BIND está embutido na GUI há cerca de um ano, portanto não é necessário mexer nas configurações. OP: pode valer a pena mencionar algumas das outras coisas que você pode fazer com uma RPZ, como responder com NXDOMAIN ou simplesmente descartar a resposta.
miken32 8/03

21

O servidor DNS recursivo não vinculado tem a capacidade de substituir registros de recursos individuais.

Veja as definições de configuração local-zonee local-datano manual , por exemplo:

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

A transparentconfiguração no local-zonediz para ele fazer pesquisas recursivas normais para qualquer nome não fornecido local-data.


11
Parece ser exatamente o que eu quero fazer, obrigado. Vou ler Unbound hoje à noite.
Remy Blank

Por outro lado, a sabedoria disso é bastante questionável. Ter um domínio internal.example.com seria mais claro.
Bortzmeyer

@Bortzmeyer - você pode estar certo, mas eu não imagino Wouter colocá-lo em apenas por diversão ;-)
Alnitak

3
@ortzmeyer, às vezes não há escolha. Exemplo: O SBS 2008 deve ter um único IP da LAN, mas precisa ser alcançado de fora usando um IP externo que o roteador está encaminhando. A Microsoft não permite duas placas de rede no SBS, nem dois IPs configurados na mesma placa. Se os servidores locais resolverem o nome DNS para o IP externo, o roteador precisará fazer o DNAT e o SNAT para os ips da LAN, e os logs no SBS mostrarão todo o acesso proveniente do IP do roteador, e isso está errado. Vou instalar unboundno meu próprio roteador, acho que a solução é muito melhor.
Cosmin Prund

Isso não responde à pergunta, pois ela é específica para BIND.
bzeaman

4

Você pode procurar no "dnsmasq", que permite fazer algumas coisas bem inteligentes com a resolução de ajustes.


Obrigado, boa dica. Pena que o dnsmasq não faz uma resolução recursiva, então ainda terei que executar o BIND em outra porta para isso (os servidores DNS do meu ISP são flakey).
Remy Blank

4

O que você procura é o DNS dividido, definido pela Webopedia como:

Em uma infraestrutura DNS dividida, você cria duas zonas para o mesmo domínio, uma a ser usada pela rede interna e a outra pela rede externa. O DNS dividido direciona hosts internos para um servidor de nomes de domínio interno para resolução de nomes e hosts externos são direcionados para um servidor de nomes de domínio externo para resolução de nomes.

Essencialmente, você precisará fazer uma cópia do seu arquivo de zona externa e apoiá-lo no servidor DNS interno, depois alterar ou adicionar os registros necessários especificamente para a sua rede interna. Essa é uma configuração bastante 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 de qual implementação de servidor DNS você usa. Na maioria das configurações, você terá um servidor DNS que serve a rede externa e um servidor diferente que serve a rede interna. Com o BIND, como possivelmente outras implementações, você pode ter as duas versões da zona no mesmo servidor através do uso da instrução "allow-query" na seção de zona do arquivo named.conf.

Outra possibilidade no BIND (e nunca tentei isso) seria definir o domínio example.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 pediria ao servidor DNS externo (conforme definido em "encaminhadores") uma resposta que não teria seus registros internos e retornaria uma resposta de falha. Em seguida, o servidor interno procuraria uma resposta. claro se isso funcionaria, mas é um pensamento.


Manter os dois arquivos de zona sincronizados será complicado, pois o externo é atualizado por meio de um cliente DNS dinâmico. Vou ler a declaração adiante, no entanto. Obrigado pela dica.
Remy Blank

Não, o encaminhamento do BIND não funcionará, será apenas para domínios desconhecidos, mas o servidor de nomes interno saberá sobre example.com, será autoritário para ele.
Bortzmeyer

11
Se estou lendo a documentação corretamente, a instrução "encaminhar primeiro" dentro de uma seção de zona deve solicitar ao BIND que procure uma resposta no encaminhador, mesmo para um domínio local autoritário, use as informações locais apenas se puder " Não receba uma resposta do remetente.
Justin Scott

Se você colocar um "encaminhar primeiro" global ', ele enviará as consultas ao encaminhador e, se não for respondido, tentará responder à consulta' (do documento), mas, se receber uma resposta, não tentará se resolver. Seria ótimo se você pudesse forçar a resolver se a resposta não é autoritativa ou mesmo se for um NXDOMAIN, mas o bind não tentará se obtiver uma resposta do encaminhador.
Pablo Martinez

3

No BIND, chego a esses resultados definindo uma zona usando o nome do host desejado. A abordagem é boa se você deseja substituir apenas 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 fica 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 DNS do ISP, obtenho o mesmo IP, mas se consultar override.example.com, obtenho resultados diferentes se o DNS da intranet (primário) estiver acessível.


2

Você já está no caminho certo.

Nos servidores DNS internos, você precisará definir uma zona para cada host de exceção imediatamente abaixo do "example.com". Para minimizar essas exceções, é 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 com autoridade para a zona "internal.example.com". (Depois de passar por pequenas operações, 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".)

Geralmente, é somente quando um host deve ser alcançável externa e internamente que as exceções que você descreve são criadas. Mesmo assim, convém usar "host1.example.com" de fora e "host1.internal.exemplo.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 de um servidor identificasse o servidor como "host1.example.com"; nesse caso, você deseja que esse seja o nome ao qual os clientes se conectam.


Sim, para os hosts "host1.example.com", ele já está funcionando bem. A parte difícil é lidar com o top-level "example.com", da mesma forma ...
Remy em branco

2

O uso do dnsmasq facilita bastante. http://www.thekelleys.org.uk/dnsmasq/doc.html Atua como servidor DNS, mas obtém respostas do servidor DNS local. O legal é que você pode substituir registros de domínio único sem mexer com arquivos de zona


2

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

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

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

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

4) reinicie o bind.

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


Mesmo processo feito por mim. encontre os detalhes em nosso wiki Stealth Name Server . Mas incapaz de resolver a dyn.dev.shahed.bizpartir de todo o mundo! Você poderia nos ajudar a resolver esse problema?
Md Shahed Hossain
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.