Come gestire il DNS con un primary nascosto e secondary pubblici

Il server su cui modificate le vostre zone DNS non ha bisogno di rispondere a internet, e non dovrebbe farlo. Un primary nascosto detiene la copia autoritativa e riceve le modifiche dalle vostre persone e dalla vostra automazione. Un insieme di secondary pubblici, che sono gli unici server elencati nei vostri record NS, risponde a ogni query. Il primary può essere aggiornato, riavviato o attaccato da nessuno, perché nessuno all'esterno sa dove si trova. Questo articolo mostra come costruirlo con PowerDNS, i due modi per portare i dati dal primary ai secondary, e i controlli che provano che il primary è davvero nascosto.

La forma del progetto

• Un primary su una rete privata, senza indirizzo pubblico, mai nominato nei record NS o SOA. Esegue l'API e l'interfaccia web che il vostro team usa.
• Due o più secondary pubblici in siti diversi, idealmente su reti diverse e provider o piattaforme diversi, così nessun singolo guasto li porta giù tutti.
• Un percorso privato dal primary a ogni secondary, solo per la replica.
• I secondary continuano a rispondere se il primary sparisce. Detengono una copia completa, quindi un primary morto significa «nessuna modifica per un po'», non «dominio offline».

Ci sono due modi per alimentare i secondary. Entrambi funzionano; si addicono a team diversi.

Opzione uno: zone transfer con NOTIFY e TSIG

Questo è DNS standard e funziona con qualunque mix di server DNS. Il primary invia un NOTIFY quando una zona cambia; il secondary controlla il serial del SOA e preleva la zona con AXFR o IXFR.

Sul primary, in 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=

Quegli indirizzi sono gli indirizzi privati dei secondary. Lasciare only-notify vuoto ed elencare le destinazioni in also-notify significa che il NOTIFY va solo ai vostri secondary, mai a qualunque cosa si trovi nei record NS.

Poi firmate i trasferimenti. Una allow list di IP da sola si fida della rete; una chiave TSIG prova che la richiesta viene dal vostro 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

Dove 203.0.113.10 è l'indirizzo privato del primary. Per evitare di creare a mano ogni zona su ogni secondary, PowerDNS può crearle automaticamente quando il primary invia un NOTIFY per una nuova zona. Configurate il primary come autoprimary su ogni secondary:

pdnsutil add-autoprimary 203.0.113.10 ns1.example.net

e impostate autosecondary=yes sui secondary.

Opzione due: zone native e replica del database

PowerDNS può anche saltare del tutto i trasferimenti DNS. Marcate le zone come NATIVE, tenetele in un backend MySQL, MariaDB o PostgreSQL, e lasciate che il database replichi i dati del primary su una replica in sola lettura su ogni secondary.

pdnsutil set-kind example.com native

Su ogni secondary, PowerDNS legge dal suo database replica locale, configurato in sola lettura. La replica gira solo sulla rete privata.

Perché sceglierla:

• Ogni modifica arriva come una riga, non appena il database la spedisce. Non c'è un incremento del serial da dimenticare e nessun NOTIFY da perdere.
• AXFR può essere spento ovunque, quindi non c'è alcuna interfaccia di trasferimento da proteggere.
• Le nuove zone compaiono sui secondary automaticamente, perché anche loro sono righe.
• Le chiavi DNSSEC si replicano insieme ai record, e ogni secondary firma le risposte da sé.

Perché no: ogni secondary deve eseguire lo stesso backend, e ora state gestendo una replica di database, che ha bisogno del proprio monitoraggio per lag e thread interrotti. Se i vostri secondary includono il DNS di un altro vendor, i trasferimenti sono l'unica opzione.

Noi costruiamo i nostri con zone native e replica del database, perché elimina completamente la superficie di trasferimento e fa del database l'unica, ovvia fonte di verità.

DNSSEC con un primary nascosto

Entrambe le opzioni supportano la firma:

• Con i trasferimenti, firmate sul primary. I secondary ricevono la zona firmata e la servono come dati presigned; PowerDNS marca la zona PRESIGNED automaticamente quando trasferisce record firmati.
• Con la replica del database, le chiavi vivono nel database, quindi ogni secondary firma dal vivo con le stesse chiavi e risponde in modo identico.

In entrambi i casi, testate la validazione dall'esterno con un resolver validante:

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

delv deve riportare «fully validated».

Nominate i server giusti

Lo scopo di un primary nascosto si perde se il suo nome finisce nei record che il mondo legge.

• I record NS elencano solo i secondary pubblici.
• Il campo MNAME del SOA nomina un secondary pubblico, non il primary. In PowerDNS, default-soa-content lo imposta per le nuove zone; correggete quelle esistenti con pdnsutil edit-zone.
• I glue presso il registry puntano solo agli indirizzi pubblici dei secondary.

Alcuni strumenti mettono per default il nome del server stesso nel MNAME del SOA. Controllatelo su ogni zona, non solo sulla prima.

Chiudete ogni ruolo

• Mettete un front end consapevole del DNS come dnsdist davanti a ogni secondary pubblico, per rifiutare i tipi di query da amplificazione, limitare il rate e scartare le query per zone che non servite.
• Sui secondary, rifiutate i NOTIFY da qualunque posto che non sia il primary, e rifiutate le richieste AXFR da internet.

Controllatelo dall'esterno

# 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

Eseguite il confronto dei serial di continuo, non una volta sola. Un secondary che ha smesso di ricevere aggiornamenti continua a rispondere con sicurezza con dati vecchi; l'unico sintomo è un serial che resta indietro. Impostate un allarme su questo, e un allarme se il nome o l'indirizzo del primary compare mai in un record NS o SOA.

In breve

Il primary è dove modificate, i secondary sono dove il mondo chiede, e i due si incontrano solo su una rete privata. Scegliete i trasferimenti se mescolate vendor DNS, la replica del database se non volete alcuna superficie di trasferimento. Nominate solo i secondary, firmate la zona, e tenete d'occhio i serial.

Costruiamo e gestiamo cluster PowerDNS in questo modo per clienti che vogliono possedere il proprio DNS. Se ne state pianificando uno, siamo lieti di aiutarvi.

cta: Parla con un ingegnere

Related

• /what-we-do/platforms/dns/
• /what-we-do/network/dns/