Como operar DNS com um hidden primary e secondaries públicos

O servidor onde edita as suas zonas DNS não precisa de responder à internet, e não devia. Um hidden primary guarda a cópia autoritativa e recebe alterações das suas pessoas e da sua automação. Um conjunto de secondaries públicos, que são os únicos servidores listados nos seus registos NS, responde a todas as queries. O primary pode receber patches, ser reiniciado ou atacado por ninguém, porque ninguém de fora sabe onde está. Este artigo mostra como construir isso com PowerDNS, as duas formas de levar os dados do primary aos secondaries, e as verificações que provam que o primary está mesmo escondido.

A forma do desenho

• Um primary numa rede privada, sem endereço público, nunca nomeado em registos NS ou SOA. Corre a API e a interface web que a sua equipa usa.
• Dois ou mais secondaries públicos em sites diferentes, idealmente em redes diferentes e em fornecedores ou plataformas diferentes, para que nenhuma falha isolada os derrube a todos.
• Um caminho privado do primary para cada secondary, apenas para replicação.
• Os secondaries continuam a responder se o primary desaparecer. Guardam uma cópia completa, pelo que um primary morto significa «sem alterações durante algum tempo», não «domínio offline».

Há duas formas de alimentar os secondaries. Ambas funcionam. Servem equipas diferentes.

Opção um: transferências de zona com NOTIFY e TSIG

Isto é DNS padrão e funciona com qualquer mistura de servidores DNS. O primary envia um NOTIFY quando uma zona muda. O secondary verifica o SOA serial e puxa a zona com AXFR ou IXFR.

No primary, em pdns.conf:

primary=yes
allow-axfr-ips=192.0.2.21/32,198.51.100.31/32
also-notify=192.0.2.21,198.51.100.31
only-notify=

Esses endereços são os endereços privados dos secondaries. Deixar only-notify vazio e listar os destinos em also-notify significa que o NOTIFY vai apenas para os seus secondaries, nunca para o que por acaso estiver nos registos NS.

Depois assine as transferências. Uma lista de IP permitidos, por si só, confia na rede. Uma chave TSIG prova que o pedido vem do seu secondary.

# on the primary
pdnsutil generate-tsig-key xfr hmac-sha256
pdnsutil activate-tsig-key example.com xfr primary
pdnsutil list-tsig-keys      # copy the secret

# on each secondary (pdns.conf contains: secondary=yes)
pdnsutil import-tsig-key xfr hmac-sha256 '<secret>'
pdnsutil create-secondary-zone example.com 203.0.113.10
pdnsutil activate-tsig-key example.com xfr secondary

Onde 203.0.113.10 é o endereço privado do primary. Para evitar criar todas as zonas à mão em todos os secondaries, o PowerDNS pode criá-las automaticamente quando o primary envia um NOTIFY para uma zona nova. Configure o primary como autoprimary em cada secondary:

pdnsutil add-autoprimary 203.0.113.10 ns1.example.net

e defina autosecondary=yes nos secondaries.

Opção dois: zonas native e replicação de base de dados

O PowerDNS também pode dispensar por completo as transferências DNS. Marque as zonas como NATIVE, guarde-as num backend MySQL, MariaDB ou PostgreSQL, e deixe a base de dados replicar os dados do primary para uma réplica só de leitura em cada secondary.

pdnsutil set-kind example.com native

Em cada secondary, o PowerDNS lê da sua base de dados réplica local, configurada só de leitura. A replicação corre apenas pela rede privada.

Porquê escolher isto:

• Cada alteração chega como uma linha, assim que a base de dados a envia. Não há serial para esquecer de incrementar nem NOTIFY para perder.
• O AXFR pode ser desligado em todo o lado, pelo que não há nenhuma interface de transferência para proteger.
• As zonas novas aparecem nos secondaries automaticamente, porque também são linhas.
• As chaves DNSSEC replicam juntamente com os registos, e cada secondary assina as respostas por si.

Porque não: todos os secondaries têm de correr o mesmo backend, e passa a operar replicação de base de dados, que precisa da sua própria monitorização de atraso e de threads quebradas. Se os seus secondaries incluírem DNS de outro fabricante, as transferências são a única opção.

Nós construímos os nossos com zonas native e replicação de base de dados, porque remove por completo a superfície de transferência e faz da base de dados a única fonte de verdade, e a mais óbvia.

DNSSEC com um hidden primary

As duas opções suportam assinatura:

• Com transferências, assine no primary. Os secondaries recebem a zona assinada e servem-na como dados presigned. O PowerDNS marca a zona como PRESIGNED automaticamente quando transfere registos assinados.
• Com replicação de base de dados, as chaves vivem na base de dados, pelo que cada secondary assina ao vivo com as mesmas chaves e responde de forma idêntica.

Em qualquer dos casos, teste a validação a partir de fora com um resolver validante:

dig +dnssec example.com SOA @1.1.1.1
delv example.com SOA

O delv deve reportar «fully validated».

Nomeie os servidores certos

O sentido de um hidden primary perde-se se o seu nome escapar para os registos que o mundo lê.

• Os registos NS listam apenas os secondaries públicos.
• O campo SOA MNAME nomeia um secondary público, não o primary. No PowerDNS, default-soa-content define-o para as zonas novas. Corrija as existentes com pdnsutil edit-zone.
• O glue no registo aponta apenas para os endereços públicos dos secondaries.

Algumas ferramentas põem o nome do próprio servidor no SOA MNAME por omissão. Verifique-o em todas as zonas, não só na primeira.

Tranque cada função

• Coloque à frente de cada secondary público um front end que entende DNS, como o dnsdist, para recusar tipos de query que permitem amplificação, limitar o ritmo, e descartar queries para zonas que não serve.
• Nos secondaries, recuse NOTIFY de qualquer origem que não o primary, e recuse pedidos AXFR vindos da internet.

Verifique a partir de fora

# NS and SOA name only public secondaries
dig +short NS example.com
dig +short SOA example.com

# Every secondary has the same serial
for ns in $(dig +short NS example.com); do
  printf '%s ' "$ns"; dig +short SOA example.com @"$ns" | awk '{print $3}'
done

# Transfers are refused from the internet
dig AXFR example.com @ns1.example.net

# The primary does not answer from outside (expect a timeout)
dig example.com SOA @<primary-address> +time=2 +tries=1

Corra a comparação de serials continuamente, não uma vez. Um secondary que deixou de receber atualizações continua a responder com confiança com dados antigos. O único sintoma é um serial que fica para trás. Alerte sobre isso, e alerte se o nome ou o endereço do primary alguma vez aparecer num registo NS ou SOA.

Em resumo

O primary é onde edita, os secondaries são onde o mundo pergunta, e os dois só se encontram numa rede privada. Escolha transferências se mistura fabricantes de DNS, replicação de base de dados se não quer nenhuma superfície de transferência. Nomeie apenas os secondaries, assine a zona, e vigie os serials.

Construímos e operamos clusters PowerDNS desta forma para clientes que querem ser donos do seu DNS. Se está a planear um, teremos todo o gosto em ajudar.

CTA

Fale com um engenheiro

Related

Relacionados: DNS autoritativo e recursivo em PowerDNS · Authoritative DNS e reverse DNS, operados como infraestrutura