CNAME: aliassen in de DNS-wereld
Een CNAME-record (Canonical Name) is een type DNS-record dat een alias aanmaakt van de ene hostnaam naar de andere. In plaats van direct naar een IP-adres te verwijzen (zoals een A-record), zegt een CNAME: "deze naam is eigenlijk een alias van die andere naam — zoek het IP daar op." Het is als postdoorverwijzing: als je een brief stuurt naar "Kerkstraat 5" en er hangt een bordje "de bewoner is verhuisd naar Marktstraat 10", wordt de post bezorgd op het nieuwe adres.
CNAME's zijn fundamenteel in de moderne webinfrastructuur: vrijwel alle clouddiensten, CDN's en SaaS-platformen vereisen het configureren van een CNAME die naar hun hostnaam verwijst. Wanneer je Cloudflare, AWS, Heroku, GitHub Pages of een andere clouddienst gebruikt, heeft jouw domein doorgaans een CNAME die verwijst naar de hostnaam van de provider. Dit stelt de provider in staat om de IP-adressen van hun servers te wijzigen zonder dat er aanpassingen aan jouw DNS nodig zijn.
De CNAME-regels die je moet kennen
CNAME-records hebben strikte regels die in de RFC's zijn gedefinieerd en bij overtreding resolutiefouten veroorzaken. De belangrijkste regel: een hostnaam met een CNAME-record mag geen enkel ander type record hebben. Dit betekent dat als www.voorbeeld.nl een CNAME heeft, je geen TXT-, MX- of enig ander record op dezelfde hostnaam kunt toevoegen. Deze beperking bestaat omdat de CNAME aangeeft dat die naam een alias is — alle DNS-queries voor die naam worden doorgestuurd naar het CNAME-doel.
De tweede kritieke regel: je kunt geen CNAME gebruiken op de root (apex) van het domein. Het domein voorbeeld.nl (zonder www) moet ten minste SOA- en NS-records hebben, die niet naast een CNAME kunnen bestaan. Als jouw clouddienst een CNAME vereist maar je de domeinroot moet gebruiken, zoek dan bij je DNS-provider naar alternatieven: ALIAS, ANAME of CNAME-flattening die het conflict aan de serverzijde oplossen.
CNAME-ketens en prestaties
Wanneer een CNAME verwijst naar een andere hostnaam die op zijn beurt ook een CNAME is, ontstaat er een keten. Onze CNAME Lookup volgt de volledige keten tot aan de uiteindelijke resolutie en toont elk niveau. CNAME-ketens voegen latentie toe: elk niveau vereist een extra DNS-query. De best practice is om ketens te beperken tot 1-2 niveaus. Langere ketens zijn doorgaans het resultaat van in de loop der tijd opgestapelde legacy-configuraties en zouden vereenvoudigd moeten worden.
Een verraderlijk probleem bij CNAME-ketens is de lus: A verwijst naar B dat weer naar A verwijst. Dit veroorzaakt een oneindige resolutiefout die resolvers afbreken na een maximaal aantal stappen (doorgaans 8-10). De CNAME Lookup identificeert lussen door de cyclus duidelijk weer te geven. Als je een lus vindt, is de oplossing om de keten te doorbreken door een van de CNAME's te vervangen door een direct A-record.
Om te controleren of je CNAME's correct zijn geconfigureerd en de doelen opgelost worden, combineer je de CNAME Lookup met de DNS Lookup voor een volledig beeld. Als je een dienst migreert en het CNAME-doel moet bijwerken, verlaag dan eerst de TTL, voer de wijziging door en controleer de wereldwijde propagatie met DNS Propagation. Dit minimaliseert de downtime tijdens migraties.
CNAME's worden ook gebruikt voor vanity-domeinen van e-mailmarketing en voor tracking: links zoals click.newsletter.voorbeeld.nl zijn vaak een CNAME naar het domein van de e-mailmarketingdienst. Controleer regelmatig of deze CNAME's nog nodig zijn en naar actieve diensten verwijzen. Verweesde CNAME's die verwijzen naar subdomeinen van niet meer gebruikte diensten kunnen kwetsbaar zijn voor subdomain takeover, een aanzienlijk beveiligingsrisico.