A-Record CNAME klinkt vergelijkbaar, maar voert twee verschillende taken uit in het DNS: Het A-record wijst een domein rechtstreeks toe aan een IPv4-adres, terwijl de CNAME in plaats daarvan een alias aan een andere hostnaam toewijst. In dit artikel leg ik het praktische verschil uit, waar elk type record goed tot zijn recht komt en hoe je beide correct kunt gebruiken zodat subdomeinen, www en externe services betrouwbaar aan de juiste hostnaam worden toegewezen. Adres show.
Centrale punten
- A-RecordDirecte toewijzing van een domein aan een IPv4-adres
- CNAMEAlias van een subdomein naar een andere hostnaam
- PrestatiesA-Record meestal sneller, CNAME flexibeler
- Apex-domeinvoor het hoofddomein gebruiken meestal A-Record
- OnderhoudIP wijzigt alleen het A-record, CNAME's volgen
DNA uitgelegd in een notendop
Ik vergelijk DNS zoals een telefoonboek: mensen onthouden namen, computers spreken IP's en DNS vertaalt tussen de twee. Als u example.de oproept, haalt de resolver de overeenkomende gegevens op van gezaghebbende naamservers en geeft hij het IP-adres zodat de browser het verzoek naar de juiste server kan sturen. Server wordt verzonden. Om dit proces soepel te laten verlopen, werken resolvers met tussenliggende geheugens en respecteren ze de gedefinieerde TTL, die regelt hoe lang een resultaat geldig blijft. Voor een compacte introductie raad ik de uitleg van DNS en domeinnaamsysteemwaarin de belangrijkste bouwstenen worden samengevat. Als basisregel geldt: zonder correcte DNS-invoer kan een gebruiker uw website niet bereiken, zelfs niet als de webserver tiptop in orde is. loopt.
A-Record: directe toewijzing aan het IPv4-adres
A A-Record verbindt een domein of subdomein direct met een specifiek IPv4, zoals 203.0.113.10, zodat het verzoek direct op de gewenste machine terechtkomt zonder omwegen. Deze directheid brengt snelheid met zich mee, omdat de resolver normaal gesproken maar één query nodig heeft, wat merkbaar korte responstijden kan opleveren. Gebruik A-records voor hoofddomeinen en voor subdomeinen met hun eigen doelserver als je het IP beheert en niet voortdurend wijzigt, zodat je de Soevereiniteit via de resolutie. Plan de TTL zo dat deze overeenkomt met je veranderingsfrequentie: infrequente veranderingen staan een langere TTL toe voor minder DNS-verkeer, frequente verhuizingen hebben baat bij een korte TTL zodat nieuwe IP's zich sneller verspreiden. Als je ook IPv6 gebruikt, voeg dan het AAAA record toe, aangezien het A record alleen betrekking heeft op IPv4 van.
CNAME: alias voor hostnamen en subdomeinen
A CNAME wijst niet naar een IP, maar naar een andere hostnaam, daarom wordt het gezien als een alias die het beheer van veel subdomeinen vereenvoudigt. Voorbeeld: www.beispiel.de wijst als CNAME naar example.de, het eigenlijke IP staat alleen op het hoofddomein en blijft uw enige aanpassingspunt. Als het IP van de server verandert, hoeft alleen het A-record van het hoofddomein te worden aangepast en alle afhankelijke CNAME's volgen automatisch de nieuwe Doel. Dit is hoe ik opstellingen met blog-, shop- of app-subdomeinen slank houd, vooral wanneer verschillende services dezelfde backend gebruiken. Ik verbind ook externe platforms op deze manier, zoals cdn.provider.net, zonder dat ik het onderliggende IP-adres hoef te kennen of te onderhouden. moet.
Directe vergelijking: eigenschappen, prestaties en gebruik
Beide invoertypes vervullen duidelijke taken, maar verschillen in doel, resolutie en focus van gebruik, wat je zult merken in je dagelijkse werk. Gebruik voor het Apex-domein meestal de A-Recordomdat e-mailingangen zoals MX parallel moeten lopen en een CNAME daar problemen veroorzaakt. Voor subdomeinen is de CNAME aantrekkelijker omdat het je onderhoudsinspanning vermindert en de configuratie overzichtelijk houdt, vooral in grote omgevingen. Op het gebied van responstijd scoort het A-Record punten omdat een lookup voldoende is, terwijl een CNAME minstens één extra stap vereist, die afhankelijk van de resolver nauwelijks meetbaar is, maar voor veel ketens merkbaar kan zijn. De volgende tabel vat de kerngegevens samen en laat zien waarom ik bewust beide gebruik, afhankelijk van het doel. mix:
| Functie | A-Record | CNAME |
|---|---|---|
| Doeltype | IP-adres (IPv4) | Hostnaam (Alias) |
| Resolutie | meestal 1 opzoeken | minstens 2 lookups |
| Hoofddomein (Apex) | geschikt | problematisch met MX |
| Onderhoud voor IP-verandering | Alle aangetaste A-records wijzigen | alleen A-record op bestemming, CNAME's volgen |
| Toepassingsprofiel | solide, kritisch Doelen | veel subdomeinen, externe services |
Praktijk: Voorbeelden van schone configuraties
Voor nieuwe projecten begin ik met een duidelijke scheiding: het Apex-domein krijgt een A-Recordwww wijst via CNAME naar de Apex en verdere subdomeinen volgen indien nodig. Als een shop naar een SaaS-platform verwijst, stel ik shop.deinedomain.de in als CNAME naar shop.example.net, zodat latere wijzigingen werken zonder IP-kennis. Voor interne tools met een eigen machine, zoals monitor.deinedomain.de, kies ik een A-record, omdat ik bewust het IP beheer en de voorkeur geef aan directe resolutie. De volgende mini-matrix maakt het verschil tastbaar en laat zien hoe flexibel CNAME's zijn in grotere opstellingen. Zo houd ik het DNS-beheer duidelijk en responsief:
| subdomein | Type | Doel |
|---|---|---|
| www | CNAME | voorbeeld.com |
| blog | CNAME | voorbeeld.com |
| winkel | CNAME | shop.external.com |
| voorbeeld.com | A-Record | 192.0.2.10 |
TTL, prestaties en ketens van CNAME's
De TTL (Time to Live) beïnvloedt hoe lang resolvers reacties cachen, wat direct van invloed is op prestaties en tijdigheid. Voor statische doelen gebruik ik langere TTL's om het aantal DNS-verzoeken te verminderen, terwijl ik de TTL vroeg verlaag voor geplande verhuizingen zodat veranderingen wereldwijd snel aankomen. Voor CNAME's verhoogt elke extra keten het aantal resoluties. Daarom houd ik ketens kort en controleer ik aliaspaden regelmatig. Zorg ervoor dat u geen lussen creëert en dat de uiteindelijke bestemming daadwerkelijk kan worden opgelost met A of AAAA-records, anders wordt de website onbereikbaar. Test wijzigingen met tools als dig of nslookup, observeer de responstijden en controleer of de resolver de verwachte TTL respecteert.
AAAA-record en IPv6: dubbel toegankelijk, zuiver geprioriteerd
Naast A-Records gebruik ik consequent AAAA Records zodat clients ook via IPv6 verbinding kunnen maken. Moderne stacks gebruiken de "happy eyeballs" methode en kiezen automatisch het snellere pad - je wint bereik en veerkracht. Belangrijk: Publiceer alleen een AAAA record als de dienst volledig toegankelijk is via IPv6 (firewall, routing, TLS certificaat, VirtualHost/SNI). Een gebroken IPv6 pad zal anders leiden tot timeouts, ook al zou IPv4 werken. Ik houd de TTL van A en AAAA identiek zodat beide paden synchroon verouderen en controleer regelmatig met dig AAAA of het antwoord correct is.
Jokertekens: Gebruik jokertekens op een gerichte manier
Met een wildcard (*.uwdomein.com) kun je onbekende subdomeinen onderscheppen - praktisch als fallback of voor kortstondige testhosts. Ik stel meestal een CNAME naar een centraal doel of een A-record naar een landingspagina. Let op de prioriteit: Expliciete vermeldingen verslaan wildcards. Vermijd wildcard MX's of wildcard NS's die onbedoeld de mail- of zonestructuur kunnen veranderen. Houd wildcards transparant gedocumenteerd zodat je weet welke subdomeinen daadwerkelijk worden opgelost via de placeholder.
Meerdere A-records: correcte beoordeling van round robin en failover
Als je verschillende A-Records voor hetzelfde label, verdelen resolvers de antwoorden vaak round-robin. Dit is eenvoudige load balancing, maar geen gezondheidscontrole: als een doel faalt, leveren caches het nog steeds totdat de TTL verloopt. Voor echte hoge beschikbaarheid combineer ik DNS met upstream controles (bijv. loadbalancer of CDN) of gebruik ik providerfuncties zoals weighted/active-passive. Plan de TTL bewust: kort genoeg voor snel overschakelen, lang genoeg tegen onnodige belasting. Met aparte A en AAAA sets kun je ook subtiel per-familie controleren zonder risico op asymmetrische bereikbaarheid.
Apex domein, e-mail en CNAME alternatieven
Op de ApexNaast het A of AAAA record zijn er vaak andere entries zoals MX voor e-mail, TXT voor SPF en soms SRV in een domein (example.de), daarom leidt een CNAME daar tot conflicten. Sommige providers bieden zogenaamde ALIAS- of ANAME-types, die zich gedragen als CNAME op de Apex, maar een IP presenteren aan de resolver zodat parallelle vermeldingen bestaan zonder interferentie. Als je provider dit niet biedt, houd het dan bij A en AAAA records op de Apex en gebruik alleen CNAMEs op subdomeinen om de setup stabiel en onderhoudsarm te houden. Voor het afleveren van e-mail controleer ik altijd of MX correct is ingesteld en of SPF, DKIM en DMARC compleet zijn, zodat aflevering en reputatie correct zijn. Deze organisatie zorgt ervoor dat het web en e-mail betrouwbaar samenwerken en dat je de juiste Plaats veranderen.
E-mail, MX en CNAME: regels die problemen voorkomen
Ik houd me aan twee principes: 1) Een label dat MX of andere platen heeft, krijgt geen CNAME (regel "geen CNAME en andere gegevens"). 2) De doelhostnamen in MX zouden idealiter direct naar A/AAAA moeten wijzen en niet naar een CNAME, zodat mailservers niet tegen niets aanlopen. Voor DKIM gebruik ik graag CNAME's op vendor selectors, omdat alleen de CNAME bestaat op het selector label, wat goed werkt. Voor de bezorging zelf stel ik speciale A/AAAA-records in op de mailhost (bijv. mail.deinedomain.de) en onderhoud ik SPF, DKIM en DMARC via TXT, zodat de mailstromen robuust blijven.
Valkuilen: typische fouten snel herkennen
Ik zie de meest voorkomende problemen met te lange CNAME-ketens, alias-lussen en CNAME's op het Apex-domein waar MX's al bestaan en conflicten veroorzaken. In zulke gevallen controleer ik het zonebestand van boven naar beneden, beperk ketens tot een minimum en stel het A-record in waar andere vermeldingen nodig zijn. Een andere klassieker: haal de volgorde van www-subdomein en apex niet door elkaar, anders lopen certificaten en redirects uiteen. Houd ook de propagatie na wijzigingen in de gaten, want in caches over de hele wereld duurt het even voordat nieuwe waarden verschijnen, afhankelijk van de TTL. Gestructureerde monitoring bespaart u probleemoplossing en uw Bezoekers betrouwbaar hun bestemming bereiken.
Wijzigingen netjes doorvoeren met de provider
Voordat ik DNS-records wijzig, verlaag ik de TTLwachten op de cache runtime en dan de nieuwe waarden instellen zodat gebruikers de verse gegevens snel ontvangen. Er zijn duidelijke interfaces met velden voor A, AAAA, CNAME, MX, TXT en SRV voor veel voorkomende hosters, wat voorspelbare processen mogelijk maakt. Als je je wilt oriënteren op een specifiek voorbeeld, kijk dan eens naar de compacte Gids voor DNS-instellingendie de invoervelden en typische combinaties laat zien. Na het opslaan gebruik ik dig/nslookup om te controleren of de antwoorden en TTL correct zijn en test dan de web- en e-mailtoegankelijkheid via verschillende netwerken. Dit zorgt ervoor dat de wijziging geen onverwachte problemen veroorzaakt. Hiaten achterlaat.
Diagnose in de praktijk: dig en nslookup patronen
Ik gebruik duidelijke commando's voor snelle controles. Met graven + opsporen kun je de hele resolutieketen tot aan de gezaghebbende server zien - ideaal voor het visualiseren van CNAME-ketens of delegatieproblemen. Met dig www.deinedomain.de A +ttlunits Ik controleer welke TTL de resolver daadwerkelijk retourneert. En met dig cname.target.tld CNAME kun je herkennen of de alias wijst naar een doel dat oplosbaar is. Het is ook belangrijk om te testen met AAAA om IPv6 niet te vergeten. Op Windows levert nslookup vergelijkbare resultaten; ik stel de server in op 8.8.8.8 of 1.1.1.1 om onafhankelijke reacties te krijgen en lokale caches uit te sluiten.
Certificaten en CNAME's: wat de browser echt controleert
Zelfs als een hostnaam via CNAME naar een andere bestemming verwijst, valideert de browser de Certificaat altijd tegen de oorspronkelijk aangeroepen naam. Het certificaat moet daarom de aliasnaam (SAN/CN) bevatten, niet noodzakelijkerwijs de doelhost. Ik gebruik vaak DNS-01 uitdagingen voor automatisering: Het label _acme-uitdaging kan via CNAME worden gedelegeerd naar een provider die de validatie beheert zonder dat ik handmatig TXT-records hoef aan te passen. Zorg er alleen voor dat de CNAME correct wordt omgezet en dat er geen parallelle records zijn op hetzelfde label.
CDN- en SaaS-integratie: hostheaders en Apex-strategieën
Met CDN's of SaaS-diensten is de Hostkop Cruciaal: De doelserver verwacht het originele domein in de HTTP-header, zelfs als je naar een andere hostnaam verwijst via CNAME. Controleer of je provider "Custom Domains" incl. TLS heeft opgeslagen voor je hostnamen, anders zal SNI mislukken. Voor het Apex-domein zonder ALIAS/ANAME werk ik met 301-redirects naar www, die naar het CDN wijzen als CNAME - dit houdt de resolutie schoon en SEO consistent.
Split-horizon DNS: intern vs. extern
In bedrijfsnetwerken gebruik ik graag Gespleten horizonInterne resolvers geven andere antwoorden dan externe (bijvoorbeeld privé-IP's voor interne diensten). Een duidelijke scheiding van zones en gestandaardiseerde labels zijn hier belangrijk. Ik documenteer welke namen intern verschillen en voorkom dat interne hostnamen per ongeluk openbaar worden. Stel hier spaarzaam CNAME's in om ketens over de zonegrenzen heen te vermijden en houd de TTL intern kort voor snelle rollouts.
Beveiliging: Voorkom bungelende CNAME's en overname van subdomeinen
Bijzonder kritisch zijn bungelende CNAME's naar externe providers waarvan het doelendpoint niet meer bestaat. Aanvallers kunnen dan het vrije eindpunt registreren en inhoud leveren onder uw subdomein. Mijn tegenmaatregelen: Controleer de zone regelmatig, verwijder ongebruikte CNAME's, documenteer externe afhankelijkheden en ruim de DNS-records actief op wanneer het project verloopt. Ik stel ook CAA-records in om de uitgifte van certificaten te beperken en wildcards tot een minimum te beperken voor zover dat nodig is.
SEO-aspecten van aliassen en omleidingen
DNS-vermeldingen lossen namen op, ze vervangen niet DoorsturenIk besteed daarom ook aandacht aan HTTP redirects en consistente canonical tags zodat zoekmachines het hoofdadres herkennen. Als je www gebruikt als CNAME naar de Apex, stuur alle gebruikers dan door naar een voorkeurs-URL zodat signalen gebundeld worden. Voor subdomeinen die als aliassen fungeren, besteed ik aandacht aan interne linking en canonicals zodat content niet dubbel verschijnt en het crawlbudget redelijk blijft. Praktische tips over aliassen en bereik vind je in het compacte artikel op Domein alias en SEOdie prioriteit geeft aan schone structuren. Houd DNS en SEO gescheiden: DNS lost snel en Betrouwbaar SEO controleert zichtbaarheid en consistentie.
Samenvatting in platte tekst
De A-Record verbindt een domein direct met een IPv4-adres en biedt snelheid en controle, vooral op het Apex-domein met parallelle MX- en TXT-vermeldingen. De CNAME stelt een alias in voor een hostnaam en is ideaal wanneer veel subdomeinen naar hetzelfde doel moeten verwijzen of externe services worden geïntegreerd. Voor wijzigingen aan het doel is het meestal voldoende om het A-record van het hoofddomein te openen, terwijl alle CNAME's automatisch volgen en het onderhoud laag blijft. Let op korte ketens, geschikte TTL's en vermijd CNAME's op de top als daar e-mailvermeldingen zijn, anders riskeer je storingen. Met deze duidelijke taakverdeling selecteert u de juiste invoer voor elke host, houdt u de zone netjes en zorgen voor een snelle, betrouwbare oplossing.
