On-prem-systemen kunnen cloud-namen niet resolven en omgekeerd
Route 53 Resolver, Azure Private DNS Resolver, en Cloud DNS managed zones met inbound/outbound forwarders zijn de juiste laag. Iedere cloud-provider heeft het, naamgeving verschilt.
Probeer dit eerst zelf
- 1AWS: Route 53 Resolver met inbound endpoint (on-prem -> AWS), outbound endpoint (AWS -> on-prem) plus forwarding-rules per domein.
- 2Azure: Azure Private DNS Resolver met inbound en outbound endpoints. Combineer met Private DNS zones voor cloud-services.
- 3GCP: Cloud DNS Inbound DNS forwarding voor on-prem -> GCP, Outbound forwarding via Cloud DNS managed zone forwarding rules.
- 4Configureer over je VPN of Direct Connect / ExpressRoute / Interconnect, niet over public internet. DNS over public internet is een security-fout.
- 5Test bidirectioneel: nslookup vanaf on-prem naar cloud-resource én andersom. Vergeet de reverse-lookup niet als je SSH op naam wilt doen.
Wanneer ons inschakelen
Bij een hybride setup met meerdere on-prem-locaties, conditional-forwarding en split-DNS is dit echt een netwerk-architect-job. Half doen is hier slechter dan niet doen.
Zie ook
- Iedereen logt in met het root-account van AWSHet root-account is voor noodgevallen en facturatie. Dagelijks werk hoort via IAM-users of SSO.
- Iedere developer heeft AdministratorAccessAdministratorAccess overal is gemak nu, drama later. Begin met rolgebaseerde policies.
- Iedereen heeft losse IAM-users met eigen wachtwoordIdentity Center (voorheen AWS SSO) koppelt aan je IdP en geeft tijdelijke credentials per sessie.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.