DNS uitgelegd: hoe namen websites vinden en waarom opzoeken mislukt

Wat gebeurt er wanneer u een websiteadres invoert?

Stel dat u www.example.com invoert in uw browser. De browser en het besturingssysteem controleren eerst of er al een bruikbaar antwoord beschikbaar is. Is een nieuwe opzoeking nodig, dan vraagt het apparaat zijn ingestelde recursieve resolver. Die kan uit zijn eigen cache antwoorden of de DNS-hiërarchie volgen tot de gezaghebbende server voor de naam is gevonden. Een antwoord kan een adres bevatten of een alias die een verdere opzoeking vereist. Daarna probeert het apparaat met die informatie de websiteverbinding te maken.

Dit onderscheid is belangrijk bij het zoeken naar een storing. Een correct DNS-antwoord kan alsnog leiden naar een onbereikbare server, een geblokkeerde verbinding of een certificaatfout. Andersom bewijzen werkende wifi en een bereikbare router niet dat naamomzetting werkt. Moderne websites kunnen meerdere adressen en content delivery networks gebruiken. Twee geldige DNS-antwoorden kunnen daardoor verschillen. Alleen een adres vergelijken met een oude schermafbeelding is onvoldoende om te bepalen dat een van de antwoorden fout is.

Resolver, gezaghebbende DNS, registrar en hosting hebben verschillende taken

De recursieve resolver is de dienst die uw apparaat doorgaans bevraagt. De internetprovider levert deze vaak via de router, maar een browser, VPN of apparaatinstelling kan een andere resolver kiezen. De gezaghebbende DNS-dienst beheert de gepubliceerde records van het domein. De registrar beheert de domeinregistratie en de verwijzing naar de nameservers. De website draait bij de hostingaanbieder. Deze taken kunnen bij één leverancier liggen of bij verschillende onafhankelijke organisaties.

De nuttige vraag is daarom welk onderdeel u zelf beheert. Een thuisgebruiker kan DNS-instellingen op het eigen apparaat of de eigen router onderzoeken, maar kan de gezaghebbende records van een andere organisatie niet herstellen. Een domeinbeheerder kan records wijzigen; een wijziging op de router van een bezoeker maakt geen ontbrekend domeinrecord aan. Een beheerd werknetwerk gebruikt soms bewust een interne resolver voor private namen. Zonder toestemming vervangen kan bedrijfsdiensten onderbreken, zelfs als openbare websites daarna wel werken.

Welke DNS-records zijn belangrijk voor websites en e-mail?

A-records koppelen een naam aan IPv4-adressen; AAAA-records koppelen een naam aan IPv6-adressen. Een CNAME verwijst naar een andere naam in plaats van rechtstreeks naar een adres. MX-records bepalen de mailbestemmingen en hun voorkeurswaarden. TXT-records bevatten tekst voor onder meer domeinverificatie en e-mailauthenticatie. NS-records wijzen de gezaghebbende nameservers aan. Deze records hebben verschillende functies. Alleen het websiteadres kopiëren bij een verhuizing kan daarom e-mail of verificatie verstoren.

Gebruik precies het recordtype, de naam en de waarde die de verantwoordelijke dienst voorschrijft. Voor het hoofddomein en www kunnen afzonderlijke records nodig zijn. Ook e-mailauthenticatie vraagt specifieke namen en correcte notatie. Een extra of tegenstrijdig record kan problemen veroorzaken. Behandel TXT-records niet als tekst die u zonder meer kunt verwijderen. Bewaar vóór een wijziging een gedateerde export of schermafbeeldingen van de bestaande zone en bescherm toegangsgegevens. Beheert u het domein niet, geef uw waarneming dan door aan de eigenaar in plaats van een vervangende waarde te gokken.

• A / AAAA: adressen die bij een hostnaam horen.
• CNAME: een alias naar een andere DNS-naam.
• MX: de aangewezen mailservers voor het domein.
• TXT: gepubliceerde tekst, waaronder verificatie en e-mailbeleid.
• NS: de aangewezen gezaghebbende servers voor een domein.

Waarom verschijnt een DNS-wijziging eerder op het ene apparaat dan op het andere?

DNS-antwoorden hebben een geldigheidsduur: de time to live, meestal TTL genoemd. Een cache kan het antwoord hergebruiken zolang die duur geldig is. Een resolver die kort vóór een wijziging het oude record heeft opgehaald, kan nog dat antwoord geven. Een andere resolver zonder gecacht antwoord ontvangt al het nieuwe record. Apparaten, browsers en recursieve resolvers kunnen ieder informatie bewaren. Ook mislukte opzoekingen kunnen worden gecacht. De algemene instructie om op “propagatie” te wachten is daarom minder nuttig dan de daadwerkelijke verwijzing naar nameservers, records en relevante cacheduur controleren.

De TTL vlak vóór een wijziging verlagen verkort niet met terugwerkende kracht antwoorden die al met de oude TTL zijn opgeslagen. Plan vooruit wanneer u het domein beheert. De cache op één laptop wissen leegt alleen de plaatselijke cache, niet die van alle openbare resolvers. Het record tijdens het wachten herhaaldelijk wijzigen maakt onderzoek moeilijker en kan uiteenlopende antwoorden langer laten bestaan. Controleer eerst of de gezaghebbende servers de bedoelde gegevens publiceren, noteer oude en nieuwe waarden en laat nog geldige cache-antwoorden verlopen.

Lees de foutmelding voordat u instellingen verandert

Een melding dat een naam niet bestaat, vaak weergegeven als NXDOMAIN, zegt dat de opgevraagde naam als niet-bestaand is gemeld. Controleer de spelling, het exacte subdomein en het bijbehorende record. Een time-out betekent dat er binnen de toegestane tijd geen bruikbaar antwoord is ontvangen; de resolver, netwerkroute of filtering kan een rol spelen. SERVFAIL geeft aan dat de resolver de aanvraag niet kon afronden. Onjuiste verwijzing naar nameservers, problemen met DNSSEC-validatie en storingen verderop zijn mogelijke oorzaken. Een vereenvoudigde browsermelding bepaalt op zichzelf niet de oorzaak.

Bepaal hoe breed het probleem is. Werkt één website niet terwijl andere websites en e-mail wel werken, onderzoek dan die naam en dienst. Mislukken alle namen op slechts één apparaat, vergelijk een tweede apparaat in hetzelfde netwerk. Faalt het hele netwerk, controleer router en providerverbinding voordat u DNS als oorzaak aanwijst. Een HTTP-fout, aanmeldfout of certificaatwaarschuwing na een geslaagde opzoeking hoort bij een latere stap. Negeer een certificaatwaarschuwing niet omdat een hulpmiddel wel een adres heeft gevonden.

• Noteer de exacte naam, het tijdstip, de foutmelding en of een VPN actief was.
• Vergelijk dezelfde naam op een tweede apparaat en zo mogelijk via een andere vertrouwde verbinding.
• Leg de ingestelde resolver en eventuele veilige-DNS-instelling van de browser vast.
• Vraag het passende recordtype op; alleen een ping naar de website is onvoldoende.
• Meld fouten in domeinrecords of nameserververwijzingen aan de bevoegde domeinbeheerder.

Een veilige controlevolgorde voor thuis of een klein kantoor

Begin met iets dat niets wijzigt: controleer of de netwerkverbinding actief is, welke resolver is ingesteld en of meerdere onafhankelijke namen worden opgezocht. In Windows kan nslookup een naam via de ingestelde resolver of via een opgegeven server bevragen. Andere platforms hebben vergelijkbare hulpmiddelen. Bewaar het antwoord, inclusief de gebruikte server en het recordtype. Geen antwoord op een A-opvraag bewijst niet dat een naam ontbreekt wanneer deze alleen een AAAA-record heeft. De uitvoer moet worden beoordeeld in de context van de betrokken dienst.

Vergelijk vervolgens het getroffen apparaat met een werkend apparaat. Veilige DNS in de browser of een werk-VPN kan een ander pad gebruiken dan het systeemhulpmiddel. Test één toegestane wijziging tegelijk en zorg dat u de eerdere instelling kunt herstellen. Een tijdelijke vergelijking met een andere resolver kan op een eigen netwerk een storing helpen afbakenen, maar is geen algemene reparatie. Beheerde netwerken, ouderlijk toezicht en private domeinen kunnen de oorspronkelijke resolver nodig hebben. Terugzetten naar fabrieksinstellingen is zelden een passende eerste diagnosestap.

• Bewaar de oorspronkelijke DNS-configuratie vóór een toegestane wijziging.
• Gebruik een bekend, legitiem hulpmiddel in plaats van een willekeurige download die DNS zou repareren.
• Test na een correctie opnieuw de oorspronkelijke naam, e-mail en interne diensten.
• Verwijder tijdelijke instellingen die niet meer nodig zijn en documenteer de definitieve configuratie.

Versleutelde DNS, DNSSEC en websiteveiligheid beantwoorden andere vragen

DNS over HTTPS en DNS over TLS kunnen de verbinding tussen een client en de gebruikte resolver versleutelen. Ze maken de gebruiker niet anoniem, verbergen niet alle verbindingsinformatie en verklaren de bestemming niet veilig. De gekozen resolver blijft betrokken bij de opzoeking. Browserinstellingen kunnen bovendien verschillen van apparaatinstellingen. Daardoor kan een naam in de ene toepassing wel werken en in de andere niet. Kies een resolver met begrijpelijk beleid en omzeil niet ongemerkt de regels van een werk- of schoolnetwerk.

Met DNSSEC kunnen validerende resolvers ondertekende DNS-gegevens en hun vertrouwensketen controleren. Dit is geen versleuteling en geen onderzoek naar fraude of schadelijke software op de website. Een verouderd DS-record na het verhuizen van gezaghebbende DNS kan een correct ingevoerd adres voor validerende resolvers onbereikbaar maken. Domeinbeheerders moeten de gedocumenteerde verhuisprocedure van hun DNS-aanbieder volgen in plaats van DNSSEC zonder onderzoek uit te schakelen. Blijf HTTPS gebruiken, beoordeel onverwachte aanmeldverzoeken en houd accountbeveiliging gescheiden van DNS-onderzoek.

Hosting wijzigen zonder toegang tot website of e-mail te verliezen

Een domeinverhuizing begint met een inventaris. Bepaal welke leverancier registratie, DNS, hosting en e-mail beheert. Leg de gezaghebbende nameservers vast en alle dienstrecords die behouden moeten blijven. Controleer of de nieuwe DNS-zone de vereiste records bevat voordat u de verwijzing naar nameservers wijzigt. Volg de DNSSEC-aanwijzingen van de aanbieder, inclusief de omgang met DS-records bij de registrar. Plan een terugvalmogelijkheid en wijs iemand aan die bevoegd is het domein te wijzigen.

Controleer daarna de gezaghebbende antwoorden, de openbare website, inkomende en uitgaande e-mail en diensten die van verificatie afhankelijk zijn. Houd de vorige dienst waar mogelijk beschikbaar tijdens de geplande overgang. Een websiteverhuizing verhuist niet automatisch de mailboxen. Andere nameservers kiezen kopieert evenmin vanzelf de oude zone. Bent u bezoeker in plaats van domeineigenaar, meld dan de exacte naam en het tijdstip van de fout. Uw eigen DNS wijzigen kan geen record maken dat het domein nooit heeft gepubliceerd.

Voorbeeld: de nieuwe website werkt, maar e-mail komt niet meer aan

Stel dat een klein kantoor de website naar een ander hostingplatform verhuist. De beheerder wijzigt de nameservers van het domein en ziet de nieuwe homepage. Daarna komt e-mail niet meer aan. De DNS-zone bij de nieuwe aanbieder bevat het websiteadres, maar mist de eerdere MX-records en de benodigde records voor e-mailauthenticatie. Dit is een uitlegvoorbeeld, geen beweerd klantresultaat. Website en e-mail gebruiken hetzelfde domein, maar zijn afhankelijk van verschillende DNS-records.

De passende aanpak is de bewaarde oude zone vergelijken met de nieuwe, de precieze mailrecords bij de actieve mailaanbieder opvragen en deze door de bevoegde beheerder laten herstellen. Controleer de echte gezaghebbende antwoorden voordat u iedereen vraagt caches te legen. Bevestig dat de mailboxen zelf nog actief zijn. Test bezorging in beide richtingen en laat geldige oudere cache-antwoorden verlopen. Voorkomen begint met iedere dienst inventariseren, de bijbehorende records bewaren en de volledige zone controleren vóór een nameserverwijziging.