Welke poort gebruikt DNS? Poort 53, en wanneer niet

Welke poort gebruikt DNS voor een gewone opzoeking?

Een normale query, het soort dat uw browser tientallen keren per minuut verstuurt, gaat als één UDP-pakket naar poort 53 en komt op dezelfde manier terug. RFC 1035 noemt UDP "de aanbevolen methode voor standaardqueries op het internet" omdat het geen handshake nodig heeft: één pakket erop uit, één pakket terug, klaar. Dat is ook waarom DNS instantaan aanvoelt als het werkt en waarom een enkel verloren pakket al genoeg is om het kapot te laten voelen, aangezien UDP niet automatisch opnieuw probeert. De resolversoftware op uw apparaat of router regelt de nieuwe poging, meestal tegen een tweede geconfigureerde server als de eerste stil blijft.

Wanneer gebruikt DNS in plaats daarvan TCP?

Twee situaties duwen een DNS-uitwisseling naar TCP-poort 53. De eerste is een zonetransfer, waarbij een secundaire nameserver een volledige kopie van een zone ophaalt bij de primaire. RFC 1035 is expliciet dat "UDP niet acceptabel is voor zonetransfers" omdat de operatie een betrouwbare, geordende stroom nodig heeft, geen enkel best-effort-pakket. De tweede is een antwoord dat niet past binnen de gebruikte UDP-berichtgrootte. Als dat gebeurt, stuurt de server een afgekapt UDP-pakket terug met de TC-bit (truncated) gezet, en een compliant resolver merkt de bit op en stuurt dezelfde query opnieuw via TCP om het volledige antwoord te krijgen. U kunt dat gedrag zelf afdwingen en het volledige antwoord rechtstreeks zien:

dig +tcp example.com

Alledaagse queries hebben dit pad zelden nodig, maar het bestaat juist zodat DNS blijft werken wanneer een antwoord groeit voorbij wat één UDP-pakket aankan, wat vaker gebeurt dan vroeger.

Wat was de limiet van 512 bytes, en wat heeft dat veranderd?

RFC 1035 legde de UDP-berichtgrootte vast op 512 bytes, header inbegrepen, zonder de IP- of UDP-headers zelf mee te tellen. Dat getal was ruim in 1987, toen een DNS-antwoord een handvol adresrecords was. Het hield op ruim te zijn zodra DNSSEC-handtekeningen, langere hostnamen en records met veel IP-adressen normaal werden, omdat een ondertekend antwoord met een RRSIG-record routinematig alleen al de 512 bytes overschrijdt.

RFC 6891, gepubliceerd in 2013, verhielp dat plafond zonder het draadprotocol aan te raken: EDNS0 voegt een OPT-pseudorecord toe waarmee een resolver "de grootste UDP-payload die opnieuw kan worden samengesteld en afgeleverd in de netwerkstack van de aanvrager" kan aankondigen, en de RFC stelt 4096 bytes voor als praktisch uitgangspunt. Een resolver en server die allebei EDNS0 ondersteunen, kunnen antwoorden uitwisselen die meerdere keren groter zijn dan het oude plafond van 512 bytes in één UDP-pakket, en vallen pas terug op TCP wanneer zelfs die grotere marge niet volstaat. Vrijwel elke resolver die vandaag in gebruik is, inclusief die van uw eigen besturingssysteem, spreekt standaard EDNS0, dus deze upgrade is al gebeurd zonder enige actie van uw kant.

Waarom firewalls die alleen UDP 53 toestaan echte problemen veroorzaken

Een firewallregel die jaren geleden is geschreven en nooit herzien, zegt vaak "sta UDP-poort 53 toe, weiger al het andere dat met DNS te maken heeft". Die regel blokkeert de TCP-terugval die het protocol nodig heeft, en de storing die dat veroorzaakt is makkelijk verkeerd te diagnosticeren omdat de meeste opzoekingen gewoon blijven werken. Alleen degene die groeien voorbij de UDP-limiet falen, en ze falen op een manier die willekeurig lijkt: een domein resolvet normaal het grootste deel van de tijd en loopt dan vast, vooral zodra DNSSEC-validatie meespeelt, aangezien een valideerde resolver de RRSIG- en DNSKEY-records moet ophalen naast het antwoord waar hij om vroeg.

Het praktische resultaat is dat met DNSSEC ondertekende zones en elke recordset met veel waarden (een domein met een dozijn mailservers, bijvoorbeeld) onbetrouwbaar worden achter een firewall die alleen UDP toelaat, terwijl al het andere gezond lijkt. Uitgaande TCP 53 blokkeren, of het in slechts één richting blokkeren, is een van de vaker zelf veroorzaakte DNS-storingen, en het duikt zelden op in een basale connectiviteitscheck omdat die check meestal alleen UDP probeert.

DNS over TLS en DNS over HTTPS: andere poorten, dezelfde opzoekingen

Twee nieuwere transporten vervoeren dezelfde DNS-queries en -antwoorden, maar halen dat allemaal volledig van poort 53. DNS over TLS, gedefinieerd in RFC 7858, verpakt elke query in een TLS-sessie op TCP-poort 853, gekozen zodat een netwerkbeheerder nog steeds kan zien dat DoT plaatsvindt (en het kan blokkeren) zelfs zonder te ontcijferen, aangezien de poort zelf al een duidelijk signaal is.

DNS over HTTPS, gedefinieerd in RFC 8484, gaat verder. Het stuurt DNS-queries als gewone HTTPS-verzoeken op poort 443, dezelfde poort als elke andere site die u bezoekt, en de RFC noemt "de mogelijkheid om DoH-verkeer te mengen met ander HTTPS-verkeer op dezelfde verbinding" als een bewuste eigenschap. Dat is het hele punt van DoH: een netwerk dat alleen op poort inspecteert of filtert, kan een DNS-opzoeking niet onderscheiden van elk ander HTTPS-verzoek, omdat het hetzelfde protocol is op dezelfde poort. Chrome, Firefox en Edge kunnen nu allemaal standaard DNS op deze manier versturen, en daarom garandeert het blokkeren van "poort 53" op een netwerk niet meer dat u DNS heeft geblokkeerd. Het garandeert dat u het klassieke transport heeft geblokkeerd; een browser met DoH ingeschakeld blijft namen resolven via 443, ongeacht wat u doet.

Wat is mDNS op poort 5353?

Multicast DNS is een ander protocol met een vergelijkbare naam. RFC 6762 definieert het als apparaten die "DNS-achtige UDP-query- en responsberichten sturen via IP Multicast naar UDP-poort 5353", geadresseerd aan de multicastgroep 224.0.0.251 (of het IPv6-equivalent, FF02::FB) in plaats van aan een specifieke server. Er is helemaal geen centrale nameserver bij betrokken: elk apparaat op het lokale netwerksegment luistert op poort 5353 en antwoordt voor zijn eigen naam. Zo wordt een printer of een slimme speaker bereikbaar als device.local zonder dat iemand er een DNS-record voor configureert. Het is bewust beperkt tot de lokale link en heeft niets te maken met het resolven van een publieke domeinnaam, dus mDNS-verkeer hoeft nooit uw router te verlaten.

Hoe test u of poort 53 bereikbaar is

Begin met een directe query tegen een resolver waarvan u weet dat hij werkt, wat al aangeeft of gewone UDP-opzoekingen überhaupt werken:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Als dat slaagt maar u vermoedt dat het TCP-terugvalpad geblokkeerd is, forceer dan TCP en vergelijk:

dig +tcp example.com @1.1.1.1

Een UDP-query die slaagt terwijl de geforceerde TCP-versie vastloopt, is een sterke aanwijzing dat iets tussen u en de resolver specifiek TCP 53 laat vallen, precies het storingspatroon hierboven beschreven. Testen of een poort van buiten uw eigen netwerk toegankelijk is, is waar onze poortcontrole nuttig is: richt hem op poort 53 op uw resolver of nameserver en hij opent een echte TCP-verbinding vanaf een ander netwerk, wat bevestigt of TCP 53 bereikbaar is. Lees het resultaat met één kanttekening in gedachten: een poortcontrole test TCP, dus een geslaagd resultaat daar bevestigt dat het terugvalpad open staat, maar zegt niets over UDP, dat geen handshake heeft om op dezelfde manier te testen. Voor de query zelf, inclusief het vergelijken van antwoorden van meerdere openbare resolvers en verschillende regio's tegelijk, voert u de DNS-querytool uit.

Veelgestelde vragen

Moet ik TCP 53 openzetten naast UDP 53?

Ja, voor uitgaand resolververkeer. Een firewall die alleen UDP 53 toestaat, verwerkt de meeste queries prima en faalt dan onvoorspelbaar bij grotere, doorgaans met DNSSEC ondertekende, antwoorden die de TCP-terugval nodig hebben.

Stopt het blokkeren van poort 53 alle DNS-verkeer?

Niet meer. Het blokkeert het klassieke UDP/TCP-transport. DNS over HTTPS draait op poort 443 en ziet eruit als elk ander HTTPS-verzoek, en DNS over TLS draait op zijn eigen poort 853, dus een browser of app met een van beide ingeschakeld blijft namen resolven.

Is DNS over HTTPS hetzelfde protocol als gewone DNS?

De queries en antwoorden zijn dezelfde DNS-records en codes die door RFC 1035 zijn gedefinieerd. Alleen het transport verandert: in plaats van een ruw UDP- of TCP-pakket op poort 53 wordt hetzelfde verzoek verpakt in een HTTPS-verzoek op poort 443.

Waarom gebruikt dig soms TCP zonder dat het gevraagd wordt?

Wanneer een UDP-antwoord afgekapt terugkomt, met de TC-bit gezet, stuurt een standaardcompliant client automatisch de query opnieuw via TCP om het volledige antwoord te krijgen. U ziet dit het vaakst bij domeinen met DNSSEC ingeschakeld of met veel records van hetzelfde type.

Is mDNS op poort 5353 hetzelfde als de DNS van mijn provider?

Nee. mDNS werkt alleen op uw lokale netwerksegment, heeft geen centrale server, en resolvet namen zoals device.local voor apparaten op dezelfde link. Het speelt geen enkele rol bij het resolven van een publiek domein zoals example.com.

Wat is een normale EDNS0-payloadgrootte vandaag?

RFC 6891 stelt 4096 bytes voor als praktische standaard, en de meeste huidige resolvers kondigen iets in die orde aan, ruim boven het oorspronkelijke plafond van 512 bytes, voordat ze pas op TCP terugvallen wanneer zelfs dat niet volstaat.