Een ontwikkelaar belt vanuit huis: "De API reageert in 20 ms op kantoor, 800 ms daarbuiten. » Je opent dig api.example.com op de laptop: het IP-adres is dat van de publieke load balancer. Hij, verbonden met de VPN, verkrijgt het IP-adres van een interne, niet-gerouteerde pod van internet. Het ticket wordt urgent wanneer de productie een certificaat inzet dat alleen geldig is op de interne naam.
Split-horizon bestaat om twee legitieme DNS-waarheden te dienen, afhankelijk van de oorsprong van de zoekopdracht. Als het slecht bedraad is, wordt het een verwarringsmachine: privé-IP-lekken, inconsistente TLS-certificaten, resolver-caches die liegen.
Principe: één vraag, meerdere antwoorden
Split-horizon (of gesplitste DNS) retourneert verschillende records, afhankelijk van het bronnetwerk: desktop/VPN versus internet. Een db.example.com kan verwijzen naar 10.0.1.50 voor beheerders en 203.0.113.10 voor het publiek.
Dit is normaal en vaak wenselijk om de interne latentie te verminderen en te voorkomen dat administratieve services worden blootgesteld. Dit is geen liegende DNS in de kwaadaardige zin: het is een zichtbaarheidsbeleid.
Waar het breekt in de productie
| Symptoom | Gemeenschappelijke oorzaak |
|---|---|
| Publieke site intern ontoegankelijk | Hairpin NAT ontbreekt, split is verkeerd geconfigureerd |
| IP RFC1918 in VirusTotal | Interne zone per ongeluk publiekelijk bediend |
| SAN-certificaat ontbreekt | Interne naam gebruikt door het publieke front |
| Langzame resolutie | Interne/externe lusdoorstuurders |
In het slechtste geval: een intern record dat door een ongelezen cron-script is gesynchroniseerd met een openbare DNS.
Implementatiemodellen
Twee zones: corp.internal (niet-gedelegeerd) + example.com (openbaar). Duidelijk voor de teams.
BIND-weergaven/beleid Niet-gebonden: één engine, ACL per subnet. Vereist configuratiediscipline.
Cloud DNS + Private Link: Route 53 Resolver, Azure Private DNS, Cloud DNS private – de grens wordt netwerk + IAM.
Kies op basis van wie de DNS beheert en hoeveel fysieke sites u heeft.
Synchronisatie en beheer
Gemeenschappelijke records (MX, TXT SPF, DKIM) moeten aan beide kanten identiek blijven, tenzij er een gedocumenteerde uitzondering is. Automatiseer de replicatie van gemeenschappelijke ruimtes; Isoleer interne overschrijvingen in speciale bestanden of labels.
Elke verandering moet antwoorden: “Wie ziet wat? » en “Welke resolutie wordt gebruikt bij het uitschakelen van de VPN-laptop? »
Tests vóór elke wijziging
Vanaf internet: dig +trace, DNSSEC indien actief, vergelijk met een publieke solver.
Vanaf VPN: dezelfde verzoeken, controleer IP en TTL.
Vanaf gastnetwerk: zorg ervoor dat er geen interne forwarder toegankelijk is.
Logzoneverschillen als applicatiecode.
Levensdocumentatie
Tabel: FQDN | binnenaanzicht | extern zicht | eigenaar | laatst geverifieerd.
Beoordeling bij elke interne onboardingservice.
Test VPN uit + op dezelfde laptop elk kwartaal.
Houd een gedateerd runbook bij, voor/na-statistieken en beoordeling na incidenten: cumulatieve discipline voorkomt paniek op vrijdagavond.
Houd een gedateerd runbook bij, voor/na-statistieken en beoordeling na incidenten: cumulatieve discipline voorkomt paniek op vrijdagavond.
Houd een gedateerd runbook bij, voor/na-statistieken en beoordeling na incidenten: cumulatieve discipline voorkomt paniek op vrijdagavond.
Houd een gedateerd runbook bij, voor/na-statistieken en beoordeling na incidenten: cumulatieve discipline voorkomt paniek op vrijdagavond.
Houd een gedateerd runbook bij, voor/na-statistieken en beoordeling na incidenten: cumulatieve discipline voorkomt paniek op vrijdagavond.
Houd een gedateerd runbook bij, voor/na-statistieken en beoordeling na incidenten: cumulatieve discipline voorkomt paniek op vrijdagavond.
Documentatie met gesplitste horizon
Interne/externe/eigenaar/geverifieerde FQDN-tabel. Driemaandelijkse laptop VPN-test. Interne TLS: Vernieuwen omvat beide weergaven.
Beslis en ga vooruit zonder blinde vlek
- Vermeld elke FQDN met het interne en externe antwoord, de bedrijfseigenaar en de laatste controledatum.
- Afzonderlijke zones — bekijkt BIND, Route 53 gesplitst beleid of speciale interne DNS; vermijd een enkel “bijna hetzelfde” zonebestand.
- Test vanaf de laptop — VPN geactiveerd en gedeactiveerd op dezelfde kritieke URL's (API, git, monitoring).
- Beperk AXFR-overdrachten: waarschuwing als seriële SOA tussen weergaven afwijkt of als een openbare secundaire een intern IP-adres lekt.
- Documenteer het onboarding-runbook: elke nieuwe interne service voegt een rij toe aan de tabel voordat deze in productie wordt genomen.
Om de grootte van interne vs. beheerde DNS-hosting te bepalen, bladert u door de overzicht, de vergelijker en ons netwerk gidsen.
Veelgestelde vragen
Split-horizon en publieke DNS, kunnen we mixen?
Ja, maar alleen externe standpunten mogen publiekelijk worden gedelegeerd. Interne namen mogen nooit zonder filter verschijnen in enig gebied op internet.
Moeten we twee aparte ruimtes hebben of slechts één met uitzicht?
Twee afzonderlijke zones (internal.example / example.com) vereenvoudigen het beheer. Weergaven op dezelfde BIND-server zijn geschikt als het ACL-beleid strikt en gecontroleerd is.
Wat te doen als de VPN uitvalt?
Zorg voor een back-up-resolver, tijdelijke failover-records aan de externe kant en een runbook waarvoor geen interne toegang vereist is om de openbare service te herstellen.
Hoe voorkom je dat een laptop buiten VPN intern problemen oplost?
Stel interne forwarders niet bloot op ongecontroleerde netwerken; gebruik interne, niet-openbaar gedelegeerde DNS-achtervoegsels en expliciet split-tunnel-beleid.
Voordat je een interne weergave toevoegt, schrijf je de zin: “Een ingenieur zonder VPN zou in staat moeten zijn om...” – als het einde “…niets” is, heb je één enkel punt van falen.