Wat zijn DNS-records?

DNS (Domain Name System) is het systeem dat door mensen leesbare domeinnamen zoals example.com vertaalt naar de numerieke IP-adressen die computers gebruiken om elkaar op het internet te vinden. DNS-records zijn de afzonderlijke vermeldingen in dit systeem, elk met een specifiek doel: van het laten verwijzen van uw domein naar een webserver tot het routeren van e-mail naar de juiste mailserver. Zonder DNS zou u voor elke website die u bezoekt IP-adressen moeten onthouden.

Stap voor stap: hoe DNS-resolutie werkt

Wanneer u een domeinnaam in uw browser typt, vindt vóór het laden van de pagina een reeks lookups plaats. Inzicht in dit proces helpt bij het oplossen van problemen en het instellen van redelijke TTL-waarden:

1. Browsercache: uw browser controleert eerst zijn eigen cache om te zien of hij het IP-adres voor het domein al kent. Heeft u de site recent bezocht, dan is het antwoord mogelijk al lokaal opgeslagen.
2. Cache van het besturingssysteem: heeft de browser het niet in de cache, dan vraagt hij het besturingssysteem, dat zijn eigen DNS-cache bijhoudt.
3. Recursieve resolver: heeft geen van beide caches het antwoord, dan stuurt uw computer een verzoek naar een recursieve DNS-resolver, doorgaans van uw internetprovider (ISP) of een openbare dienst zoals Cloudflare (1.1.1.1) of Google (8.8.8.8).
4. Root-nameserver: de resolver bevraagt een van de 13 root-nameserverclusters. De rootserver kent het uiteindelijke IP-adres niet, maar weet welke nameservers verantwoordelijk zijn voor het topleveldomein (.com, .org, .nl enzovoort).
5. TLD-nameserver: de resolver bevraagt de TLD-nameserver voor .com (of welke extensie dan ook). Deze server reageert met de gezaghebbende nameservers voor het specifieke domein.
6. Gezaghebbende nameserver: ten slotte bevraagt de resolver de gezaghebbende nameserver voor example.com, die het feitelijke IP-adres uit het A- (of AAAA-)record retourneert.
7. Antwoord: de resolver stuurt het IP-adres terug naar uw browser, die nu verbinding kan maken met de webserver en de pagina kan laden.

Dit hele proces duurt doorgaans 20 tot 100 milliseconden. Eenmaal opgelost wordt het resultaat op meerdere niveaus gecachet, waardoor latere bezoeken sneller zijn.

Alle gangbare DNS-recordtypen uitgelegd

DNS ondersteunt veel recordtypen, elk met een eigen rol. Hier zijn de typen die u tegenkomt bij het beheren van een WordPress-site:

• A-record: het meest fundamentele recordtype. Het koppelt een domeinnaam aan een IPv4-adres (bijv. example.com aan 93.184.216.34). U kunt meerdere A-records voor hetzelfde domein hebben om verkeer over meerdere servers te verdelen (round-robin load balancing).
• AAAA-record: het IPv6-equivalent van het A-record. Koppelt een domein aan een IPv6-adres (bijv. 2606:2800:220:1:248:1893:25c8:1946). Naarmate IPv6-adoptie groeit, zorgt het hebben van AAAA-records naast A-records dat uw site op beide protocollen bereikbaar is.
• CNAME-record: maakt een alias van het ene domein naar het andere. U kunt bijvoorbeeld www.example.com naar example.com laten verwijzen, of shop.example.com naar myshop.shopify.com. Belangrijke beperking: een CNAME kan niet samen bestaan met andere recordtypen op dezelfde naam (u kunt niet zowel een CNAME als een MX-record voor hetzelfde subdomein hebben).
• MX-record: geeft aan welke mailservers e-mail voor uw domein verwerken. Elk MX-record heeft een prioriteitswaarde (lager getal betekent hogere prioriteit). Is uw primaire mailserver offline, dan wordt e-mail bezorgd op de server met de eerstvolgende laagste prioriteit.
• TXT-record: een veelzijdig record dat willekeurige tekstdata opslaat. Meest gebruikt voor SPF-records voor e-mailauthenticatie, DKIM-sleutels, DMARC-beleid en domeinverificatie voor diensten als Google Search Console of Microsoft 365.
• NS-record: geeft de gezaghebbende nameservers voor uw domein aan. Wanneer u een domein registreert, stelt u NS-records in die wijzen naar uw DNS-provider (bijv. Cloudflare, Route 53 of de nameservers van uw hostingbedrijf). Het wijzigen van NS-records delegeert in feite de controle over de DNS van uw domein naar een andere provider.
• SOA-record: het "Start of Authority"-record bevat administratieve informatie over de DNS-zone, waaronder de primaire nameserver, het e-mailadres van de DNS-beheerder, het serienummer van de zone en timing-waarden voor hoe vaak secundaire nameservers op updates moeten controleren.
• SRV-record: geeft host en poort aan voor specifieke diensten. Wordt minder vaak gebruikt voor websites maar is relevant voor diensten als SIP (VoIP), XMPP (chat) of Microsoft Active Directory.
• CAA-record: Certificate Authority Authorization-records geven aan welke certificeringsinstanties SSL/TLS-certificaten voor uw domein mogen uitgeven. Dit is een beveiligingsmaatregel die voorkomt dat ongeautoriseerde CA's certificaten voor uw site uitgeven. U zou bijvoorbeeld een CAA-record kunnen instellen waardoor alleen Let's Encrypt certificaten voor uw domein mag uitgeven.

SPF, DKIM en DMARC voor e-mailauthenticatie

Verstuurt uw WordPress-site e-mail (meldingen van contactformulieren, WooCommerce-orderbevestigingen, wachtwoordresets), dan is e-mailauthenticatie essentieel. Zonder authenticatie belanden uw e-mails eerder in spammappen of worden ze volledig afgewezen. Deze drie standaarden werken samen en worden allemaal geconfigureerd via DNS-TXT-records:

• SPF (Sender Policy Framework): een TXT-record dat aangeeft welke servers gemachtigd zijn e-mail namens uw domein te versturen. Bijvoorbeeld: v=spf1 include:_spf.google.com include:sendgrid.net -all betekent dat Google en SendGrid gemachtigd zijn en alle andere servers afgewezen moeten worden. Zonder SPF kan iedereen e-mails vervalsen die ogenschijnlijk van uw domein komen.
• DKIM (DomainKeys Identified Mail): voegt een digitale handtekening toe aan elke uitgaande e-mail. De publieke sleutel wordt gepubliceerd als DNS-TXT-record, en de ontvangende mailserver gebruikt deze om de handtekening te verifiëren. Dit bewijst dat de e-mail onderweg niet is gemanipuleerd en daadwerkelijk van uw server kwam.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): bouwt voort op SPF en DKIM door ontvangende mailservers te vertellen wat te doen wanneer authenticatie faalt. U kunt hen instrueren de e-mail af te wijzen, in quarantaine te plaatsen (in spam) of slechts te monitoren en rapporteren. Een eenvoudig DMARC-record ziet er zo uit: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Alle drie instellen is met name belangrijk wanneer u een transactionele e-maildienst (zoals Mailgun, SendGrid of Amazon SES) gebruikt om WordPress-e-mails te versturen. Zonder correcte authenticatie kunnen uw orderbevestigingen en wachtwoordreset-e-mails uw klanten nooit bereiken.

TTL en wat het betekent voor DNS-propagatie

Elk DNS-record heeft een TTL-waarde (Time to Live), gemeten in seconden. Deze vertelt DNS-resolvers hoe lang zij het record mogen cachen voordat zij op een update controleren. Veelgebruikte TTL-waarden zijn:

• 300 (5 minuten): goed voor records die vaak wijzigen of wanneer u zich op een migratie voorbereidt.
• 3600 (1 uur): een redelijke standaard voor de meeste records.
• 86400 (24 uur): geschikt voor records die zelden wijzigen, zoals NS-records.

Wanneer mensen praten over "DNS-propagatie die tot 48 uur duurt", verwijzen zij naar de tijd die nodig is voordat gecachete records over de hele wereld verlopen en met nieuwe data worden vernieuwd. Staat uw huidige TTL op 86400 seconden (24 uur), dan kunnen resolvers die het oude record hebben gecachet dit nog tot 24 uur na uw wijziging blijven gebruiken.

Een praktische tip: plant u een serververhuizing of DNS-wijziging, verlaag de TTL dan een dag of twee voor de overstap naar 300 seconden. Wanneer u de records bijwerkt, verlopen de oude gecachete waarden binnen 5 minuten en verloopt de overgang veel soepeler.

DNS- en CDN-configuratie

Wanneer u een CDN (Content Delivery Network) zoals Cloudflare instelt, wijzigt u doorgaans uw DNS om verkeer via het CDN te routeren. Er zijn twee gangbare benaderingen:

• CNAME-opzet: u maakt een CNAME-record dat uw domein naar de edge-server van het CDN laat verwijzen (bijv. example.com.cdn.cloudflare.net). Dit komt vaak voor bij CDN-aanbieders zoals KeyCDN, BunnyCDN of AWS CloudFront. De beperking is dat CNAME-records op de zone-apex (het kale domein, example.com zonder www) technisch in strijd zijn met de DNS-specificatie, hoewel sommige aanbieders dit omzeilen met eigen oplossingen.
• NS-/full-proxy-opzet: bij Cloudflares volledige opzet wijzigt u de NS-records van uw domein zodat zij naar de nameservers van Cloudflare verwijzen. Cloudflare beheert dan al uw DNS-records en proxiet verkeer via zijn netwerk. Dit is de meest gangbare aanpak omdat Cloudflare hierdoor zonder CNAME-beperkingen op de zone-apex kan werken.

WordPress-specifieke DNS-overwegingen

Bij het instellen van DNS voor een WordPress-site zijn er een paar zaken om in gedachten te houden:

• Domein laten verwijzen: uw A-record dient naar het IP-adres van uw hostingserver te wijzen. Op shared hosting levert uw host het IP. Op een VPS of dedicated server gebruikt u het publieke IP-adres van de server. Zorg dat zowel example.com als www.example.com correct resolven (via een A-record en een CNAME, of twee A-records).
• E-mailopzet: veel WordPress-hosts bieden geen e-mailhosting. Gebruikt u Google Workspace of Microsoft 365 voor e-mail, dan dient u de juiste MX-records in te stellen en SPF-/DKIM-TXT-records toe te voegen zoals gespecificeerd door uw e-mailaanbieder. Als deze fout staan, komen meldingen van uw contactformulier mogelijk niet aan.
• Subdomein-opzet: voor WordPress multisite met subdomein-configuratie, of als u een staging-site op staging.example.com draait, heeft u extra A-records of CNAME-records voor elk subdomein nodig. Wildcard-DNS-records (*.example.com) kunnen dit vereenvoudigen voor multisite-installaties.
• Domeinverificatie: Google Search Console, Facebook Business, Pinterest en andere diensten vragen u domeineigendom te verifiëren door een TXT-record toe te voegen. Deze records beïnvloeden de werking van uw site niet; zij bewijzen alleen dat u het domein beheert.

Wat InspectWP controleert

InspectWP haalt de DNS-records voor het domein van uw WordPress-site op en toont deze, inclusief A-, AAAA-, MX-, TXT-, NS- en CNAME-records. Dit geeft u een snel overzicht van uw DNS-configuratie zonder dat u in het dashboard van uw DNS-provider hoeft in te loggen. Het helpt u te verifiëren dat uw domein naar de juiste server wijst, dat MX-records voor e-mailaflevering zijn geconfigureerd, en dat essentiële TXT-records (zoals SPF) aanwezig zijn. Het opsporen van een verkeerd geconfigureerd of ontbrekend record kan u uren probleemoplossing met e-mailaflevering of connectiviteit besparen.