Linux concept: DNS-resolver

Twee mensen zoeken dezelfde naam op, op dezelfde laptop, in dezelfde minuut, en krijgen twee verschillende antwoorden. Geen van beiden heeft ongelijk en er is niets kapot. Op Linux is "een naam opzoeken" niet één ding: het is een stapel van vier lagen, elk met een eigen configuratiebestand, een eigen cache en een eigen mening, en een DNS-tool op de commandoregel slaat de meeste ervan over. Zolang je niet weet welke laag het antwoord gaf, kun je niet zeggen of het probleem bij je domein ligt, bij je netwerk, of bij één regel in een bestand dat je nog nooit hebt geopend.

Dit artikel gaat over de clientkant: de machine die voor je staat. Wat /etc/resolv.conf op een modern systeem echt is, waarom /etc/nsswitch.conf meer bepaalt dan DNS zelf, wat resolvectl je kan vertellen dat dig niet kan, hoe containers namen anders opzoeken dan hun host, en hoe je je eigen resolver draait zonder het aanvalswapen van iemand anders te worden.

Hoe een Linux-machine een naam in een adres omzet, laag voor laag.

Doel: na het lezen kun je precies zeggen welke laag een lookup beantwoordde, en pas je de instelling aan op de plek waar die echt gegenereerd wordt.

2. Waar komen de namen vandaan?

Drie bestandsnamen dragen het grootste deel van dit onderwerp, en elk ervan is een afkorting waarvan de uitgeschreven vorm verklaart waar het bestand voor dient.

Het woord stub is het ook waard om vast te pinnen, want het duikt op in elk diagnosebericht op een modern systeem. Een stub-resolver is een client die bijna niets weet: hij vraagt het aan één server en gelooft het antwoord. Hij volgt geen verwijzingen vanaf de root, hij weet niet wat een autoritatieve server is, en hij kan zelf niets oplossen. Dat werk hoort bij een recursieve resolver, en dat is wat je provider of 1.1.1.1 draait.

Het verwarrende op Linux is dat systemd-resolved zichzelf een "stub listener" noemt en op 127.0.0.53 draait. Vanuit je applicaties gezien is het een stub, vanuit het netwerk gezien een client, en hij lost niets op vanaf de root. Het is een doorstuurserver met een cache.

En resolvectl is simpelweg resolve control, volgens hetzelfde patroon als systemctl, journalctl en hostnamectl: een besturingsprogramma voor één systemd-dienst.

4. Eenvoudige toepassingen

Vijf commando's beantwoorden bijna elke dagelijkse vraag. Leer deze eerst, want meestal staat het antwoord in één ervan en hoef je helemaal niets aan te passen.

4.1 Wat gebruikt deze machine eigenlijk?

De voor de hand liggende eerste stap is /etc/resolv.conf lezen. Doe dat, maar lees wat er staat:

$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
...
nameserver 127.0.0.53
options edns0 trust-ad
search localdomain

Die 127.0.0.53 is geen DNS-server op het internet. Het is de lokale stub, en de echte servers zitten erachter. Het bestand vertelt je, in een commentaarregel, dat het je vraag niet kan beantwoorden. Het commando dat dat wel kan, is resolvectl status:

$ resolvectl status
Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
Fallback DNS Servers: 9.9.9.9

Link 3 (wlp0s20f3)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1
        DNS Domain: localdomain

Link 6 (docker0)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Lees die uitvoer als een tabel per interface, want dat is het. De wifi-interface heeft een DNS-server; docker0 heeft er geen. De minnetjes zijn functies die uitstaan: geen DNS over TLS, geen DNSSEC-validatie, geen multicast DNS. resolv.conf mode: stub bevestigt dat het bestand dat je net las de gegenereerde stub-versie is en niet een statisch bestand dat jij geschreven hebt.

Alleen de servers, zonder de rest:

$ resolvectl dns
Global:
Link 3 (wlp0s20f3): 192.168.1.1
Link 6 (docker0):

4.2 Waar zet deze machine een naam naartoe om?

resolvectl query volgt hetzelfde pad als een applicatie, en vertelt je daarna dingen die geen enkele andere tool meldt:

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

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

De laatste drie regels zijn de reden om dit commando te gebruiken. Het meldt welke interface antwoordde, of het antwoord met DNSSEC gevalideerd is, of het versleuteld reisde, en of het uit de cache of van het netwerk kwam. Dat zijn vier vragen waar mensen normaal naar raden. Hier kwam het antwoord deels uit de cache, was het niet gevalideerd, en reisde het onversleuteld: de gewone toestand van een laptop die met een thuisrouter praat.

4.3 getent hosts tegenover getent ahosts

getent bevraagt de NSS-databases precies zoals een applicatie dat doet. Voor namen heeft het twee vormen, en die zijn niet hetzelfde:

$ getent hosts petermartin.nl
2a01:4f8:c0c:6848::1 petermartin.nl

$ getent ahosts petermartin.nl
23.88.98.40     STREAM petermartin.nl
23.88.98.40     DGRAM
23.88.98.40     RAW
2a01:4f8:c0c:6848::1 STREAM
2a01:4f8:c0c:6848::1 DGRAM
2a01:4f8:c0c:6848::1 RAW

Let op de volgorde. hosts gaf het IPv6-adres terug; ahosts zette IPv4 vooraan. Dezelfde machine, dezelfde naam, dezelfde seconde. Paragraaf 7.1 legt uit waarom, en dat is de nuttigste verrassing in dit artikel.

De korte versie voor nu: ahosts is degene die je vertelt wat een applicatie werkelijk gaat doen. Gebruik die, en negeer hosts tenzij je specifiek het oude gedrag wilt.

4.4 Waar kwam dat antwoord vandaan?

Drie tools, drie verschillende lagen. Weten welke welke is, verandert een verwarrende bug in een diagnose van één regel:

Als die drie het oneens zijn, is die onenigheid het antwoord. Verschilt getent van dig, dan onderschept iets lokaals de naam: een regel in /etc/hosts, een mDNS-responder, of een zoekdomein. Verschilt resolvectl van dig, dan is het meestal een cache, en paragraaf 4.5 leegt die.

4.5 De cache legen

Nadat een record gewijzigd is, kan de lokale daemon het oude antwoord nog voor de rest van zijn TTL vasthouden:

$ resolvectl flush-caches

Het drukt niets af en keert meteen terug. Dat is succes. Let op wat het niet doet: het leegt alleen de cache op deze machine. Je router, de resolver van je provider en je browser hebben allemaal hun eigen cache, en geen daarvan wordt geraakt. Lost een naam na dit commando nog steeds op naar het oude adres, dan staat de verouderde kopie niet op jouw machine.

Op een systeem zonder lokale caching-daemon valt er niets te legen. Genoeg servers draaien zo, en juist het ontbreken van een cache is waarom een wijziging daar meteen zichtbaar is en op jouw laptop vijf minuten later.

6. Gevorderde toepassingen

6.1 DNS over TLS en DNSSEC-validatie aanzetten

Klassiek DNS reist onversleuteld, dus iedereen op het pad kan lezen wat je opzoekt en het antwoord veranderen. systemd-resolved kan de stap naar je bovenliggende server versleutelen en handtekeningen valideren, en op de meeste systemen staan beide uit. De uitvoer van resolvectl status in paragraaf 4.1 zegt het al: -DNSOverTLS en DNSSEC=no/unsupported.

Beide stel je in via /etc/systemd/resolved.conf. Het meegeleverde bestand staat volledig in commentaar, wat een handige referentie voor de standaardwaarden is:

$ grep -E '^#(DNS|FallbackDNS|DNSSEC|DNSOverTLS|Cache)' /etc/systemd/resolved.conf
#DNS=
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative

Om te versleutelen noem je een server die het ondersteunt en pin je de hostnaam waar het certificaat op moet matchen:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes
DNSSEC=allow-downgrade

Daarna systemctl restart systemd-resolved en met resolvectl status bevestigen dat de minnetjes plusjes zijn geworden.

Twee waarschuwingen die je serieus moet nemen. DNSOverTLS=yes is streng: ondersteunt de server het niet, dan mislukt de resolutie in plaats van terug te vallen. Dat is het juiste gedrag en ook een prima manier om alle naamresolutie kwijt te raken op wifi met een inlogportaal. En DNSSEC=yes maakt een kapotte handtekening ergens in een keten fataal, ook bij domeinen waarvan de eigenaar een fout heeft gemaakt die jij niet kunt herstellen. allow-downgrade valideert waar het kan en breekt niet waar het niet kan, en dat is de instelling die de meeste mensen eigenlijk willen.

6.2 Split DNS, en waarom een VPN niet alles moet overnemen

Een VPN heeft doorgaans twee dingen nodig: interne namen moeten door de tunnel oplossen, en al het andere moet het lokale netwerk blijven gebruiken. De oude aanpak - /etc/resolv.conf herschrijven en de VPN-server vooraan zetten - stuurt elke lookup die je doet door de resolver van het bedrijf, inclusief je privé-browsen, en breekt wat het lokale netwerk aan het oplossen was.

Routeringsdomeinen zijn het juiste mechanisme. Een domein met een ~ ervoor wordt niet achter korte namen geplakt; het routeert alleen vragen voor dat achtervoegsel naar die interface:

# route alleen corp.example.com via de VPN-interface
$ sudo resolvectl domain tun0 '~corp.example.com'
$ sudo resolvectl dns tun0 10.0.0.53

$ resolvectl domain
Link 3 (wlp0s20f3): localdomain
Link 8 (tun0): ~corp.example.com

Nu gaat db.corp.example.com naar 10.0.0.53 en al het andere naar de server van de wifi. Om elke vraag aan een interface te geven is het routeringsdomein ~., een tilde en een punt: de root, oftewel "alles". Zie je ~. op een VPN-interface, dan weet je dat die al je DNS heeft opgeëist. Soms is dat de bedoeling, en het is hoe dan ook goed om te weten.

resolvectl revert tun0 maakt instellingen per interface die zo gezet zijn weer ongedaan.

6.3 Containers lossen namen anders op dan hun host

Een container erft de resolver-instellingen van je machine niet, en het verschil bijt precies tijdens de debugsessie waarin je een verrassing het minst kunt gebruiken. Wat hij krijgt, hangt af van het Docker-netwerk waar hij op zit, en de twee gevallen gedragen zich totaal 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
# Generated by Docker Engine.
...
nameserver 192.168.1.1

$ docker run -d --name dnsdb2 alpine sleep 60
$ docker run --rm alpine getent hosts dnsdb2
$ echo $?
2                             # niets: containernamen lossen hier niet op

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
# Generated by Docker Engine.
...
nameserver 127.0.0.11

$ docker run -d --network dnstest --name dnsdb alpine sleep 60
$ docker run --rm --network dnstest alpine getent hosts dnsdb
172.18.0.2        dnsdb  dnsdb

Dat adres, 127.0.0.11, is de ingebouwde DNS-server van Docker, en die lost de ene containernaam naar de andere op. Daarom werken servicenamen in een Docker Compose-stack zonder dat iemand DNS instelt: Compose maakt automatisch een zelfgemaakt netwerk voor het project.

Merk ook op dat de host 127.0.0.53 gebruikte en de container op de standaard bridge 192.168.1.1 kreeg. Docker geeft bewust geen loopback-adres door aan een container, want binnen de netwerknaamruimte van de container zou dat naar de container zelf wijzen.

Twee praktische gevolgen. Ten eerste: kan een applicatie in een container zijn database niet bereiken, test de resolutie dan in de container, niet op de host, want ze krijgen antwoord van verschillende resolvers. Ten tweede: lossen namen in een stack niet op, kijk dan eerst op welk netwerk de containers 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. Binnen moderne platformen is DNS de laag voor service-discovery in plaats van een internetgids.

6.4 Je eigen resolver draaien, zonder een open resolver te worden

Er zijn goede redenen om een echte recursieve resolver op Linux te draaien: caching voor een heel kantoor, je eigen DNSSEC-validatie, onafhankelijkheid van een derde partij, en logs die je zelf beheert. unbound is de gebruikelijke keuze; BIND kan het ook, en dnsmasq is een lichtere doorstuurserver-met-cache die veel thuisrouters al draaien.

Er is één manier om dit ernstig verkeerd te doen, en die is het waard om ronduit te benoemen. Een recursieve resolver die iedereen op het internet antwoord geeft, is een open resolver, en die wordt binnen enkele dagen gevonden en misbruikt.

Het misbruik heet amplificatie. DNS draait van oudsher over UDP, dat niet controleert wie een pakket verstuurde. Een aanvaller stuurt dus kleine vragen met het adres van het slachtoffer als vervalste afzender. Jouw server stuurt gehoorzaam veel grotere antwoorden naar het slachtoffer. Een bescheiden verzoek wordt een stortvloed, de aanvaller betaalt bijna 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, dus 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 oplost is recursief en hoort van buiten niet bereikbaar te zijn. Ze combineren op één publiek adres is hoe dit meestal per ongeluk gebeurt.
• Zet response rate limiting aan op alles wat wel aan het internet hangt.
• Bind aan de juiste interface. Een resolver die op 0.0.0.0 luistert op een machine met een publiek adres staat open, ook al dacht je dat hij intern was.

Het algemene principe reikt verder dan DNS: weet voordat je een server blootstelt welke rol hij hoort te spelen, want de juiste configuratie verschilt per rol en de faalmodus hier is dat iemand anders jouw bandbreedte gebruikt om een vreemde aan te vallen.

6.5 Bewust een laag overslaan

Verdenk je één laag, haal die dan uit beeld in plaats van erover te redeneren. Elk van deze commando's slaat iets specifieks over:

$ resolvectl query --cache=no petermartin.nl    # sla de lokale cache over
$ resolvectl query --protocol=dns NAAM          # sla mDNS en LLMNR over
$ dig @192.168.1.1 petermartin.nl               # sla de lokale daemon helemaal over
$ dig @1.1.1.1 petermartin.nl                   # sla ook de server van het netwerk over
$ getent ahosts NAAM                            # inclusief elke laag, als een applicatie

Werk die lijst af, en het eerste commando waarvan het antwoord verandert vertelt je welke laag verantwoordelijk was. Dat gaat sneller dan configuratiebestanden lezen, en het werkt op een machine waarvan je de configuratie nog nooit gezien hebt.

8. Best practices

• Pas nooit /etc/resolv.conf aan. Op de meeste systemen is het een gegenereerde symlink. Pas de instelling aan waar die geproduceerd wordt: het NetworkManager-verbindingsprofiel, /etc/systemd/resolved.conf, of de DHCP-server die hem uitdeelde.
• Gebruik resolvectl status om de echte servers te vinden. De nameserver-regel in resolv.conf is bijna altijd 127.0.0.53, en die zegt niets over het netwerk.
• Gebruik liever getent ahosts dan getent hosts. Het roept getaddrinfo() aan en geeft adressen in de volgorde waarin applicaties ze echt gaan proberen.
• Gebruik het juiste tool voor de vraag. getent voor "wat doet deze machine", resolvectl query voor "wat heeft de lokale resolver en waarvandaan", dig voor "wat zegt DNS zelf". Zijn ze het oneens, dan is die onenigheid de diagnose.
• Controleer eerst /etc/hosts als één machine afwijkt van alle andere. Het kost vijf seconden en het is vaker het antwoord dan wat dan ook.
• Verwijder regels uit het hosts-bestand als de migratie klaar is. Een override die naar een uitgezette server wijst geeft een storing die niemand kan verklaren, want er is niets mis met het domein.
• Test container-DNS in de container. Een container krijgt antwoord van een andere resolver dan zijn host, en containernamen lossen alleen op een zelfgemaakt netwerk op, niet op de standaard bridge.
• Gebruik routeringsdomeinen voor een VPN, geen globale override. ~corp.example.com op de tunnelinterface routeert alleen wat daar hoort. Een interface met ~. heeft elke lookup die je doet overgenomen.
• Kies liever DNSSEC=allow-downgrade dan DNSSEC=yes, tenzij je erop voorbereid bent dat de kapotte handtekening van een vreemde jouw resolutie breekt.
• Test DNSOverTLS=yes voordat je erop vertrouwt. Het valt niet terug, wat correct is en je ook afsluit op een netwerk met een inlogportaal.
• Stel nooit een recursieve resolver bloot aan het internet. Beperk recursie tot je eigen netwerken, houd autoritatieve en recursieve rollen op aparte servers, en controleer waar je resolver aan gebonden is in plaats van het aan te nemen.
• Onthoud dat het legen van de lokale cache alleen de lokale cache leegt. Je router, je provider en je browser houden hun eigen kopie, en geen daarvan wordt geraakt.
• Lees de documentatie op de machine zelf. man resolved.conf noemt elke instelling met de standaardwaarde, man nsswitch.conf legt de actiesyntaxis tussen haakjes uit, man gai.conf behandelt de adresvolgorde, en resolvectl --help toont twintig subcommando's die de meeste mensen nooit ontdekken.

10. Samenvatting

Op Linux is een naam opzoeken een stapel, geen lookup. Bijna alles wat eraan verwarrend is, komt doordat je de ene laag een vraag stelt die een andere laag beantwoordde.

• Vier lagen zitten tussen een applicatie en het netwerk: de applicatie zelf, NSS (/etc/nsswitch.conf), de stub-resolver (/etc/resolv.conf) en een lokale caching-daemon zoals systemd-resolved.
• DNS wordt bijna als laatste geraadpleegd, niet als eerste. files staat vóór dns in nsswitch.conf, dus /etc/hosts wint voor elke applicatie op de machine.
• /etc/resolv.conf is een gegenereerde symlink met 127.0.0.53 erin, de lokale stub. Het kan je niet vertellen welke servers de machine echt gebruikt; resolvectl status wel, per interface.
• Drie tools vragen het aan drie verschillende lagen. getent ahosts gedraagt zich als een applicatie, resolvectl query vraagt het aan de lokale daemon en meldt waar het antwoord vandaan kwam, en dig vraagt het rechtstreeks aan een naamserver. Hun onenigheid is de diagnose.
• getent hosts roept gethostbyname2() aan; getent ahosts roept getaddrinfo() aan. Alleen de tweede geeft adressen in de volgorde waarin software ze echt gaat proberen.
• /etc/gai.conf bepaalt de voorkeur voor IPv4 of IPv6 voor elk programma op de machine. Het wordt volledig in commentaar meegeleverd, en één regel uit commentaar halen lost het probleem van de trage eerste verbinding door kapot IPv6 op.
• DNS per interface is de hele reden voor de daemon. Een routeringsdomein geschreven als ~corp.example.com routeert alleen dat achtervoegsel via een interface; ~. routeert alles, en dat is meestal wat een VPN die "DNS brak" gedaan heeft.
• Containers lossen anders op. De standaard bridge geeft de bovenliggende server van de host en geen containernamen; een zelfgemaakt netwerk geeft Docker's eigen resolver op 127.0.0.11, en namen werken.
• systemd-resolved cachet alleen positieve antwoorden (Cache=no-negative), en de cache is alleen als root te lezen.
• Een recursieve resolver aan het internet is een open resolver en wordt binnen enkele dagen een amplificatiewapen. Beperk recursie, en houd autoritatieve en recursieve rollen gescheiden.
• Een browser met DNS over HTTPS negeert dit allemaal, en daarom kan hij het oneens zijn met elk commandoregeltool op dezelfde machine.

De commando's om binnen handbereik te houden:

WAT GEBRUIKT DEZE MACHINE
  resolvectl status              servers per interface, DNSSEC- en DoT-status
  resolvectl dns                 alleen de servers
  resolvectl domain              zoekdomeinen, en ~routeringsdomeinen
  nmcli dev show | grep DNS      wat NetworkManager doorgaf
  grep '^hosts:' /etc/nsswitch.conf    de volgorde die alles bepaalt

WAAR LOST EEN NAAM NAARTOE OP
  getent ahosts NAAM             als een applicatie, met de juiste volgorde
  resolvectl query NAAM          + welke interface, cache of niet, gevalideerd of niet
  dig NAAM                       DNS zelf, met voorbijgaan aan elke lokale laag
  dig +search NAAM               met de zoeklijst, als een applicatie

INPERKEN
  resolvectl query --cache=no NAAM     sla de lokale cache over
  dig @192.168.1.1 NAAM                sla de lokale daemon over
  dig @1.1.1.1 NAAM                    sla het lokale netwerk over
  sudo resolvectl monitor              zie vragen langskomen

AANPASSEN, WAAR HET GEGENEREERD WORDT
  nmcli connection modify ...          per netwerkprofiel
  /etc/systemd/resolved.conf           DNS=, DNSSEC=, DNSOverTLS=, Cache=
  /etc/hosts                           overrule een naam voor alles
  resolvectl dns LINK SERVER           tijdelijk; resolvectl revert LINK

DOCUMENTATIE
  man resolved.conf   man nsswitch.conf   man gai.conf   resolvectl --help

En lost een naam op elke machine goed op behalve op één, dan ligt de oorzaak vrijwel nooit bij het domein. Het is een regel die iemand aan /etc/hosts toevoegde tijdens een migratie die allang klaar is.