Linux concept: DNS

1. De basis

Het Domain Name System zet namen om in de informatie die een computer nodig heeft om een dienst te bereiken. Meestal is dat een IP-adres, maar DNS draagt ook waar je mail heen gaat, welke certificaatautoriteiten voor jou mogen uitgeven, en welke servers namens jou mogen verzenden.

Het wordt vaak het telefoonboek van het internet genoemd. Die vergelijking is geruststellend en net niet juist, want een telefoonboek is een document dat iemand drukt. DNS is een gedistribueerde database met gedelegeerd gezag: geen enkele machine bevat het geheel, geen enkele organisatie publiceert het, en elk deel wordt beantwoord door wie de verantwoordelijkheid voor dat deel gekregen heeft.

Die delegatie is het hele ontwerp. De root delegeert .nl aan het Nederlandse register. Het Nederlandse register delegeert petermartin.nl aan de naamservers die de eigenaar opgegeven heeft. Die naamservers antwoorden voor alles daaronder. Elk niveau weet net genoeg om naar het volgende te wijzen.

Het juiste mentale model: DNS is geen opzoektabel, het is een keten van doorverwijzingen. Niemand heeft het hele antwoord; iedereen weet wie je vervolgens moet vragen. Bijna elk verwarrend DNS-probleem is een gebroken schakel in die keten, of een gecachete kopie van een schakel die intussen veranderd is.

1.1 De vier rollen

Bij elke lookup zijn vier verschillende soorten software betrokken, en ze door elkaar halen is verreweg de meest voorkomende bron van verwarring. Ze zijn niet uitwisselbaar.

Het praktische gevolg: "de DNS klopt niet" is nooit een volledige zin. Een record kan tegelijkertijd juist zijn op de autoritatieve server, verouderd in een recursieve resolver en afwezig in de cache van je eigen machine, en alle drie gedragen zich zoals het hoort.

1.2 Wat een lookup werkelijk doet

Als je browser www.petermartin.nl nodig heeft en er nergens iets gecachet is, ziet de reis er zo uit:

your browser
    ↓  "where is www.petermartin.nl?"
stub resolver (127.0.0.53)
    ↓
recursive resolver (your ISP, or 1.1.1.1)
    ↓  asks a root server: "who handles .nl?"
    ↓  asks the .nl registry: "who handles petermartin.nl?"
    ↓  asks Cloudflare: "what is www.petermartin.nl?"
    ↓
back up the chain, cached at every step that allows it

Drie verzoeken aan drie verschillende organisaties, voor een naam. Dat klinkt traag, en de eerste lookup is dat ook. Elke stap daarna wordt uit de cache beantwoord tot de TTL afloopt, en daarom voelt het tweede bezoek aan een site meteen snel.

Het belangrijkste is wat er gecachet wordt en waar. De recursieve resolver cachet het antwoord en de doorverwijzingen, dus de volgende bezoeker die om een andere naam onder .nl vraagt slaat de root helemaal over. Dit is ook waarom een wijziging die je doorvoert voor sommige mensen onzichtbaar is en voor andere niet: hun resolvers cachetten op verschillende momenten.

1.3 Waar dit artikel over gaat

Dit artikel gaat over DNS als iets wat je ontwerpt en beheert: wie welk stuk in handen heeft, hoe je een zone indeelt, hoe mailauthenticatie in elkaar past, wat je aan weerbaarheid en DNSSEC doet, en welke beslissingen je later spijt gaan geven.

Het herhaalt bewust niet de techniek van DNS inspecteren vanaf de opdrachtregel. Voor records lezen, een delegatie volgen, een cache controleren en TTL-waarden kiezen, zie het bijbehorende artikel over het dig-commando, dat het gereedschap uitgebreid behandelt. Hier is de vraag niet "hoe zie ik het" maar "wat hoort het te zijn".

3. Een korte geschiedenis

DNS is niet ontworpen als een grootse architectuur. Het is geschreven om een administratieve crisis op te lossen: een tekstbestand dat niet meer meeschaalde.

Voor DNS hield elke machine op het ARPANET een lokale kopie bij van een enkel bestand met de naam HOSTS.TXT, beheerd door het Network Information Center van het Stanford Research Institute. Elke nieuwe host betekende dat bestand aanpassen, en elke machine op het netwerk het opnieuw downloaden. Naarmate het netwerk groeide, groeide het bestand, groeiden de downloads, en groeide de vertraging tussen "er is een host" en "iedereen weet het".

In november 1983 publiceerde Paul Mockapetris de vervanging als twee documenten: RFC 882, "Domain Names Concepts and Facilities", dat het idee beschreef, en RFC 883, "Domain Names Implementation and Specification", dat vastlegde hoe het over de lijn werkte. Het inzicht was om niet langer een bestand te verspreiden, maar gezag.

Twee dingen zijn het meenemen waard uit die tabel. De kernspecificatie is uit 1987 en is nooit vervangen, alleen uitgebreid. En elke uitbreiding sindsdien ging over de twee dingen waar het origineel geen rekening mee hield: bewijzen dat een antwoord echt is (DNSSEC), en de vraag privé houden (DoT en DoH). Het oorspronkelijke ontwerp ging uit van een klein netwerk waarin men elkaar vertrouwde, want in 1983 was dat ook zo.

5. Een zone ontwerpen

Zodra de delegatie naar jouw naamservers wijst, is alles binnen de zone jouw beslissing. De meeste zones zijn klein, en de meeste ellende erin komt voort uit vier of vijf keuzes die zonder veel nadenken gemaakt zijn en pijnlijk terug te draaien zijn.

5.1 De apex, en waarom CNAME daar niet werkt

De apex (of "root" van je zone) is het kale domein, example.com zonder iets ervoor. Hij is bijzonder, en hij pakt iedereen precies een keer.

Je kunt geen CNAME op de apex zetten. De standaarden verbieden dat een CNAME naast welk ander record dan ook staat, en de apex draagt altijd SOA- en NS-records, want dat is wat er een zone van maakt. Een CNAME daar wordt dus niet alleen afgeraden; hij is niet te representeren.

Dat botst rechtstreeks met moderne hosting, waar providers je een naam geven in plaats van een adres, juist zodat ze het adres erachter kunnen wijzigen. De oplossingen, in volgorde van voorkeur:

Biedt je provider flattening aan, gebruik het dan. Zo niet, dan is dat een echte reden om er een te overwegen die het wel doet.

5.2 Kies www of juist niet, en houd je eraan

Allebei werkt. Wat problemen geeft is ze als gelijken bedienen, want dan bestaat elke pagina op twee adressen, en moeten zoekmachines, cookies en certificaten allemaal te horen krijgen dat het hetzelfde is.

Kies er een als canoniek, publiceer allebei in DNS, en verwijs de een naar de ander door met een permanente redirect op de webserver. De DNS-kant is onopvallend:

example.com.        300   IN   A       203.0.113.10
www.example.com.    300   IN   CNAME   example.com.

De CNAME is prima op www, want www is een gewone naam binnen de zone en niet de apex. Alleen de apex is beperkt.

5.3 Subdomeinen: records of delegatie?

Er zijn twee behoorlijk verschillende manieren om een subdomein te hebben, en de verkeerde kiezen levert later werk op.

• Records in je eigen zone. shop.example.com is gewoon nog een naam die je naast al het andere beheert. Dit is bijna altijd wat je wilt.
• Delegatie. Je publiceert NS-records voor shop.example.com die naar andermans naamservers wijzen, en geeft die hele tak uit handen. Vanaf dat moment kun je niets erbinnen zien of repareren.

Delegeer alleen wanneer een ander team of platform echt zijn eigen records op snelheid moet kunnen beheren, en dat betekent in de praktijk grote organisaties en sommige cloudplatformen. Voor een enkele site voegt delegatie een tweede plek toe waar dingen kapot kunnen en een tweede vertrouwensketen die intact moet blijven.

5.4 Wildcards antwoorden voor namen die je nooit aangemaakt hebt

Een wildcard-record past op alles wat geen eigen vermelding heeft:

*.example.com.      300   IN   A       203.0.113.10

Het ziet er handig uit en het verandert stilletjes de betekenis van je zone. Elke typefout wordt nu opgezocht. Elk subdomein dat een aanvaller verzint wordt opgezocht. Monitoring die controleert "bestaat deze naam" zegt altijd ja. En een wildcard plus een toegeeflijke webserver is de klassieke opzet voor subdomain takeover, waarbij iemand zijn eigen inhoud serveert op een naam die van jou lijkt.

Gebruik een wildcard als je werkelijk onbeperkt veel namen bedient, zoals klantsubdomeinen op een platform. Zet anders de namen neer die je echt hebt. Het typen is niet het dure deel van een zone beheren.

5.5 Split horizon: dezelfde naam, twee antwoorden

Sommige organisaties antwoorden verschillend op dezelfde naam, afhankelijk van wie het vraagt: een privé-adres op het kantoornetwerk, een publiek adres van buitenaf. Dit heet split horizon, en het is een legitiem ontwerp.

Het is ook een valkuil voor wie het later moet uitzoeken, want twee mensen die te goeder trouw hetzelfde commando draaien krijgen verschillende antwoorden en concluderen allebei dat de ander in de war is. Draai je split horizon, documenteer het dan waar degene met dienst het vindt, en verwacht dat elk extern DNS-controlegereedschap iets anders zegt dan wat jij aan je bureau ziet.

5.6 TTL's kiezen

Elk record draagt een TTL, het aantal seconden dat een resolver het mag cachen, en die waarde is een echte ontwerpbeslissing en geen standaard om maar te accepteren. Hij bepaalt hoe snel je kunt bewegen, en hoe lang je blijft werken als je naamservers dat niet doen.

Kort samengevat: 300 seconden voor adressen, een dag voor NS-records, een uur voor mail- en tekstrecords, en verlaag alles een dag voor een geplande migratie. De onderbouwing, met metingen aan goed beheerde domeinen en de afweging in beide richtingen, staat in het dig-artikel, dat ook laat zien hoe je leest wat een zone werkelijk publiceert in plaats van wat een cache je vertelt.

7. DNS op een Linux-machine

Alles tot nu toe ging over het domein dat je publiceert. Deze sectie gaat over de machine voor je neus, want de clientkant heeft zijn eigen regels en die zijn de reden dat twee mensen dezelfde lookup kunnen draaien en het oneens zijn.

7.1 Je resolv.conf is waarschijnlijk een symlink

De traditionele plek waar een Linux-machine zijn resolverinstellingen bewaart is /etc/resolv.conf. Generaties documentatie zeggen dat je dat bestand moet aanpassen. Op een modern systeem klopt dat advies meestal niet, en hier is het bewijs:

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 24  2024 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

Het bestand is een symlink naar een map die bij het opstarten opnieuw aangemaakt wordt. Alles wat je erin typt is de volgende herstart kwijt, of eerder. Verschillende programma's kunnen het genereren: systemd-resolved, NetworkManager, een DHCP-client, resolvconf, een VPN-client of een containerruntime.

Op de meeste netwerken komen de DNS-servers in dat bestand helemaal niet van een persoon: ze kwamen binnen in een DHCP-lease, samen met het adres en de gateway. Het bijbehorende artikel over DHCP behandelt waar die instellingen vandaan komen en waarom ze hier aanpassen niet blijvend is.

Die 127.0.0.53 is geen DNS-server op het internet. Het is de lokale stub, en de echte bovenliggende servers zitten erachter, per netwerkinterface. De eerlijke manier om ze te zien is het vragen aan degene die ze beheert:

$ resolvectl status | grep -A2 'Current DNS Server'
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

$ resolvectl query petermartin.nl
petermartin.nl: 2a01:4f8:c0c:6848::1                        -- link: wlp0s20f3
                23.88.98.40                                 -- link: wlp0s20f3

-- Information acquired via protocol DNS in 5.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no

De laatste regel is het twee keer lezen waard. Die meldt of het antwoord met DNSSEC gevalideerd is en of het versleuteld gereisd heeft, twee dingen waar mensen meestal naar raden. Hier is het antwoord op allebei "no", wat de normale toestand is op een laptop die met een thuisrouter praat.

Wil je de instellingen wijzigen, wijzig ze dan waar ze gemaakt worden: het verbindingsprofiel in NetworkManager, de DHCP-server, of /etc/systemd/resolved.conf. Het doel van de symlink aanpassen is een oplossing die het tot dinsdag volhoudt.

7.2 De volgorde waarin Linux werkelijk opzoekt

DNS is niet de enige manier waarop een Linux-machine een naam in een adres omzet, en het is niet per se de eerste. De volgorde staat in /etc/nsswitch.conf:

$ grep '^hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns mymachines

Van links naar rechts gelezen kijkt die machine eerst in /etc/hosts, dan naar multicast-DNS voor .local-namen, en pas daarna naar echt DNS. Het [NOTFOUND=return] tussen haken betekent dat als mDNS een definitief "nee" geeft, het zoeken daar stopt in plaats van door te vallen.

Deze ene regel verklaart een hele categorie verwarring. Een naam in /etc/hosts wordt opgezocht voor je browser en je scripts terwijl DNS er niets van weet. Een .local-naam bereikt DNS misschien nooit. En een DNS-gereedschap op de opdrachtregel vraagt het rechtstreeks aan een naamserver en slaat deze lijst volledig over, dus het kan het eerlijk oneens zijn met elke toepassing op de machine.

De regel die daaruit volgt is eenvoudig. Wil je vragen "wat zegt DNS", gebruik dan een DNS-gereedschap. Wil je vragen "wat doet deze machine werkelijk", gebruik dan getent, dat de lijst hierboven afloopt precies zoals een toepassing dat zou doen:

$ getent hosts petermartin.nl

Het bijbehorende artikel over het dig-commando behandelt deze grens uitgebreider, inclusief waarom een naam overal kan werken en toch lijkt niet te bestaan.

7.3 Containers hebben hun eigen DNS, en het hangt van het netwerk af

Een container erft de resolverinstellingen van je machine niet, en het verschil bijt precies tijdens de sessie waarin je een verrassing het minst kunt gebruiken. Wat hij krijgt hangt af van welk Docker-netwerk hij is binnengegaan, en de twee gevallen gedragen zich volstrekt verschillend.

Op de standaard bridge krijgt de container de bovenliggende server van de host en verder niets:

$ docker run --rm alpine cat /etc/resolv.conf
nameserver 192.168.1.1
search .

$ docker run -d --name db2 alpine sleep 60
$ docker run --rm alpine getent hosts db2
                              # nothing: names do not resolve here

Op een zelfgemaakt netwerk zet Docker zijn eigen ingebouwde resolver ertussen en gaan containernamen werken:

$ docker network create dnstest
$ docker run --rm --network dnstest alpine cat /etc/resolv.conf
nameserver 127.0.0.11
search .
options edns0 trust-ad ndots:0

$ docker run -d --network dnstest --name db alpine sleep 60
$ docker run --rm --network dnstest alpine getent hosts db
172.19.0.2        db  db

Dat adres, 127.0.0.11, is de ingebouwde DNS-server van Docker, en die zoekt de ene containernaam naar de andere op. Dit is waarom servicenamen in een Docker Compose-stack werken zonder dat iemand DNS ingesteld heeft: Compose maakt automatisch een eigen netwerk voor het project aan.

Twee praktische gevolgen. Ten eerste: kan een applicatie in een container zijn database niet bereiken, test het opzoeken dan binnen de container en niet op de host, want ze antwoorden vanaf verschillende resolvers. Ten tweede: onderzoek je een stack waar namen niet opgezocht worden, controleer dan op welk netwerk de containers werkelijk zitten voordat je naar iets anders kijkt.

$ docker exec -it mycontainer cat /etc/resolv.conf
$ docker exec -it mycontainer getent hosts database

Hetzelfde idee schaalt op. Kubernetes draait een cluster-DNS-dienst, meestal CoreDNS, en geeft elke service een naam als database.default.svc.cluster.local zodat applicaties elkaar kunnen vinden zonder vaste adressen. DNS is al een tijd niet meer alleen een internetgids; binnen moderne platformen is het de laag waarmee diensten elkaar vinden.

7.4 Word geen open resolver

Je kunt je eigen recursieve resolver op Linux draaien, en daar zijn goede redenen voor: lokale caching, je eigen DNSSEC-validatie, onafhankelijkheid van een derde partij, en logs die je zelf beheert. unbound is de gebruikelijke keuze, en BIND kan het ook.

Er is een manier om dit ernstig fout te doen, en die is het waard om ronduit te benoemen. Een recursieve resolver die iedereen op het internet antwoordt is een open resolver, en die wordt binnen dagen gevonden en misbruikt.

Het misbruik heet amplificatie. DNS loopt traditioneel over UDP, dat niet controleert wie een pakket verstuurd heeft, dus stuurt een aanvaller kleine vragen met het adres van het slachtoffer als vervalste afzender. Jouw server stuurt keurig veel grotere antwoorden naar dat slachtoffer. Een bescheiden verzoek wordt een stortvloed, de aanvaller kost het vrijwel niets, en het verkeer komt van jouw adres in plaats van het zijne.

Het voorkomen is niet ingewikkeld:

• Beperk recursie tot clients die je vertrouwt, oftewel je eigen netwerken. Deze ene instelling haalt het hele probleem weg.
• Houd de twee rollen gescheiden. Een server die je zones aan de wereld publiceert is autoritatief en heeft helemaal geen recursie nodig. Een server die voor je medewerkers opzoekt is recursief en hoort van buitenaf niet bereikbaar te zijn. Ze op een publiek adres combineren is meestal hoe dit per ongeluk gebeurt.
• Zet response rate limiting aan op alles wat wel aan het internet hangt.

Het algemene principe is het meenemen waard voorbij DNS: weet voordat je een DNS-server blootstelt of hij autoritatief bedoeld is, recursief, of allebei, want de juiste instelling verschilt per geval en de verkeerde afloop is dat iemand anders jouw bandbreedte gebruikt om een vreemde aan te vallen.

9. Best practices

• Ken je drie leveranciers voordat je ze nodig hebt. Schrijf op wie de registrar, de DNS-host en de webhost zijn, en wie voor elk de inloggegevens heeft. Midden in een storing is het verkeerde moment om te ontdekken dat het domein op het persoonlijke account van een oud-collega staat.
• Bescherm eerst de registratie. Registrar lock aan, automatisch verlengen aan, een betaalmethode die medewerkers overleeft, en een rolafhankelijk adres als contact van de houder. Al het andere in DNS gaat ervan uit dat het domein nog bestaat.
• Bewaak de verloopdatum ergens anders dan via de e-mail van de registrar. Kloppen de accountgegevens niet, dan gaan die herinneringen ook naar de verkeerde plek.
• Stel TTL's bewust in, en verlaag ze een dag voor een geplande verhuizing. 300 voor adressen, een dag voor NS, een uur voor mail- en tekstrecords.
• Houd de apex op een uitgevlakte ALIAS of een gewoon A-record, nooit een CNAME, en kies of www of het kale domein als canoniek in plaats van ze als gelijken te bedienen.
• Zet de subdomeinen neer die je hebt in plaats van naar een wildcard te grijpen. Een wildcard antwoordt voor namen die je nooit aangemaakt hebt, inclusief de namen die iemand anders verzint.
• Rol mailauthenticatie in volgorde uit. Eerst SPF en DKIM, dan DMARC op p=none, lees de rapportages een paar weken, en scherp pas daarna aan. Meteen naar p=reject gaan vernietigt stilletjes de mail die je vergeten was.
• Publiceer een CAA-record met de autoriteit die je werkelijk gebruikt. Het is twee minuten werk en het beperkt wat een ten onrechte uitgegeven certificaat kan doen.
• Zet DNSSEC aan als je provider de hele levenscyclus beheert, inclusief het wisselen van sleutels en het DS-record naar de registrar duwen. Zou het een handmatige klus zijn die je een keer doet en nooit meer bekijkt, denk er dan langer over na.
• Kies liever een goede anycast-provider dan twee middelmatige. Voeg secundaire DNS toe wanneer een uur onbereikbaar zijn echt duur is, niet omdat het professioneler klinkt.
• Gebruik round robin niet als uitwijk. DNS weet niet of een server leeft. Gebruik records met gezondheidscontrole of een load balancer.
• Ruim de zone een keer per jaar op. Verwijder de verificatie-TXT-records van diensten die je niet meer gebruikt en de A-records van servers die niet meer bestaan. Oude records zijn hoe subdomain takeovers beginnen.
• Pas /etc/resolv.conf niet aan. Op de meeste systemen is het een gegenereerde symlink. Wijzig de instelling waar hij gemaakt wordt, en gebruik resolvectl status om te zien wat je machine werkelijk gebruikt.
• Test container-DNS binnen de container. Een container antwoordt vanaf een andere resolver dan de host, en containernamen worden alleen op een zelfgemaakt netwerk opgezocht, niet op de standaard bridge.
• Stel nooit een recursieve resolver aan het internet bloot. Beperk recursie tot je eigen netwerken, en houd autoritatieve en recursieve rollen op aparte servers. Een open resolver wordt het aanvalsgereedschap van iemand anders.
• Controleer wijzigingen van buiten je eigen netwerk. Je resolver, je router en je browser cachen alle drie, en alle drie kunnen je iets laten zien wat de rest van de wereld niet ziet.

11. Samenvatting

DNS ziet eruit als een opzoektabel en gedraagt zich als een organogram. Vrijwel alles wat mensen eraan verwart komt uit dat gat.

• DNS is een gedistribueerde database met gedelegeerd gezag. De root delegeert aan registers, registers delegeren aan jouw naamservers, en elk niveau weet alleen wie het vervolgens moet vragen.
• Er zijn vier soorten software bij betrokken en ze zijn niet uitwisselbaar: de stub-resolver op je machine, de recursieve resolver die het uitzoekwerk doet en cachet, de autoritatieve server die de waarheid bevat, en het register dat de delegatie publiceert.
• Een domein is drie afspraken met drie bedrijven: de registrar waar je het huurt, de DNS-host die vragen beantwoordt, en de webhost die de site draait. Weten waar je moet inloggen is het grootste deel van het werk.
• Naamservers wijzig je bij de registrar. Records wijzig je bij de DNS-host. Die twee door elkaar halen kost een dag.
• DNS verving in 1983 een enkel HOSTS.TXT-bestand, en de specificatie waar alles nog steeds op draait is RFC 1034 en RFC 1035 uit 1987. Elke toevoeging sindsdien ging over bewijzen dat antwoorden echt zijn of over vragen privé houden.
• De apex kan geen CNAME dragen. Gebruik ALIAS of flattening als je provider het aanbiedt, of een gewoon A-record als dat niet zo is.
• Kies www of het kale domein als canoniek en verwijs de ander door. Ze als gelijken bedienen levert werk op in elke laag boven DNS.
• Wildcards antwoorden voor namen die je nooit aangemaakt hebt. Zet neer wat je hebt.
• Mailauthenticatie is een systeem: MX om te ontvangen, SPF voor toegestane servers, DKIM voor ondertekende berichten, DMARC voor de beslissing, en PTR bij je hostingprovider. Rol ze in die volgorde uit en begin DMARC op p=none.
• DNS is ook waar het internet eigendomsbewijzen bewaart: ACME-DNS-01-challenges, verificatierecords van diensten, en CAA om te benoemen welke autoriteiten voor je mogen uitgeven.
• DNSSEC bewijst dat antwoorden echt zijn en faalt hard als het stukgaat. Zet het aan als je provider de hele levenscyclus beheert, inclusief het DS-record bij de registrar.
• De 13 rootservers zijn 13 adressen, geen 13 machines: ongeveer tweeduizend anycast-instanties, twaalf beheerders. Anycast is ook wat een goede DNS-provider je verkoopt.
• Round robin verdeelt last maar is geen uitwijk, want DNS controleert nooit of een server leeft.
• Je huurt je domein. Registrar lock, automatisch verlengen, een rolafhankelijk e-mailadres, en bewaking van de verloopdatum die niet van de herinneringen van de registrar afhangt.
• Op een Linux-machine wordt /etc/resolv.conf gegenereerd en bepaalt /etc/nsswitch.conf de echte volgorde: files voor dns, dus getent en een DNS-gereedschap kunnen het eerlijk oneens zijn.
• Containers zoeken op via hun eigen server. Op een zelfgemaakt Docker-netwerk is dat 127.0.0.11 en werken containernamen; op de standaard bridge niet.
• Een recursieve resolver die open staat naar het internet wordt misbruikt voor amplificatie. Beperk recursie, en houd autoritatieve en recursieve rollen gescheiden.
• Voor records lezen, een delegatie natrekken, een cache met de bron vergelijken en TTL-waarden kiezen behandelt het bijbehorende artikel over het dig-commando het gereedschap.

Dit is de checklist die het bewaren waard is als je een domein overneemt dat je niet zelf opgezet hebt:

WHO HOLDS IT
  registrar        who it is renewed with, and who has that login
  DNS host         which name servers the registrar publishes
  web host         who owns the IP the A record points at

IS IT SAFE
  registrar lock   on
  auto-renew       on, with a payment method nobody personally owns
  registrant email a role address, not an individual
  expiry alert     somewhere other than the registrar's own email

IS IT SANE
  apex             A or ALIAS, never CNAME
  www              canonical one way, redirected the other
  wildcards        none, unless you genuinely serve unlimited names
  stale records    A records for dead servers, TXT for dead services

ON THIS MACHINE
  resolvectl status      which upstream servers are really in use
  /etc/nsswitch.conf     the order: files, mdns, dns
  getent hosts NAME      what an application sees, not what DNS says

IS IT TRUSTED
  SPF, DKIM        published and passing
  DMARC            at least p=none, with reports going somewhere read
  CAA              names the authority you actually use
  DNSSEC           signed AND the DS record published at the registrar

Een domein dat overal hetzelfde wordt opgezocht, zijn mail bezorgt, zijn certificaten vernieuwt en zijn eigen verlengingsdatum overleeft is geen geluk: het is een handvol beslissingen die bewust genomen en opgeschreven zijn. De meeste kosten op dat moment niets en zijn duur om achteraf alsnog te doen.

Heb je een domein geerfd dat niemand gedocumenteerd heeft, of verhuis je er een tussen providers en wil je de delegatie, de zone en de mailrecords laten controleren voor de omschakeling in plaats van tijdens, dan is dat een uur aandacht van iemand waard voordat het een storing wordt.