Wat is DNS en hoe werkt het voor uw VPS?

Wat is DNS en waarom uw domein uw VPS nog niet bereikt

DNS (domain name system) vertaalt een naam zoals example.com naar een IP (internet protocol) adres zoals 203.0.113.10. Een browser kan geen verbinding maken met een naam. Deze maakt verbinding met een adres, dus elke pagina die wordt geladen begint met een DNS-vraag en een antwoord. Als u zojuist een domein en een eigen VPS heeft aangeschaft en er wordt niets geladen, dan is een van de twee volgende situaties van toepassing: er is nog geen record dat de naam koppelt aan het adres van uw server, of er is wel een record maar ergens in het pad wordt nog een ouder antwoord verstrekt.

Beide situaties zijn normaal en betekenen niet dat er iets defect is. De onderstaande secties behandelen de onderdelen in de volgorde waarin u ze zult tegenkomen, te beginnen met het punt dat de meeste tijd in beslag neemt: welk configuratiescherm beheert daadwerkelijk uw records.

Elke controle hier maakt gebruik van dig, dat standaard niet is geïnstalleerd op een nieuwe Ubuntu- of Debian-machine.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameservers, DNS host: welke moet u aanpassen

Deze drie termen beschrijven verschillende taken. Ze door elkaar halen is de meest voorkomende reden waarom een wijziging geen effect heeft.

• De registrar is het bedrijf waar u het domein heeft gekocht. De cruciale taak is delegatie: het vertelt het register dat uw TLD (top-level domain, het .com-gedeelte) beheert welke nameservers autoritatief zijn voor uw domein.
• De autoritatieve nameservers bevatten de werkelijke records voor uw zone. Een zone is uw domein en de namen daaronder.
• De DNS host is de partij die deze nameservers beheert. Dit kan de registrar zijn, een aparte provider, of bind9 draaiend op een server die u zelf bezit.

U koopt bij de registrar. U brengt wijzigingen aan bij de DNS host. Als u uw domein heeft verplaatst naar de nameservers van een andere provider, toont het DNS-paneel van de registrar nog steeds een zone en slaat het uw wijzigingen op, maar niemand op het internet vraagt die zone ooit om informatie. De records zijn echt. Ze worden simpelweg nooit geraadpleegd.

Zoek uit waar de wereld de informatie opvraagt:

dig example.com NS +short
dig +trace example.com

Het eerste commando toont de nameservers die vandaag antwoord geven voor het domein. Het tweede commando doorloopt de keten vanaf de root-servers en toont de verwijzing die de TLD-servers verstrekken; dit is de delegatie die uw registrar beheert. Als die namen toebehoren aan een provider die u niet herkent, dan beheert die provider het paneel dat u nodig heeft.

Hoe een enkele opzoeking verloopt

Er zijn vier partijen betrokken en elk van hen bewaart een kopie van wat er wordt geleerd.

1. De stub resolver op uw machine. Deze voert zelf geen zoekopdrachten uit. Hij vraagt het aan één geconfigureerde server en vertrouwt op het antwoord. Op Ubuntu is /etc/resolv.conf meestal een symlink naar /run/systemd/resolve/stub-resolv.conf en wijst dit naar 127.0.0.53, wat systemd-resolved is die lokaal draait met een eigen cache.
2. De recursive resolver. Dit is de resolver die door uw ISP (internet service provider) wordt beheerd, een publieke variant zoals 1.1.1.1, of een resolver die u zelf draait. Deze voert het eigenlijke werk uit om het antwoord te vinden.
3. De root- en TLD-servers. De recursive resolver vraagt het aan een root-server, die uw adres niet kent maar antwoordt met een verwijzing naar de .com-servers. Deze antwoorden vervolgens met een verwijzing naar uw nameservers.
4. De authoritative nameserver. Deze vraagt het aan niemand. Hij antwoordt vanuit uw zone en markeert het antwoord als autoritatief.

dig +trace example.com laat u zien hoe dit proces verloopt, omdat het bij de root zelf begint en elke verwijzing toont in plaats van een cache te raadplegen. Dat is de snelste manier om te controleren of de delegatie en de zone met elkaar overeenstemmen.

De DNS-records die van belang zijn bij het beheren van een server

• A: koppelt een naam aan een IPv4-adres. example.com. A 203.0.113.10. Dit is het record dat uw domein naar uw VPS verwijst.
• AAAA: koppelt een naam aan een IPv6-adres, zoals 2001:db8::10. Publiceer dit alleen wanneer uw service daadwerkelijk op dat adres luistert. Clients op IPv6-netwerken proberen eerst het AAAA-antwoord; een adres waarop niets reageert, zorgt voor vertraging bij elk bezoek.
• CNAME: een alias van de ene naam naar de andere. www.example.com. CNAME example.com. stuurt bezoekers van www door naar het adres waar het hoofddomein naar verwijst. Een CNAME kan niet op het apex-niveau (het kale example.com) staan, omdat het apex-niveau zijn eigen SOA (start of authority) en NS-records moet bevatten, en een CNAME mag geen naam delen met enig ander record. Providers bieden hiervoor oplossingen onder namen als ALIAS, ANAME of CNAME flattening.
• MX: bepaalt waar e-mail voor het domein wordt afgeleverd. Het bevat een hostnaam en een voorkeursnummer; het laagste nummer wordt als eerste geprobeerd. Een MX moet verwijzen naar een naam die een adresrecord heeft. Verwijzen naar een CNAME is ongeldig en sommige verzendende servers zullen dit weigeren.
• TXT: vrije tekst, gebruikt voor verificatie en beleid. E-mailauthenticatierecords (SPF, DKIM, DMARC) staan hier, evenals het ACME-token (automatic certificate management environment) dat een wildcard-certificaat uitgeeft.
• NS: bepaalt welke nameservers de zone beheren. De kopie die bepaalt waar de wereld de informatie opvraagt, bevindt zich in de parent zone en is afkomstig van de delegatie bij uw registrar, niet van de kopie binnen uw eigen zone.

Twee details zorgen voor meer verwarring dan de recordtypes zelf. Een naam die eindigt op een punt is absoluut, dus www.example.com. betekent precies dat en niets meer. De meeste beheerpanelen verwachten een relatieve naam en voegen het domein automatisch voor u toe; het invoeren van www.example.com in het naamveld resulteert dus in www.example.com.example.com, wat voor niemand zal resolven. Het andere detail is @, wat in bijna elk paneel het apex-niveau betekent: het domein op zichzelf, zonder subdomein.

Wijs een A-record naar uw VPS

Bepaal eerst het adres waaronder uw server op internet bekend is:

curl -4 https://ifconfig.me
ip -brief -4 address show

Maak vervolgens één record aan bij uw DNS-provider: type A, naam @, waarde het betreffende adres, TTL (time to live) 300. Voeg een tweede record toe voor www, hetzij als een ander A met hetzelfde adres, hetzij als een CNAME die naar het apex-domein verwijst.

Controleer nu of de resolutie werkt, bij voorkeur vanaf uw laptop in plaats van vanaf de server zelf:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Het eerste commando gebruikt het standaardpad van uw machine, inclusief caches. Het tweede commando slaat uw lokale cache over en vraagt een publieke recursieve resolver. Het derde commando vraagt direct uw autoritatieve nameserver, waardoor het antwoord de actuele status zonder enige cache in het pad weergeeft. Wanneer het derde commando uw adres teruggeeft en het eerste niet, is uw DNS correct geconfigureerd en wacht u op het verlopen van een gecachte kopie van het oude antwoord.

Naamresolutie laadt niet

Een geslaagde naamresolutie bewijst dat DNS werkt. Het zegt niets over uw webserver. Zodra dig het juiste adres teruggeeft, test u de verbinding:

curl -I http://example.com

curl: (6) Could not resolve host: example.com duidt op een DNS-probleem. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused is geen DNS-probleem: de naam is opgelost en het pakket is aangekomen; het probleem is dat er niets op die poort luisterde. Een verzoek dat blijft hangen en vervolgens een time-out geeft, betekent meestal dat een firewall het pakket stilletjes heeft gedropt in plaats van het te weigeren. Op dat punt is DNS niet langer het onderwerp en nemen poorten en listening sockets en de ufw firewall-regels op uw VPS het over. Nadat de verbinding tot stand is gekomen, is de rest van het laden van de pagina HTTP dat zijn werk doet.

Waarom de browser nog steeds de oude host toont

Er is geen sprake van propagatie. Geen enkele server pusht uw wijziging naar buiten. Uw autoritatieve nameserver bevat de nieuwe waarde zodra u deze opslaat, en elke gecachte kopie van het vorige antwoord blijft geldig totdat de eigen timer verloopt. Die timer is de TTL, in seconden, die het record meekreeg toen het werd verstrekt.

Kopieën bevinden zich op meer plaatsen dan men verwacht: de korte cache van de browser zelf, de stub resolver op de machine, de recursieve resolver die door dat netwerk wordt gebruikt, en elke resolver die door een VPN op de client is geïnstalleerd. Elk houdt zijn kopie vast tot de ontvangen TTL is verstreken. Twee personen op twee netwerken kunnen urenlang twee verschillende antwoorden zien, en beide machines gedragen zich correct.

Monitor het aftellen bij een caching resolver:

dig @1.1.1.1 example.com +noall +answer

Voer dit twee keer uit, met enkele seconden ertussen. De TTL in het antwoord loopt af. Wanneer deze nul bereikt, gooit de resolver het record weg en vraagt het opnieuw op bij uw nameserver.

Er is een tweede cache waar bijna niemand rekening mee houdt: negatieve antwoorden. Wanneer een resolver te horen krijgt dat een naam niet bestaat, cacht deze ook de NXDOMAIN, voor de tijd die is ingesteld in het laatste veld van het SOA-record van uw zone.

dig example.com SOA +short

Het laatste getal op die regel is de negatieve TTL, vaak 3600. Het opzoeken van staging.example.com voordat u het aanmaakt, kan het record dus een uur lang voor u verbergen nadat u het heeft aangemaakt. Maak eerst het record aan en voer daarna pas de query uit.

Het wijzigen van nameservers is trager dan het wijzigen van een record, en de reden daarvoor is mechanisch. De delegatie-records in de .com zone worden geserveerd met een TTL van 172800 seconden, wat twee dagen is. Een resolver die uw oude nameservers heeft gecacht, kan deze dus zo lang blijven bevragen. Dit is waar het advies om "tot 48 uur te wachten" vandaan komt. Dit is van toepassing op wijzigingen van nameservers, niet op gewone wijzigingen van records.

Plan een migratie rondom de TTL in plaats van ertegen te vechten:

1. Verlaag de TTL van het record naar 300 en sla het op.
2. Wacht langer dan de oude TTL, zodat elke gecachte kopie met de oude waarde is verlopen.
3. Wijzig het adres.
4. Zodra het verkeer is verplaatst, verhoogt u de TTL weer naar 3600 of hoger, omdat een lage TTL betekent dat elke resolver uw nameservers veel vaker bevraagt.

Om te wissen wat uw eigen machine vasthoudt:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics toont een cache-sectie met hit- en miss-tellers, dus direct na een flush verschijnt de volgende lookup als een miss. Browsers houden een aparte cache bij, wat betekent dat Chrome nog steeds een oud antwoord kan gebruiken nadat de systeemcache leeg is. Wis die cache op chrome://net-internals/#dns. Controleer ook /etc/hosts, omdat een achtergebleven regel daar DNS op die machine (en alleen op die machine) overrulet. getent hosts example.com toont het antwoord dat het systeem daadwerkelijk zal gebruiken, inclusief /etc/hosts.

Wildcard-certificaten worden geverifieerd met een TXT-record

Een CA (certificate authority) controleert of u de eigenaar bent van een domeinnaam voordat deze een certificaat uitgeeft. De HTTP-01-challenge serveert een bestand via poort 80 op die specifieke hostnaam, wat goed werkt voor een enkele naam. Een wildcard-certificaat dekt *.example.com, een onbeperkte set hostnamen waarvan de CA geen bestand kan ophalen. Daarom geeft Let's Encrypt wildcards alleen uit via de DNS-01-challenge. U publiceert een TXT-record op _acme-challenge.example.com met een token dat de CA aan u verstrekt; het beheer over de zone geldt hierbij als bewijs.

Dit maakt uw DNS-provider onderdeel van de certificaatvernieuwing. Certbot moet bij elke vernieuwing automatisch dat TXT-record aanmaken en verwijderen, dus is er een API en een bijbehorende plugin voor uw provider vereist. Wanneer de validatie mislukt, is de gebruikelijke melding DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Dit betekent dat de CA het record opvroeg voordat het zichtbaar was: het record is niet opgeslagen of er was nog sprake van een gecachet negatief antwoord. De volledige procedure vindt u in de handleiding voor wildcard-certificaten met de DNS-01-challenge.

Wanneer een VPN uw resolver overneemt

Een VPN-client (virtual private network) vervangt normaal gesproken de systeem-resolver zolang de verbinding actief is. Dit is nodig omdat het versturen van opzoekopdrachten naar het lokale netwerk dat netwerk zou informeren over elke site die u bezoekt. Dit is het juiste gedrag, maar het kan op twee manieren misgaan.

Als de tunnel tot stand komt en namen niet langer worden omgezet terwijl IP-adressen nog wel werken, dan is de resolver die de client heeft geïnstalleerd onbereikbaar vanuit de tunnel. ping 1.1.1.1 slaagt en curl https://example.com geeft curl: (6) Could not resolve host: example.com terug. Als de tunnel daarentegen tot stand komt en opzoekopdrachten nog steeds naar het netwerk gaan waar u zich op bevindt, wordt uw verkeer wel getunneld, maar ziet de lokale resolver elke naam waar u om vraagt.

resolvectl status

Dit commando toont de resolver die per link in gebruik is, zodat u kunt zien welke de tunnel heeft geïnstalleerd en of dit de bedoelde resolver is. Een WireGuard-tunnel stelt dit in via de DNS =-regel in de clientconfiguratie, en DNS herstellen wanneer WireGuard de resolver overneemt behandelt de gevallen voor systemd-resolved en resolvconf in detail.

De antwoordcodes en wat ze betekenen

• NXDOMAIN: een autoritatieve server geeft aan dat de naam niet bestaat. Controleer de spelling, controleer op een dubbele domeinextensie en controleer of u de zone heeft bewerkt waar uw delegatie naar verwijst.
• NOERROR met een leeg ANSWER SECTION: de naam bestaat, maar er is geen record van het type waar u om vroeg. Vragen naar een AAAA terwijl alleen een A bestaat, resulteert precies hierin.
• SERVFAIL: de resolver heeft geprobeerd een antwoord te genereren, maar dit is mislukt. De twee meest voorkomende oorzaken zijn autoritatieve servers die niet antwoorden en het falen van DNSSEC (domain name system security extensions) validatie. Test dit met dig @1.1.1.1 example.com A +cd, waarmee validatie wordt uitgeschakeld. Een antwoord met +cd en SERVFAIL zonder deze vlag betekent dat de handtekeningen het probleem vormen; dit gebeurt vaak na een verhuizing van de nameserver waarbij de parent-zone nog het oude DS (delegation signer) record publiceert.
• REFUSED: de server die u bevroeg, zal die vraag niet beantwoorden. Dit gebeurt meestal omdat u dig heeft gericht op een autoritatieve server voor een domein dat deze niet beheert.
• ;; connection timed out; no servers could be reached: dig heeft nooit een resolver bereikt. Dit is een netwerk- of resolverprobleem aan uw kant; het domein zelf is hierbij niet het onderwerp.

ping: example.com: Temporary failure in name resolution is dezelfde klasse van foutmelding, maar dan gerapporteerd door glibc in plaats van door dig.

Is het verstandig om nameservers op uw eigen VPS te draaien?

Dat kan. bind9, knot of nsd kunnen uw zone vanaf de server bedienen, en u leert hierdoor meer over DNS dan met welk paneel dan ook. De bezwaren zijn praktisch van aard. Een domein hoort ten minste twee nameservers op gescheiden netwerken te hebben; een enkele VPS wordt anders een single point of failure voor elke dienst op het domein, inclusief e-mail. Nameservers die vernoemd zijn naar het domein dat ze bedienen, vereisen glue records bij de registrar. Dit is het adres van ns1.example.com dat in de parent zone wordt opgeslagen, omdat de opzoeking anders niet kan starten. Wanneer een resolver uw nameserver niet kan bereiken, valt deze niet terug op uw website: het gehele domein verdwijnt voor die gebruiker. Gehoste DNS met een API is voor de meeste mensen de keuze met het laagste risico. Het draaien van een caching resolver op uw VPS voor uw eigen machines is een andere taak en vergt aanzienlijk minder onderhoud.

FAQ

Waarom is mijn DNS-wijziging nog niet doorgevoerd?

Niets wordt doorgevoerd. Uw autoritatieve nameservers bevatten de nieuwe waarde op het moment dat u deze opslaat, en elke resolver die de waarde al heeft opgevraagd, behoudt zijn gecachte kopie totdat de ontvangen TTL is verstreken. Vraag de autoritatieve server direct met dig @ns1.your-dns-host.net example.com A +short. Als deze het nieuwe adres teruggeeft, is de wijziging live en is alles wat overblijft caching. Als u nameservers heeft gewijzigd in plaats van records, houd er dan rekening mee dat dit veel langer duurt, omdat TLD-delegaties worden uitgegeven met een TTL van twee dagen.

Hoe vind ik welke nameservers mijn domein daadwerkelijk gebruikt?

dig example.com NS +short toont de nameservers die momenteel antwoorden voor het domein, en dig +trace example.com toont de verwijzingsketen vanaf de root, inclusief de delegatie die de TLD-servers verstrekken. Als die namen niet overeenkomen met de provider wiens paneel u heeft bewerkt, is dat de oorzaak van uw probleem. Bewerk de records bij de provider die in de delegatie wordt genoemd, of wijzig de delegatie bij uw registrar zodat deze naar de gewenste locatie wijst.

Mijn domein resolveert, maar de site laadt nog steeds niet. Wat nu?

DNS is voltooid zodra dig example.com A +short het adres van uw server teruggeeft. Daarna is het probleem de verbinding. Als curl -I http://example.com de melding Connection refused geeft, betekent dit dat er niets op die poort luistert. Een verzoek dat blijft hangen totdat het een time-out geeft, betekent dat een firewall het pakket heeft geweigerd. Controleer of uw webserver draait en is gebonden aan het publieke adres, en controleer vervolgens de firewall op de server en de afzonderlijke netwerkfirewall in het configuratiescherm van uw provider.

Waarom kan ik geen CNAME op mijn root-domein plaatsen?

Een CNAME geeft aan dat een naam een alias is voor een andere naam, en een naam die een CNAME heeft, mag geen enkel ander record bevatten. Uw root-domein moet SOA- en NS-records bevatten om als zone te kunnen bestaan, dus het kan geen CNAME zijn. Gebruik een A-record met het adres op de root, of gebruik de providerfunctie die wordt verkocht als ALIAS, ANAME of CNAME flattening, die een naam opslaat en vragen beantwoordt met het adres waarnaar die naam momenteel resolveert.