To lokasjonar, éi privat DNS-sone: kven eig oppføringane?

Du legg til ein vert på den grøne lokasjonen, han blir løyst opp for grøne brukarar, og det gule kontoret får framleis NXDOMAIN. Det er ikkje ein VPN-feil og ikkje ein øydelagd resolver; det er eit eigarskapshol i den private sona. To uavhengig redigerte oppføringslister blir ikkje éi sone berre fordi lokasjonane kan nå kvarandre. Løysinga er ein publiseringsplan, ikkje nok ein brannmurregel.

Symptomet namngir den manglande eigaren

Kvar lokasjon har truleg ei lokal overstyring, ei Pi-hole-oppføring eller ei dnsmasq-linje som nokon la til då eit namn var naudsynt. Den grøne oppføringa finst berre på den grøne resolveren, så ein klient på gul spør sin eigen resolver og får eit sanneleg "ingen slik namn". Eit utdatert svar ser annleis ut: verten flytta, éin lokasjon oppdaterte kopien sin, og den andre returnerer framleis den gamle adressa.

Ingen av mønstra blir løyste lenge ved å tømme cachen. Cachen til ein videresendande resolver er ein kopi av eit svar han ein gong fekk, ikkje ein autoritet som publiserer nye namn, så ein cache som verkar i dag seier ingenting om morgondagens vert. BIND-dokumentasjonen skildrar primær-, sekundær-, rekursiv- og videresendarrollene kvar for seg nettopp av denne grunnen.

Så designspørsmålet er smalt og svarande: kven kan opprette ei oppføring, og korleis når den oppføringa kvar resolver som må svare på henne?

Alternativ A: éi autoritativ sone med sekundære

Køyr ein primær for internal.example.com og la støtta sekundære hente sona på kvar lokasjon. Den rekursive resolveren til kvar lokasjon spør sin lokale sekundær, så svara kjem frå ein autoritativ kjelde i staden for ein cache, og ei endring som er gjord éin gong blir overført i staden for å bli skriven på nytt.

Den ordninga krev eksplisitte avgjerder som er lette å utsetje og dyre å hoppe over. Kven kan redigere sona? Kva tenarar har lov til å overføre henne, og over kva adresser? Kva skal klientane sjå medan tunnelen mellom lokasjonane er nede? Ein sekundær held fram med å svare frå den siste kopien sin, noko som vanlegvis er ønskt åtferd, men det må vere eit uttalt val og ikkje overrasking under ein avbrott.

Avgrens soneoverføringar til dei kjende sekundære etter adresse og bruk transaksjonssignaturar der implementasjonen støttar dei. Ei open overføring er ein kopi av ditt interne namnerom for alle som når porten.

Prisen er koordinering: éin redigeringsveg, éi endringsvurdering og ei felles forståing av kven som har vakt når ei oppføring er feil.

Alternativ B: eit subdomene per lokasjon

Deleger green.internal.example.com til den grøne lokasjonen og yellow.internal.example.com til den gule. Kvar lokasjon blir autoritativ for sine eigne namn, og foreldresona ber berre delegasjonsoppføringane. Striden om éi fil forsvinn, og eit lokalt team kan leggje til ein vert utan å vente på ei sentral endring.

Delegasjonen må finnast i foreldresona, med NS-oppføringar som peikar på dei autoritative tenarane til lokasjonen. Ei vilkårsstyrt videresending for subdomenet er eit gyldig alternativ når full delegasjon er upraktisk, men det er ei resolverinnstilling og ikkje eit publisert faktum, så kvar resolver treng den same regelen.

Prisen flyttar seg i staden for å forsvinne: foreldresona treng framleis ein eigar, og å opprette ein ny lokasjon er no ei endring på to stader i staden for éin.

La kvar resolver følgje valet

Gje klientane den godkjende resolveren og søkjedomenet gjennom den støtta konfigurasjonen deira, og sørg for at resolveren har ein tillaten VPN-rute til kvar ekstern DNS-tenar han må spørje. Applikasjonar treng også ruter til dei private adressene som desse svara returnerer, fordi eit korrekt namn utan veg framleis er ei broten tilknyting.

Viss Pi-hole leverer lokalt oppslag, skriv ned kva oppføringar han eig og kva spørjingar han videresender. To uavhengig redigerte Pi-hole-lister replikerer framleis ikkje. I Pi-hole v6 blir eigedefinerte dnsmasq-linjer sette gjennom vertssidealternativ som TOML, CLI eller miljøvariablar og blir ikkje eksponerte gjennom API-et; lasting av /etc/dnsmasq.d/-filer er eit separat alternativ som er slått av som standard.

Test deretter frå begge sider med eit namn som bør vere synleg 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 fortel deg om den gule resolveren trur han er autoritativ, spør ein sekundær eller berre videresender. Dette er ulike design med ulike feilmodusar, og svaret identifiserer vanlegvis kva ein du faktisk har rulle ut.

Avslutt med tre aksepttilfelle: eitt namn frå kvar lokasjon, éi oppføring endra innan timen og sambandet mellom lokasjonane utilgjengeleg. Eit design som berre består det første har ein publiseringsplan på papiret og ei lokal overstyring i produksjon.