Due sedi, una zona DNS privata: di chi sono i record?

Aggiungete un host nella sede verde, viene risolto per gli utenti verdi, e l’ufficio giallo riceve ancora NXDOMAIN. Non è un guasto della VPN né un resolver rotto; è una lacuna di proprietà nella zona privata. Due elenchi di record modificati separatamente non diventano un’unica zona solo perché le sedi possono raggiungersi. La soluzione è un piano di pubblicazione, non un’altra regola del firewall.

Il sintomo nomina il proprietario mancante

Ogni sede ha probabilmente un’esclusione locale, una voce Pi-hole o una riga dnsmasq aggiunta da qualcuno quando serviva un nome. Il record verde esiste solo sul resolver verde, quindi un client nella sede gialla interroga il proprio resolver e riceve un veritiero «nessun nome di questo tipo». Una risposta obsoleta appare diversa: l’host si è spostato, una sede ha aggiornato la sua copia e l’altra restituisce ancora l’indirizzo vecchio.

Nessuno dei due schemi si corregge a lungo svuotando la cache. La cache di un resolver inoltro è la copia di una risposta ricevuta una volta, non un’autorità che pubblica nuovi nomi, quindi una cache che funziona oggi non dice nulla sull’host di domani. La documentazione di BIND descrive separatamente i ruoli primario, secondario, ricorsivo e di inoltro proprio per questo motivo.

La domanda di progettazione è quindi stretta e ha risposta: chi può creare un record e come quel record raggiunge ogni resolver che deve rispondere per esso?

Opzione A: una zona autorevole con secondari

Eseguite un primario per internal.example.com e lasciate che i secondari supportati ottengano la zona in ogni sede. Il resolver ricorsivo di ciascuna sede interroga il proprio secondario locale, quindi le risposte provengono da una fonte autorevole anziché da una cache, e una modifica fatta una volta viene trasferita invece di essere ridigitata.

Questa disposizione richiede decisioni esplicite, facili da rinviare e costose da omettere. Chi può modificare la zona? Quali server possono trasferirla, e attraverso quali indirizzi? Cosa devono vedere i client mentre il tunnel tra le sedi è inattivo? Un secondario continua a rispondere dalla sua ultima copia, che di solito è il comportamento desiderato, ma deve essere una scelta dichiarata e non una sorpresa durante un’interruzione.

Limitate i trasferimenti di zona ai secondari noti per indirizzo e usate le firme di transazione dove l’implementazione le supporta. Un trasferimento aperto è una copia del vostro spazio dei nomi interno per chiunque raggiunga la porta.

Il costo è il coordinamento: un solo percorso di modifica, una sola revisione delle modifiche e una comprensione condivisa di chi è reperibile quando un record è sbagliato.

Opzione B: un sottodominio per sede

Delegate green.internal.example.com alla sede verde e yellow.internal.example.com alla sede gialla. Ogni sede diventa autorevole per i propri nomi e la zona padre porta solo i record di delega. La contesa su un singolo file scompare e un team locale può aggiungere un host senza attendere una modifica centrale.

La delega deve esistere nella zona padre, con record NS che puntano ai server autorevoli della sede. Un inoltro condizionale per il sottodominio è un’alternativa valida quando una delega completa non è pratica, ma è un’impostazione del resolver e non un fatto pubblicato, quindi ogni resolver ha bisogno della stessa regola.

Il costo si sposta invece di svanire: la zona padre ha ancora bisogno di un proprietario, e creare una nuova sede ora è una modifica in due punti invece di uno.

Fate seguire la scelta a ogni resolver

Fornite ai client il resolver approvato e il dominio di ricerca tramite la loro configurazione supportata, e assicuratevi che il resolver abbia una rotta VPN consentita verso qualsiasi server DNS remoto che debba interrogare. Anche le applicazioni hanno bisogno di rotte verso gli indirizzi privati che quelle risposte restituiscono, perché un nome corretto senza percorso resta una connessione interrotta.

Se Pi-hole fornisce la risoluzione locale, annotate quali record possiede e quali query inoltra. Due elenchi Pi-hole modificati separatamente continuano a non replicarsi. In Pi-hole v6, le righe dnsmasq personalizzate si impostano tramite opzioni lato host come TOML, CLI o variabili d’ambiente e non sono esposte tramite l’API; il caricamento dei file di /etc/dnsmasq.d/ è un’opzione separata, disattivata per impostazione predefinita.

Poi provate da entrambi i lati con un nome che dovrebbe essere visibile ovunque:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

La risposta SOA vi dice se il resolver giallo si ritiene autorevole, interroga un secondario o si limita a inoltrare. Sono progettazioni diverse con modalità di guasto diverse, e la risposta di solito identifica quale avete effettivamente distribuito.

Chiudete con tre casi di accettazione: un nome da ogni sede, un record modificato entro l’ora e il collegamento tra le sedi non disponibile. Una progettazione che supera solo il primo ha un piano di pubblicazione sulla carta e un’esclusione locale in produzione.