To lokaliteter, én privat DNS-zone: hvem ejer posterne?

Du tilføjer en vært på den grønne lokalitet, den slår op for grønne brugere, og det gule kontor får stadig NXDOMAIN. Det er ikke en VPN-fejl og ikke en defekt resolver; det er et ejerskabshul i den private zone. To uafhængigt redigerede postlister bliver ikke én zone, blot fordi lokaliteterne kan nå hinanden. Løsningen er en publiceringsplan, ikke endnu en firewallregel.

Symptomet navngiver den manglende ejer

Hver lokalitet har sandsynligvis en lokal tilsidesættelse, en Pi-hole-post eller en dnsmasq-linje, som nogen tilføjede, da et navn var nødvendigt. Den grønne post findes kun på den grønne resolver, så en klient på gul spørger sin egen resolver og får et sandfærdigt "intet sådant navn". Et forældet svar ser anderledes ud: værten er flyttet, én lokalitet har opdateret sin kopi, og den anden returnerer stadig den gamle adresse.

Ingen af mønstrene løses i længden af en cachetømning. En videresendende resolvers cache er en kopi af et svar, den engang modtog, ikke en myndighed, der publicerer nye navne, så en cache, der virker i dag, siger intet om morgendagens vært. BIND-dokumentationen beskriver primære, sekundære, rekursive og videresendende roller hver for sig netop af denne grund.

Så designspørgsmålet er snævert og kan besvares: hvem må oprette en post, og hvordan når den post hver resolver, der skal svare på den?

Mulighed A: én autoritativ zone med sekundære

Kør en primær for internal.example.com og lad understøttede sekundære hente zonen på hver lokalitet. Hver lokalitets rekursive resolver spørger sin lokale sekundære, så svarene kommer fra en autoritativ kilde i stedet for en cache, og en ændring, der er lavet én gang, overføres i stedet for at blive skrevet igen.

Den ordning kræver eksplicitte beslutninger, som er nemme at udskyde og dyre at springe over. Hvem må redigere zonen? Hvilke servere må overføre den, og over hvilke adresser? Hvad skal klienter se, mens tunnelen mellem lokaliteterne er nede? En sekundær fortsætter med at svare ud fra sin sidste kopi, hvilket normalt er den adfærd, du ønsker, men det skal være et erklæret valg og ikke en overraskelse under et udfald.

Begræns zoneoverførsler til de kendte sekundære efter adresse, og brug transaktionssignaturer, hvor implementeringen understøtter dem. En åben overførsel er en kopi af dit interne navnerum til enhver, der kan nå porten.

Prisen er koordinering: én redigeringsvej, én ændringsgennemgang og en fælles forståelse af, hvem der har vagten, når en post er forkert.

Mulighed B: et subdomæne for hver lokalitet

Delegér green.internal.example.com til den grønne lokalitet og yellow.internal.example.com til den gule. Hver lokalitet bliver autoritativ for sine egne navne, og den overordnede zone bærer kun delegeringsposterne. Striden om én fil forsvinder, og et lokalt team kan tilføje en vært uden at vente på en central ændring.

Delegeringen skal findes i den overordnede zone, med NS-poster, der peger på lokalitetens autoritative servere. En betinget videresendelse for subdomænet er et gyldigt alternativ, når en fuld delegering er upraktisk, men det er en resolverindstilling og ikke en publiceret kendsgerning, så hver resolver har brug for den samme regel.

Prisen flytter sig i stedet for at forsvinde: den overordnede zone har stadig brug for en ejer, og at oprette en ny lokalitet er nu en ændring to steder i stedet for ét.

Lad hver resolver følge valget

Giv klienterne den godkendte resolver og søgedomænet gennem deres understøttede konfiguration, og sørg for at resolveren har en tilladt VPN-rute til enhver fjern DNS-server, den skal forespørge. Programmer har også brug for ruter til de private adresser, som disse svar returnerer, fordi et korrekt navn uden en vej stadig er en brudt forbindelse.

Hvis Pi-hole leverer lokal opslagning, så skriv ned, hvilke poster den ejer, og hvilke forespørgsler den videresender. To uafhængigt redigerede Pi-hole-lister replikerer stadig ikke. I Pi-hole v6 sættes tilpassede dnsmasq-linjer gennem værtsidens valgmuligheder som TOML, CLI eller miljøvariabler og eksponeres ikke gennem API'et; indlæsning af /etc/dnsmasq.d/-filer er en separat valgmulighed, der er slået fra som standard.

Test derefter fra begge sider med et navn, der bør være synligt 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 fortæller dig, om den gule resolver mener, at den er autoritativ, spørger en sekundær eller blot videresender. Det er forskellige designs med forskellige fejlmåder, og svaret identificerer normalt, hvilken du faktisk har implementeret.

Afslut med tre accepttilfælde: et navn fra hver lokalitet, en post ændret inden for timen og forbindelsen mellem lokaliteterne utilgængelig. Et design, der kun består det første, har en publiceringsplan på papiret og en lokal tilsidesættelse i produktionen.