DNS: como obter o servidor local para sobrepor os resultados ao servidor autoritativo?

Question

Eu tenho um domínio para o qual eu controle o DNS e está hospedado na internet. Eu também tenho uma rede interna NAT (192.168.0.0/24) que tem acesso à Internet, e que eu também controlo. Nesta rede interna, também tenho um resolvedor de DNS. O software DNS em ambos é PowerDNS.

O que eu quero ser capaz de fazer é que o resolvedor de DNS na rede interna possa adicionar / alterar registros de consultas e resultados que vêm do servidor autoritativo. Por exemplo, o servidor autoritativo pode ter um único registro para animal.exemplo.com:

animal.example.com.    IN    AAAA    2001:140:283::1

No entanto, eu gostaria que, quando os clientes internos fizessem uma pesquisa de DNS para animal.example.com, eles pudessem recuperar o seguinte:

animal.example.com.    IN    AAAA    2001:140:283::1
animal.example.com.    IN    A       192.168.0.2

Obviamente, eu poderia configurar o servidor DNS interno para fingir ser autoritativo para example.com, mas isso exigiria um bom esforço para manter o servidor DNS principal e o servidor DNS interno em sincronia com os registros que são o mesmo entre os dois. Se o servidor DNS interno pudesse de alguma forma se tornar um escravo do servidor DNS principal, mas também tivesse a provisão de adicionar seus próprios resultados, isso seria ideal.

Isso é possível?

    

Answer 1

Na verdade, se eu tivesse para fazer isso, eu usaria um Lua Script com o recursor que manipula os dados no postresolve.

Se eu realmente recomendar algo diferente: basta usar uma Zona autoritária separada, como internal.example.com, onde você usa AXFR example.com, a partir dos Servidores autoritativos, e simplesmente anexe seus dados RFC1918 locais.

Dessa forma, você ainda pode depurar a Zona autoritária como se ela estivesse na Internet a partir de sua LAN e usar os dados internos.

Sobre o PowerDNS Recursor Lua Scripting: link

    

Answer 2

O que eu acho que você quer é uma configuração de DNS de horizonte dividido, no entanto, o PowerDNS não suporta diretamente isso (diferente de Bind ou DJBDNS). A resposta oficial sobre isso do autor está aqui: link

Eu nunca achei o DNS split-horizon particularmente confuso, especialmente se os arquivos estiverem dispostos claramente no sistema de arquivos, por exemplo. ./master-interal/domain.com ./master-external/domain.com

A única opção que eles estão sugerindo é ter duas instâncias diferentes do PowerDNS em execução em um servidor escutando em portas diferentes. Eu acho que você iria então alavancar iptables para redirecionar o tráfego para a porta 53 para qualquer instância relevante.

    

Answer 3

Eu recomendo strongmente que você não siga esse caminho, pois é extremamente confuso, complexo e difícil de gerenciar. Em vez disso, você deve configurar um domínio interno separado, como inside.example.com . Então, se o seu servidor dns externo também estiver na sua rede interna, você deve configurá-lo para ser autoritativo para ambos os domínios. No entanto, se o seu servidor de DNS externo não estiver na sua rede interna, você deverá configurar o seu servidor de DNS interno para ser autoritativo para o inside.example.com. Em seguida, o seu servidor DNS interno deve encaminhar todas as outras solicitações para o servidor de DNS externo.

Eu percebo que a desvantagem disso é que você tem que mudar o domínio em todas as suas máquinas internas, mas fazer esse trabalho inicial agora economizará muita confusão mais tarde.

    

Answer 4

Dividir DNS por meio do Recursor do PowerDNS

Depois de procurar por algum tempo no meu Fedora 20, pareço ter feito funcionar. Não encontrei um tutorial completo em nenhum lugar, portanto, um breve resumo para uma configuração mínima:

Queremosresolverwebserver.dyndns.orgparaacessarumserviçodaweb,tantodaInternetquantodaLAN.

DaInternet

AmáquinaanaInternetresolvewebserver.dyndns.orgparaoendereçoIPIPisp.OBehingIPispéumroteadorcomNAT,queencaminhaaporta80paraoIPdaLANIPx,disponibilizandoumserviçodaWebnaInternet.

IssoéfeitonaturalmenteregistrandooendereçoIPIPispnoservidordenomesautoritativoparaodomíniodyndns.org,que,nocasodeumserviçocomooDynDns,éfeitousandoddclientrodandonoroteadorouemalgumlugarnaLAN,eportantosemmaisinteresseaqui.

DaLAN

AmáquinabnaLANresolvewebserver.dyndns.orgparaoendereçoIPIPx,paraqueoserviçodaWebsetornedisponívelnaLANdiretamente.Alémdisso,assumindoquetodasasmáquinasnaLANsãonomeadasaolongodaslinhasdebar.localdomain,onomewebserver.localdomaintambémdeveserresolvidoparaIPx.Nóstambémqueremosterumapesquisareversaparaumaboamedida,resolvendoIPxparawebserver.dyndns.orgdentrodaLAN(naInternet,IPxresolvenaturalmenteparanadaeIPispresolvealgumacadeiaarbitráriageradapeloISP.

Assumimosquepdns-recursorestásendoexecutadoemumamáquinaseparadacomIPIPdns,mastambémpodemostê-loemexecuçãonoservidordaWeb(nomesmoendereçoIPIPxouemumalias),outemapenasumaúnicamáquinanaLAN.

Amáquina"b" pode ser configurada estaticamente ou dinamicamente via DHCP; veja dhclient e dnsmasq e possivelmente avahi . NetworkManager também entra aqui porque pode reescrever /etc/resolv.conf ; por enquanto, assuma a configuração estática.

Além disso, assuma:

IPx = 192.168.1.1
IPdns = 192.168.1.2
IPbar = 192.168.1.3

Então:

/etc/resolv.conf em qualquer máquina:

nameserver 192.168.1.2
domain localdomain

Configuração para pdns-recursor :

/etc/pdns-recursor/recursor.conf basicamente reduz para:

setuid=pdns-recursor
setgid=pdns-recursor
allow-from=127.0.0.0/8, 192.168.1.0/8, ::1/128, fe80::/10
auth-zones=webserver.dyndns.org=/etc/pdns-recursor/[webserver.dyndns.org].zone, localdomain=/etc/pdns-recursor/[localdomain].zone, 168.192.in-addr.arpa=/etc/pdns-recursor/[168.192.in-addr.arpa].zone
local-address=192.168.1.2

As referências acima restringem muito os arquivos de zona (seus nomes reais não são importantes):

Em /etc/pdns-recursor/[168.192.in-addr.arpa].zone (observe a falta de um ponto no final do nome do registro - é um nome relativo não absoluto: 1.1 significa 1.1.168.192.in-addr.arpa ). Isso funciona com ou sem o "IN".

1.1   IN   PTR     webserver.dyndns.org.
2.1   IN   PTR     dns.localdomain.
3.1   IN   PTR     b.localdomain.

Em /etc/pdns-recursor/[webserver.dyndns.org].zone (anote o ponto no final do nome do registro - é um nome absoluto e não relativo)

webserver.dyndns.org.  IN  A  192.168.1.1

Em /etc/pdns-recursor/[localdomain].zone

webserver    IN  A  192.168.1.1
dns          IN  A  192.168.1.2
b            IN  A  192.168.1.3

Após a reinicialização de pdns-recursor , on pode testar usando dig executando estes comandos:

PDNS=192.168.1.2

# Test unknwon domain resolution and webserver resolution    
dig @$PDNS www.cnn.com | grep -A1 ";; ANSWER SECTION:"                  
dig @$PDNS webserver.dyndns.org | grep -A1 ";; ANSWER SECTION:"

# Test responses for localdomain
dig @$PDNS unknown.localdomain | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS webserver.localdomain | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS b.localdomain | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS dns.localdomain A | grep -A1 ";; ANSWER SECTION:"

# Test responses for localdomain if the domain is omitted
dig +search @$PDNS webserver | grep -A1 ";; ANSWER SECTION:"

# Test reverse resolution
dig @$PDNS -x 192.168.1.1 | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS -x 192.168.1.2 | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS -x 192.168.1.3 | grep -A1 ";; ANSWER SECTION:"
dig @$PDNS -x 192.168.1.4 | grep -A1 ";; ANSWER SECTION:"

    

Answer 5

Use PipeBackend no PowerDNS. Eu criei vários sistemas no Python.

PipeBackend:

The PipeBackend is primarily meant for allowing rapid development of new backends without tight integration with PowerDNS. It allows end-users to write PDNS backends in any language.