Cloud DNS Forwarding werd in 2018 aangekondigd via een korte blogpost. De kortheid van die blogpost staat in groot contrast met de enorme impact die het kan hebben bij het vereenvoudigen van de Cloud-aanpassing van ondernemingen. Ik zal u uitleggen waarom.
Wat is Google Cloud DNS Forwarding?
Kort gezegd heeft Google Cloud DNS uitgebreid met de mogelijkheid om een privé DNS-omgeving te beheren zoals u dat wilt. U kunt vertrouwen op de DNS-server van GCP (genaamd Internal DNS for Compute Engine), een willekeurige DNS-server toevoegen als extra naast die van Google, of GCP’s DNS volledig overstemmen met uw eigen DNS-server. En dat laatste heeft veel macht.
Dus waarom is dit zo’n big deal?
Voor de release van het DNS-beleid om je eigen DNS-server te vermelden, was het een enorm gedoe om de eigen DNS-server van GCP te omzeilen, vooral met Linux-instanties. Als je wilde dat je Linux instanties wisten van je machines op prem, kon je niet gewoon hun resolv.conf veranderen omdat GCP nogal koppig is en het elke 24 uur opnieuw instelt. Je kon ook niet de Interne DNS wijzigen die door de metadata server wordt gebruikt. Bedankt daarvoor…
Er zijn een heleboel workarounds, waaronder het installeren van een BIND DNS-server die is ingesteld om door te sturen naar uw werkelijke DNS-server op elke instantie. Niet echt beheersbaar voor grote werklasten als je het mij vraagt. Op Windows servers was het eenvoudiger, omdat je gewoon de goede oude netwerk configuratie kunt oproepen en daar de DNS IP servers kunt veranderen. Maar dat moest je nog steeds op elke server doen. Niet erg beheersbaar als je naar Cloud kijkt voor de zogenaamde ‘managed services’. Ironisch genoeg had je zelfs meer te beheren!
“De alternatieve naamservers worden de enige bron die GCP bevraagt voor alle DNS-verzoeken die VM’s in de VPC indienen met behulp van hun metadataserver, 169.254.169.254”.
Nu heeft Google toegestaan om een uitgaand DNS-beleid te maken om een alternatieve naamserver als enige bron van waarheid te gebruiken. Uit de docs: Wanneer u dit doet, worden de alternatieve naamservers de enige bron die GCP bevraagt voor alle DNS-verzoeken die worden ingediend door VM’s in de VPC met behulp van hun metadataserver, 169.254.169.254.
Het woord “alleen” is hier essentieel. Het neemt eindelijk de controle weg van het Compute Engine Internal DNS monster waar je nul controle over had.
U hoeft niet langer te vertrouwen op bitcoin_miner-539.c.my-awesome-project.internal DNS-namen en niet in staat te zijn uw eigen DNS-vermeldingen toe te voegen.
“Je hebt nu de flexibiliteit om beide kanten op te gaan. Laat Google uw hele DNS automatisch beheren, voeg een secundaire server toe of neem de volledige controle.”
Dus hoe moet ik het gebruiken?
Zoals altijd: dat hangt ervan af. U hebt nu de flexibiliteit om beide kanten op te gaan. Laat Google uw volledige DNS beheren, voeg een secundaire server toe of neem de volledige controle. U kunt uw bestaande Active Directory DNS toevoegen als secundaire DNS door een doorstuurzone aan te maken – bijvoorbeeld door Google de Compute Engine Instances te laten beheren maar te vertrouwen op uw Active Directory voor uw on-prem-omgeving – of volledige controle te geven aan uw Active Directory door een beleid voor uitgaande doorsturing in te schakelen, waardoor de interne DNS van de Compute Engine volledig wordt omzeild.
Belangrijk: Een DNS-beleid dat uitgaande forwarding inschakelt, schakelt resolutie van Compute Engine Internal DNS en Cloud DNS managed private zones uit.
Dit is een super schone manier omdat de metadata server, waarvoor elke Compute Engine instance automatisch wordt geconfigureerd om naar toe te gaan voor DNS resolving, je DNS voorkeuren zal respecteren. U hoeft niets meer te veranderen aan een Compute Engine instance, maar kunt uw DNS-omgeving centraal beheren met Cloud DNS.
Volledig enterprise-ready: Gedeelde VPC
Voeg daarbij het gebruik van Shared VPC en beheer uw volledige VPC (incl. VPN, DNS en firewalling) in het hostproject. Dit geeft de serviceprojecten gemoedsrust omdat ze zich niet eens hoeven te bekommeren om DNS en automatisch genieten van de vrijheid van de setup in het hostproject. Op deze manier kan het netwerkteam zich bezighouden met het hostproject, terwijl al deze complexiteit wordt verborgen voor operationele collega’s die alleen de VM’s hoeven te beheren, niet het netwerk, in het serviceproject.
Ze creëren gewoon een instantie in het dienstenproject met behulp van de gedeelde VPC en BOEM, ze zijn automatisch geconfigureerd om toegang te krijgen tot de DNS via de VPN-verbinding die in het hostproject wordt beheerd. Wil je loco gaan? Configureer dit alles met behulp van Deployment Manager voor een volledige Infrastructure-as-Code aanpak.
Een andere leuke functie is het feit dat het ook andersom kan werken, zodat uw on-prem instances Google Cloud Internal DNS kunnen bevragen met behulp van Inbound DNS forwarding. U hebt nu dus echt de volledige flexibiliteit om volledig voor hybride te gaan.
Slotopmerking: uiteraard is een VPN of Interconnect nodig om verbinding te maken met uw on-premise Active Directory, om ervoor te zorgen dat u binnen uw privé-netwerk blijft en alles afgesloten blijft van publieke toegang. We willen toch niet dat de wereld onze interne DNS raadpleegt voor ‘master.finance.fourcast’?
Hulp nodig?
Neem gerust contact op, bij Devoteam G Cloud hebben we de expertise in huis om van uw project een succes te maken.
