DNS, SSL en servertaken automatiseren bij elke provider

Infrastructuurautomatisering betekent dat je scripts, op standaarden gebaseerde protocollen of een beheerplatform repetitief DNS-, SSL- en serverwerk laat afhandelen, in plaats van door vijf verschillende providerdashboards te klikken. De grootste winst zit in het automatiseren van certificaatverlenging (ACME), wijzigingen in DNS-records (provider-API's of een gemeenschappelijke abstractielaag) en het opstarten van servers (cloud-init), terwijl een laag voor driftdetectie de wijzigingen opvangt die de automatisering heeft gemist. Draai je infrastructuur bij meer dan één registrar, DNS-host of cloud, dan is dit het verschil tussen een incident van vijf minuten en een zaterdag lang zoeken naar een login.

Wat valt onder infrastructuurautomatisering

In de basis is infra-automatisering elk proces dat DNS, certificaten of de serverstatus wijzigt zonder dat iemand handmatig inlogt op een configuratiescherm. Dat omvat:

• Recordwijzigingen: A-, CNAME-, MX-, TXT- of CAA-records toevoegen, bijwerken of verwijderen via een API in plaats van een webformulier.
• Certificaatverlengingen: TLS-certificaten automatisch uitgeven en installeren voordat ze verlopen, in plaats van te wachten op een vervalmelding.
• Serveracties: een VM op dezelfde manier provisionen, herstarten, schalen of opstarten, ongeacht op welke cloud die draait.
• Driftmeldingen: een melding krijgen wanneer de live status (een record, een certificaat, een draaiende service) niet meer overeenkomt met wat je verwacht.

Hiervoor heb je geen exotische tools nodig. Het meeste is gebouwd op open standaarden die elke serieuze provider al ondersteunt. Juist daarom kan één dashboard bovenop veel providers draaien zonder de API van elke provider vanaf nul opnieuw uit te vinden.

DNS-wijzigingen automatiseren bij meerdere providers

Elke grote DNS-host (Cloudflare, Route 53, Google Cloud DNS, DigitalOcean, Namecheap, GoDaddy) biedt een REST API voor record-CRUD (create, read, update, delete). Het probleem is niet dat er geen API's zijn, maar dat elke API een eigen authenticatiemodel, schema en rate limits heeft. Daarom gebruiken de meeste automatiseringsopstellingen een gemeenschappelijke abstractielaag (de DNS-providers van Terraform, OctoDNS of een beheerplatform) in plaats van zelf een client te bouwen voor elke registrar waarmee je werkt.

Een recordwijziging met precies hetzelfde doel ziet er overal anders uit:

Ben je nog niet klaar om dit zelf te scripten? Doe dan voor en na elke wijziging een snelle controle met onze gratis DNS lookup-tool. Zo bevestig je het snelst dat een record echt is gepropageerd zoals je automatisering het bedoelde. Voor de recordtypes zelf is onze gids over DNS-recordtypes een handig naslagwerk terwijl je wijzigingen scriptt.

TipWelke abstractie je ook gebruikt, houd de TTL laag (300–600 seconden) op records die je wilt automatiseren. Met een TTL van 24 uur wordt een gescripte rollback een wachttijd van uren.

SSL-certificaten automatisch uitgeven en verlengen

Het ACME-protocol (RFC 8555) heeft ervoor gezorgd dat certificaatautomatisering de norm werd in plaats van de uitzondering. Let's Encrypt maakte het populair, maar ZeroSSL, Google Trust Services en Buypass Go SSL implementeren allemaal dezelfde standaard. Daardoor werkt dezelfde clienttooling (Certbot, acme.sh, lego) bij al deze aanbieders: je wijst simpelweg naar een andere directory-URL.

Er zijn twee ACME-challengetypes die je moet kennen:

• HTTP-01: serveert een token op http://yourdomain/.well-known/acme-challenge/. Eenvoudig, maar hiermee kun je geen wildcardcertificaten uitgeven.
• DNS-01: vereist een _acme-challenge TXT-record. Dit is de enige methode die wildcardcertificaten (*.yourdomain.com) ondersteunt, en daarom is DNS-01 de standaard geworden voor geautomatiseerde opstellingen met meerdere domeinen en providers.

Omdat certificaten van Let's Encrypt 90 dagen geldig zijn, is automatisering geen optie maar juist het hele punt. Een vergeten handmatige verlenging is een van de meest voorkomende oorzaken van ongeplande downtime. Twijfel je of een gratis geautomatiseerd certificaat genoeg is voor jouw situatie? In ons artikel over Let's Encrypt vs commerciële SSL-certificaten lees je wanneer de betaalde route nog zinvol is. Hoe dan ook bevestigt een periodieke controle met onze gratis SSL check-tool dat de keten, de vervaldatum en de hostnaam echt kloppen: automatisering verkleint het risico, maar neemt de noodzaak tot verificatie niet weg.

Servertaken automatiseren over clouds heen

Serverautomatisering heeft een eigen de-factostandaard: cloud-init. Dit regelt taken bij de eerste opstart, zoals pakketten installeren, gebruikers aanmaken, SSH-sleutels plaatsen en opstartscripts uitvoeren, en wordt standaard ondersteund door AWS, Azure, GCP, DigitalOcean, Hetzner en de meeste andere IaaS-providers. Eén cloud-init-configuratie schrijven en die bij meerdere providers hergebruiken is veel betrouwbaarder dan per cloud aparte bootstrapscripts onderhouden.

Voor doorlopende configuratie (niet alleen de eerste opstart) is Ansible de gangbare keuze, omdat het servers via SSH beheert zonder dat er een agent nodig is. De modules dekken bovendien de API's van de meeste cloudproviders voor acties als schalen, snapshots maken of herstarten.

Voorbeeld van een cloud-init-fragment dat hetzelfde werkt bij elke provider die het ondersteunt:

#cloud-config
package_update: true
packages:
  - nginx
users:
  - name: deploy
    ssh-authorized-keys:
      - ssh-rsa AAAA...your-key-here
runcmd:
  - systemctl enable nginx
  - systemctl start nginx

Opvangen wat automatisering mist: drift en downtime

Automatisering vermindert handwerk, maar je moet nog steeds weten wanneer er echt iets misgaat: een verlengingsjob die stilletjes faalt, een record dat iemand buiten je scripts om handmatig heeft aangepast, of een server die niet meer reageert. Hier sluit monitoring de cirkel: het laat het verschil zien tussen "de automatisering is uitgevoerd" en "het resultaat klopt".

WarningEen verlengingsscript dat succes meldt, garandeert niet dat het nieuwe certificaat ook echt wordt geserveerd. Combineer geautomatiseerde uitgifte altijd met een onafhankelijke controle: een monitor, niet alleen de exitcode van een cronjob.

Een snelle handmatige controle met onze gratis is it down-tool is prima als steekproef, maar voor alles wat onbeheerd draait wil je continue monitoring met meldingen, geen tool die je zelf moet onthouden te openen.

Waarom alles vanaf één plek beheren

Elk onderdeel hierboven (DNS, certificaten, servers, monitoring) heeft een eigen standaard en een eigen ecosysteem van tools. De praktische uitdaging zit niet in één onderdeel, maar in het feit dat de meeste teams uiteindelijk DNS in het ene dashboard hebben, certificaten bijhouden in een spreadsheet, servers verspreid hebben over twee of drie clouds en monitoring er los aan hebben vastgeknoopt. InfraNest bestaat om die overzichten op één plek samen te brengen: beheer DNS-records bij elke provider die je gebruikt, houd certificaten en hun vervaldata bij in één lijst, en draai uptime monitoring op alles wat je hebt geprovisioned, zonder voor elke provider steeds van login te wisselen.

Ben je actief bezig je tooling te consolideren? Lees dan wat er onlangs is veranderd in ons overzicht van de updates van juli 2026.

Begin met in kaart brengen waar je DNS, certificaten en servers nu staan, en bekijk dan hoeveel daarvan het dashboard van InfraNest je al in één overzicht kan laten zien.