Twee locaties, één privé-DNS-zone: van wie zijn de records?

Je voegt een host toe op de groene locatie, hij resolvet voor groene gebruikers, en het gele kantoor krijgt nog steeds NXDOMAIN. Dat is geen VPN-storing en geen kapotte resolver; het is een eigendomsgat in de privézone. Twee onafhankelijk bewerkte recordlijsten worden niet één zone alleen omdat de locaties elkaar kunnen bereiken. De oplossing is een publicatieplan, niet nog een firewallregel.

Het symptoom noemt de ontbrekende eigenaar

Elke locatie heeft waarschijnlijk een lokale overschrijving, een Pi-hole-item of een dnsmasq-regel die iemand toevoegde toen een naam nodig was. Het groene record bestaat alleen op de groene resolver, dus een client op geel vraagt zijn eigen resolver en krijgt een waarheidsgetrouw "geen dergelijke naam". Een verouderd antwoord ziet er anders uit: de host is verhuisd, de ene locatie heeft zijn kopie bijgewerkt en de andere geeft nog steeds het oude adres terug.

Geen van beide patronen wordt lang opgelost met een cache-leegloop. De cache van een doorsturende resolver is een kopie van een antwoord dat hij ooit ontving, geen gezag dat nieuwe namen publiceert, dus een cache die vandaag werkt zegt niets over de host van morgen. De BIND-documentatie beschrijft primaire, secundaire, recursieve en doorsturende rollen juist om deze reden apart.

De ontwerpvraag is dus smal en beantwoordbaar: wie mag een record aanmaken, en hoe bereikt dat record elke resolver die er antwoord op moet geven?

Optie A: één gezaghebbende zone met secondaries

Draai een primaire voor internal.example.com en laat ondersteunde secondaries de zone op elke locatie ophalen. De recursieve resolver van elke locatie vraagt zijn lokale secondary, dus antwoorden komen uit een gezaghebbende bron in plaats van een cache, en een wijziging die één keer is gedaan wordt overgedragen in plaats van opnieuw getypt.

Die opzet vereist expliciete beslissingen die makkelijk uit te stellen en duur om over te slaan zijn. Wie mag de zone bewerken? Welke servers mogen hem overdragen, en via welke adressen? Wat moeten clients zien terwijl de tunnel tussen locaties plat ligt? Een secondary blijft antwoorden uit zijn laatste kopie, wat meestal het gewenste gedrag is, maar het moet een uitgesproken keuze zijn en geen verrassing tijdens een storing.

Beperk zoneoverdrachten tot de bekende secondaries op adres en gebruik transactiehandtekeningen waar de implementatie die ondersteunt. Een open overdracht is een kopie van je interne naamruimte voor iedereen die de poort bereikt.

De prijs is coördinatie: één bewerkingspad, één wijzigingsbeoordeling en een gedeeld begrip van wie dienst heeft wanneer een record fout is.

Optie B: een subdomein per locatie

Delegeer green.internal.example.com aan de groene locatie en yellow.internal.example.com aan de gele. Elke locatie wordt gezaghebbend voor zijn eigen namen, en de bovenliggende zone draagt alleen de delegatierecords. De strijd om één bestand verdwijnt, en een lokaal team kan een host toevoegen zonder op een centrale wijziging te wachten.

De delegatie moet in de bovenliggende zone bestaan, met NS-records die naar de gezaghebbende servers van de locatie wijzen. Een voorwaardelijke doorsturing voor het subdomein is een geldig alternatief wanneer een volledige delegatie onpraktisch is, maar het is een resolverinstelling en geen gepubliceerd feit, dus elke resolver heeft dezelfde regel nodig.

De prijs verschuift in plaats van te verdwijnen: de bovenliggende zone heeft nog steeds een eigenaar nodig, en een nieuwe locatie aanmaken is nu een wijziging op twee plaatsen in plaats van één.

Laat elke resolver de keuze volgen

Geef clients de goedgekeurde resolver en het zoekdomein via hun ondersteunde configuratie, en zorg dat de resolver een toegestane VPN-route heeft naar elke externe DNS-server die hij moet bevragen. Applicaties hebben ook routes nodig naar de privéadressen die die antwoorden teruggeven, want een correcte naam zonder pad is nog steeds een verbroken verbinding.

Als Pi-hole lokale resolutie levert, schrijf dan op welke records het bezit en welke query's het doorstuurt. Twee onafhankelijk bewerkte Pi-hole-lijsten repliceren nog steeds niet. In Pi-hole v6 worden aangepaste dnsmasq-regels ingesteld via opties aan de hostkant zoals TOML, CLI of omgevingsvariabelen en ze worden niet via de API blootgelegd; het laden van /etc/dnsmasq.d/-bestanden is een aparte optie die standaard uit staat.

Test daarna van beide kanten met een naam die overal zichtbaar zou moeten zijn:

$ 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

Het SOA-antwoord vertelt je of de gele resolver zich gezaghebbend acht, een secondary bevraagt of alleen doorstuurt. Dat zijn verschillende ontwerpen met verschillende faalwijzen, en het antwoord benoemt meestal welke je werkelijk hebt uitgerold.

Sluit af met drie acceptatiegevallen: één naam van elke locatie, één record binnen het uur gewijzigd en de verbinding tussen locaties niet beschikbaar. Een ontwerp dat alleen het eerste haalt, heeft een publicatieplan op papier en een lokale overschrijving in productie.