Stel dat het serveradres van een domein is gewijzigd: thuis opent de nieuwe website, maar de telefoon maakt nog verbinding met de oude server. Ook bij dezelfde naam kunnen de uitkomsten tijdelijk verschillen als apparaten andere DNS-caches gebruiken. Een HTTP-cache die gedownloade pagina's hergebruikt en een DNS-cache die een verbindingsadres helpt vinden, vragen om verschillende controles.
Dit artikel volgt de fictieve bibliotheekhost www.library.example om naamomzetting en caching uit te leggen. Namen en tijdschema zijn illustraties, geen metingen van antwoorden van een echte dienst. Het doel is onderscheid te maken tussen het vinden van een adres, vertraagd zichtbare wijzigingen en fouten na de naamomzetting.
1. DNS geeft per naam verschillende soorten antwoorden
DNS levert informatie bij domeinnamen via verschillende recordtypen. A staat voor een IPv4-adres en AAAA voor een IPv6-adres; een naam kan meerdere adressen hebben. CNAME is een alias naar een andere naam, MX verwijst naar een server die mail ontvangt en NS naar een autoritatieve nameserver voor de zone. Dezelfde naam opvragen kan dus verschillende antwoorden geven als het gevraagde recordtype verschilt.
Zoals Cloudflares uitleg over DNS-records beschrijft, bevat CNAME een andere naam, geen IP-adres. Om een adres te krijgen, moet mogelijk ook die naam worden opgelost. In https://www.library.example/books behandelt DNS de hostnaam www.library.example. Het pad /books en de pagina-inhoud worden niet in DNS geregistreerd. Een CNAME instellen maakt niet automatisch een HTTP-omleiding die de adresbalk van de browser verandert.
2. Hoe een recursieve resolver autoritatieve servers vindt
De naamomzetting van een apparaat vraagt meestal de ingestelde recursieve resolver om antwoord. Die gebruikt beschikbare cachegegevens of bevraagt andere DNS-servers en geeft het uiteindelijke antwoord of een fout terug. De standaard voor DNS-terminologie RFC 9499 onderscheidt dit namens de client zoeken van de autoritatieve server, die informatie over zijn eigen zone bezit. Lees de herkomst van een antwoord in het licht van de rol van de server.
In een vereenvoudigd traject zonder caches of tussenpersonen verwijst de root de resolver naar servers van het topleveldomein, die vervolgens verwijzen naar de autoritatieve servers van de doelzone. De laatste autoritatieve server levert het gewenste record of de alias. Eén rootserver bewaart niet de IP-adressen van alle websites. In werkelijkheid kan de zoektocht beginnen bij opgeslagen delegatiegegevens of worden doorgestuurd naar een andere resolver. Niet elk bezoek herhaalt daarom de hele reeks.
3. TTL is resterende cacheduur, geen wereldwijde klok
De TTL van een record geeft de cachelevensduur in seconden door. Bij gewone antwoorden uit een cache neemt de resterende tijd tijdens opslag af. Slaat een resolver om 10:00 een adres met TTL 300 seconden op, dan heeft een antwoord uit diezelfde kopie om 10:02 nog ongeveer 180 seconden. De tabel veronderstelt één resolver zonder tussentijdse herbevraging, vervroegde verversing of het aanbieden van verlopen antwoorden.
| Fictieve tijd | Adres op de autoritatieve server | Wat deze resolver doet |
|---|---|---|
| 10:00 | Oud adres | Slaat het oude adres op met TTL 300 seconden |
| 10:01 | Gewijzigd naar nieuw adres | De opgeslagen kopie heeft nog 240 seconden |
| 10:03 | Nieuw adres | Kan het oude adres nog 120 seconden hergebruiken |
| Eerste vraag na 10:05 | Nieuw adres | Aangenomen wordt dat een nieuwe vraag het nieuwe adres oplevert, in plaats van de verlopen kopie |
Andere resolvers hebben het record misschien later opgeslagen of nog nooit gezien. Hun verversmomenten verschillen, dus één TTL bepaalt niet wanneer alle gebruikers wereldwijd tegelijk overstappen. Een cache kan gegevens vóór afloop weggooien; een webpagina vernieuwen wist ook niet de kopie van een gedeelde resolver. TTL helpt DNS-hergebruik begrijpen, maar begrenst niet de hele webverbinding of schermverversing.
4. Wanneer TTL verlagen en hoe afwezigheid wordt gecachet
Een cache die het oude adres met TTL 3.600 seconden ontving, krijgt niet direct te horen dat de beheerder die nu naar 60 seconden verlaagt. Pas bij een geplande adreswijziging de TTL vooraf aan en houd rekening met antwoorden die nog onder de oude langere levensduur zijn opgeslagen. Een lagere TTL kan vaker op wijzigingen laten controleren, maar verhoogt ook de vraagbelasting en afhankelijkheid van autoritatieve servers. Bekijk wijzigingsplan en storingsaanpak samen, in plaats van overal hetzelfde korte getal toe te passen.
Ook NXDOMAIN, dat een niet-bestaande naam aangeeft, en NODATA, voor een bestaande naam zonder het gevraagde recordtype, kunnen worden gecachet. De standaard voor negatieve caching RFC 2308 bepaalt die levensduur uit de laagste waarde van de TTL van het SOA-record van de autoritatieve server en het SOA-veld MINIMUM. Een eerder antwoord dat iets ontbreekt, kan dus direct na het toevoegen van een host blijven bestaan. Aannemen dat dit dezelfde levensduur heeft als het nieuwe A-record kan de oorzaak verhullen.
5. Houd naam, type en server gelijk bij controles
Noteer de exacte gevraagde naam, het type zoals A of AAAA, de bevraagde DNS-server en het tijdstip. Als dig is geïnstalleerd, kunt u naam en type opgeven met dig example.com A. Vervang example.com bij een echt probleem door de host die u wilt controleren. Dit commando illustreert een procedure; het is voor dit artikel niet uitgevoerd en er zijn geen antwoordtijden mee gemeten.
Bekijk de antwoordstatus samen met namen, typen, waarden en TTL in ANSWER. Controleer bij herhaling van dezelfde vraag aan dezelfde resolver of TTL afneemt, maar beschouw een stijging niet meteen als fout. Er kan vroegtijdig zijn ververst of een ander cacheknooppunt kan hebben geantwoord. Door A en AAAA apart vast te leggen, ziet u makkelijker welke adresfamilie afwijkt.
Als beheerder kunt u voor dezelfde naam en hetzelfde type het antwoord van de recursieve resolver vergelijken met dat van de autoritatieve server van uw zone. Controleer bij verschillen achtereenvolgens resterende cachetijd, overeenstemming tussen autoritatieve servers en delegatie-instellingen. Generaliseer het antwoord van één publieke resolver niet naar alle gebruikers. Interne bedrijfs-DNS of eigen DNS-instellingen van de browser kunnen het traject veranderen; noteer daarom ook de verbindingsomgeving.
6. Onderscheid DNS-fouten, verbindingsfouten en uitzonderingen
NXDOMAIN meldt dat de naam niet bestaat en NODATA dat het gevraagde recordtype ontbreekt. SERVFAIL betekent daarentegen dat de server de vraag niet kon verwerken; een time-out betekent dat er binnen de wachttijd geen antwoord kwam. Interpreteer die gevallen niet allemaal als een verwijderd domein. Bewaar eerst of er een antwoordcode was en welke server is bevraagd om de volgende controle te kiezen.
Een oud antwoord na TTL-verloop is niet altijd een overtreding. De serve-stale-methode in RFC 8767 beschrijft hoe verlopen gegevens de beschikbaarheid kunnen verbeteren wanneer verversing bij autoritatieve servers uitzonderlijk onmogelijk is. Dat betekent niet dat alle resolvers dit met dezelfde instellingen gebruiken. Controleer de gebruikte resolver zelf in plaats van uit één TTL een gegarandeerde wijzigingstermijn af te leiden.
Een geslaagde adresomzetting garandeert tot slot geen toegang tot de website. Netwerkroute, TLS-certificaat, webserver en applicatie zijn afzonderlijke stappen. Geeft DNS het verwachte adres maar opent de pagina niet, onderzoek dan de daaropvolgende verbinding. Door DNS-antwoorden en webantwoorden apart vast te leggen, vindt u de fout eerder dan door blind paginacaches te wissen of DNS-instellingen te veranderen.