To lokasjoner, én privat DNS-sone: hvem eier oppføringene?

Du legger til en vert på den grønne lokasjonen, den løses opp for grønne brukere, og det gule kontoret får fortsatt NXDOMAIN. Det er ikke en VPN-feil og ikke en ødelagt resolver; det er et eierskapshull i den private sonen. To uavhengig redigerte oppføringslister blir ikke én sone bare fordi lokasjonene kan nå hverandre. Løsningen er en publiseringsplan, ikke nok en brannmurregel.

Symptomet navngir den manglende eieren

Hver lokasjon har sannsynligvis en lokal overstyring, en Pi-hole-oppføring eller en dnsmasq-linje som noen la til da et navn var nødvendig. Den grønne oppføringen finnes bare på den grønne resolveren, så en klient på gul spør sin egen resolver og får et sannferdig "ingen slik navn". Et utdatert svar ser annerledes ut: verten flyttet, én lokasjon oppdaterte kopien sin, og den andre returnerer fortsatt den gamle adressen.

Ingen av mønstrene løses lenge ved å tømme cachen. Cachen til en videresendende resolver er en kopi av et svar den en gang mottok, ikke en autoritet som publiserer nye navn, så en cache som virker i dag sier ingenting om morgendagens vert. BIND-dokumentasjonen beskriver primær-, sekundær-, rekursiv- og videresenderrollene hver for seg nettopp av denne grunnen.

Så designspørsmålet er smalt og besvarbart: hvem kan opprette en oppføring, og hvordan når den oppføringen hver resolver som må svare på den?

Alternativ A: én autoritativ sone med sekundære

Kjør en primær for internal.example.com og la støttede sekundære hente sonen på hver lokasjon. Hver lokasjons rekursive resolver spør sin lokale sekundære, så svarene kommer fra en autoritativ kilde i stedet for en cache, og en endring som er gjort én gang overføres i stedet for å skrives på nytt.

Den ordningen krever eksplisitte beslutninger som er lette å utsette og dyre å hoppe over. Hvem kan redigere sonen? Hvilke servere har lov til å overføre den, og over hvilke adresser? Hva skal klientene se mens tunnelen mellom lokasjonene er nede? En sekundær fortsetter å svare fra sin siste kopi, noe som vanligvis er ønsket atferd, men det må være et uttalt valg og ikke en overraskelse under en avbrudd.

Begrens soneoverføringer til de kjente sekundære etter adresse og bruk transaksjonssignaturer der implementasjonen støtter dem. En åpen overføring er en kopi av ditt interne navnerom for alle som når porten.

Prisen er koordinering: én redigeringsvei, én endringsgjennomgang og en felles forståelse av hvem som har vakt når en oppføring er feil.

Alternativ B: et subdomene per lokasjon

Deleger green.internal.example.com til den grønne lokasjonen og yellow.internal.example.com til den gule. Hver lokasjon blir autoritativ for sine egne navn, og foreldresonen bærer bare delegasjonsoppføringene. Striden om én fil forsvinner, og et lokalt team kan legge til en vert uten å vente på en sentral endring.

Delegasjonen må finnes i foreldresonen, med NS-oppføringer som peker på lokasjonens autoritative servere. En betinget videresending for subdomenet er et gyldig alternativ når full delegasjon er upraktisk, men det er en resolverinnstilling og ikke et publisert faktum, så hver resolver trenger den samme regelen.

Prisen flytter seg i stedet for å forsvinne: foreldresonen trenger fortsatt en eier, og å opprette en ny lokasjon er nå en endring to steder i stedet for ett.

La hver resolver følge valget

Gi klientene den godkjente resolveren og søkedomenet gjennom deres støttede konfigurasjon, og sørg for at resolveren har en tillatt VPN-rute til enhver ekstern DNS-server den må spørre. Applikasjoner trenger også ruter til de private adressene som disse svarene returnerer, fordi et korrekt navn uten en vei fortsatt er en brutt forbindelse.

Hvis Pi-hole leverer lokal oppslag, skriv ned hvilke oppføringer den eier og hvilke spørringer den videresender. To uavhengig redigerte Pi-hole-lister replikerer fortsatt ikke. I Pi-hole v6 settes egendefinerte dnsmasq-linjer gjennom vertssidealternativer som TOML, CLI eller miljøvariabler og eksponeres ikke gjennom API-et; lasting av /etc/dnsmasq.d/-filer er et separat alternativ som er slått av som standard.

Test deretter fra begge sider med et navn som bør være synlig overalt:

$ 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

SOA-svaret forteller deg om den gule resolveren tror den er autoritativ, spør en sekundær eller bare videresender. Dette er forskjellige design med forskjellige feilmoduser, og svaret identifiserer vanligvis hvilken du faktisk har rullet ut.

Avslutt med tre aksepttilfeller: ett navn fra hver lokasjon, én oppføring endret innen timen og forbindelsen mellom lokasjonene utilgjengelig. Et design som bare består det første har en publiseringsplan på papiret og en lokal overstyring i produksjon.