Två platser, en privat DNS-zon: vem äger posterna?

Du lägger till en värd på den gröna platsen, den löses upp för gröna användare, och det gula kontoret får fortfarande NXDOMAIN. Det är inte ett VPN-fel och inte en trasig resolver; det är ett ägargap i den privata zonen. Två oberoende redigerade postlistor blir inte en zon bara för att platserna kan nå varandra. Lösningen är en publiceringsplan, inte ännu en brandväggsregel.

Symtomet namnger den saknade ägaren

Varje plats har förmodligen en lokal överstyrning, en Pi-hole-post eller en dnsmasq-rad som någon lade till när ett namn behövdes. Den gröna posten finns bara på den gröna resolvern, så en klient på gul frågar sin egen resolver och får ett sanningsenligt "inget sådant namn". Ett inaktuellt svar ser annorlunda ut: värden flyttade, en plats uppdaterade sin kopia och den andra returnerar fortfarande den gamla adressen.

Inget av mönstren löses länge genom att tömma cachen. Cachen hos en vidarebefordrande resolver är en kopia av ett svar den en gång fick, inte en auktoritet som publicerar nya namn, så en cache som fungerar i dag säger ingenting om morgondagens värd. BIND-dokumentationen beskriver primär-, sekundär-, rekursiv- och vidarebefordrarollerna var för sig just av denna anledning.

Så designfrågan är smal och besvarbar: vem får skapa en post, och hur når den posten varje resolver som måste svara för den?

Alternativ A: en auktoritativ zon med sekundärservrar

Kör en primär för internal.example.com och låt stödda sekundärer hämta zonen på varje plats. Varje plats rekursiva resolver frågar sin lokala sekundär, så svaren kommer från en auktoritativ källa i stället för en cache, och en ändring som gjorts en gång överförs i stället för att skrivas om.

Det arrangemanget kräver uttryckliga beslut som är lätta att skjuta upp och dyra att hoppa över. Vem får redigera zonen? Vilka servrar får överföra den, och över vilka adresser? Vad ska klienterna se medan tunneln mellan platserna ligger nere? En sekundär fortsätter svara från sin senaste kopia, vilket vanligtvis är det önskade beteendet, men det måste vara ett uttalat val och inte en överraskning under ett avbrott.

Begränsa zonöverföringar till de kända sekundärerna efter adress och använd transaktionssignaturer där implementeringen stöder dem. En öppen överföring är en kopia av ditt interna namnrum för alla som når porten.

Priset är samordning: en redigeringsväg, en ändringsgranskning och en gemensam förståelse för vem som har jour när en post är fel.

Alternativ B: en underdomän per plats

Delegera green.internal.example.com till den gröna platsen och yellow.internal.example.com till den gula. Varje plats blir auktoritativ för sina egna namn, och den överordnade zonen bär bara delegeringsposterna. Striden om en enda fil försvinner, och ett lokalt team kan lägga till en värd utan att vänta på en central ändring.

Delegeringen måste finnas i den överordnade zonen, med NS-poster som pekar på platsens auktoritativa servrar. En villkorad vidarebefordran för underdomänen är ett giltigt alternativ när en full delegering är opraktisk, men det är en resolverinställning och inte ett publicerat faktum, så varje resolver behöver samma regel.

Priset förflyttas i stället för att försvinna: den överordnade zonen behöver fortfarande en ägare, och att skapa en ny plats är nu en ändring på två ställen i stället för ett.

Låt varje resolver följa valet

Ge klienterna den godkända resolvern och sökdomänen via deras stödda konfiguration, och se till att resolvern har en tillåten VPN-rutt till varje fjärransluten DNS-server som den måste fråga. Applikationer behöver också rutter till de privata adresser som dessa svar returnerar, eftersom ett korrekt namn utan väg fortfarande är en bruten anslutning.

Om Pi-hole tillhandahåller lokal uppslagning, skriv ned vilka poster den äger och vilka frågor den vidarebefordrar. Två oberoende redigerade Pi-hole-listor replikeras fortfarande inte. I Pi-hole v6 ställs anpassade dnsmasq-rader in via värdsidans alternativ som TOML, CLI eller miljövariabler och exponeras inte via API:t; inläsning av /etc/dnsmasq.d/-filer är ett separat alternativ som är avstängt som standard.

Testa sedan från båda sidor med ett namn som borde vara synligt överallt:

$ 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 berättar om den gula resolvern anser sig auktoritativ, frågar en sekundär eller bara vidarebefordrar. Det är olika designer med olika felmoder, och svaret anger vanligtvis vilken du faktiskt har driftsatt.

Avsluta med tre acceptansfall: ett namn från varje plats, en post ändrad inom timmen och förbindelsen mellan platserna otillgänglig. En design som bara klarar det första har en publiceringsplan på papperet och en lokal överstyrning i produktionen.