DNS-poortgids: naamresolutie op poort 53

Wanneer een client een domein moet bereiken, vraagt hij een oplosser om records zoals A, AAAA, CNAME, MX, TXT, NS of SRV. De oplosser kan antwoorden vanuit de cache of de DNS-hiërarchie door root-, TLD- en gezaghebbende servers leiden totdat hij de record vindt.

De meeste clientquery's gebruiken UDP-poort 53 omdat het verzoek en het antwoord klein zijn. DNS kan overschakelen naar TCP als de reacties te groot zijn, als er sprake is van afkapping, als DNSSEC de reactiegrootte vergroot, of als servers zoneoverdrachten en andere bewerkingen uitvoeren waarvoor een betrouwbare stream nodig is.

UDP 53 is het gebruikelijke pad voor dagelijkse DNS-resolutie. Als u dit blokkeert, worden normale zoekopdrachten meestal verbroken. TCP 53 is niet optioneel voor een volledige DNS-implementatie: het ondersteunt grote antwoorden, terugval van ingekorte UDP-reacties, DNSSEC-zware reacties en zoneoverdrachten tussen geautoriseerde servers.

Een firewallregel die UDP 53 toestaat maar TCP 53 blokkeert, kan periodieke fouten veroorzaken die moeilijk te diagnosticeren zijn. Kleine records kunnen werken, terwijl grotere DNSSEC-, TXT- of mailgerelateerde reacties mislukken.

Een gezaghebbende DNS-server publiceert records voor domeinen die u beheert. Het moet via internet bereikbaar zijn wanneer het openbare zones bedient, maar het mag alleen gezaghebbend antwoorden voor die zones en mag geen open recursie bieden.

Een recursieve solver voert zoekopdrachten uit voor clients. Publieke recursieve solvers moeten voor die rol ontworpen en beschermd worden. Interne oplossers zouden normaal gesproken alleen antwoord moeten geven op vertrouwde netwerken, VPN-clients of specifieke applicatieomgevingen.

Open poort 53 naar internet voor gezaghebbende DNS-servers die openbare zones hosten. Zowel UDP als TCP moeten worden overwogen. Als de server alleen intern is, beperk dan de toegang tot de netwerken waarvoor naamresolutie nodig is.

Stel een recursieve oplossing niet bloot aan het hele internet, tenzij u opzettelijk een openbare oplossing gebruikt met snelheidsbeperking, misbruikmonitoring en capaciteitsplanning. Open solvers worden vaak misbruikt voor reflectie- en versterkingsaanvallen.

Voordat u poort 53 toestaat, moet u beslissen of de server gezaghebbend, recursief, doorsturend, caching of split-horizon is. Bevestig welke clients het moeten gebruiken, welke zones het bedient, of recursie is ingeschakeld en of zoneoverdrachten beperkt zijn tot geautoriseerde secundaire servers.

Een poortcontrole kan bevestigen dat poort 53 bereikbaar is, maar voor de DNS-correctheid zijn tests op protocolniveau vereist. Gebruik dig-, nslookup-, drill- of solver-logboeken om recordantwoorden, recursiebeleid, TCP-fallback, DNSSEC-gedrag en responstijden te verifiëren.

Op Windows Server kan de DNS Server-rol Active Directory-geïntegreerde zones, interne records en doorstuurregels bedienen. Beperk recursie- en zoneoverdrachten zorgvuldig, vooral als de server een openbare interface heeft.

Op Linux zijn de gebruikelijke DNS-servers BIND, Unbound, PowerDNS, Knot DNS, CoreDNS en dnsmasq. Configureer luisterinterfaces, recursiebeleid, toegestane clients, gezaghebbende zones, logboekregistratie en firewallregels voor UDP en TCP 53.

Op cloudplatforms is beheerde DNS vaak veiliger voor openbare gezaghebbende zones, omdat de provider de anycast, schaling en basis-DDoS-veerkracht afhandelt. Zelf-gehoste DNS heeft nog steeds redundante instances, monitoring en duidelijk netwerkbeleid nodig.

Begin met een externe poortcontrole op UDP of TCP 53, afhankelijk van wat u moet valideren. Voer vervolgens dig @server example.com A, dig @server example.com AAAA of nslookup uit tegen de doelresolver om echte DNS-antwoorden te bevestigen.

Test TCP expliciet met dig +tcp @server example.com TXT of een ander groot antwoord. Voor gezaghebbende servers kunt u records van buiten uw netwerk opvragen en controleren of recursie wordt geweigerd. Voor recursieve solvers kunt u zoekopdrachten uitvoeren vanuit zowel toegestane als niet-toegestane bronnetwerken.

Als poort 53 gesloten is, kan de DNS-service worden gestopt, op de verkeerde interface luisteren, worden geblokkeerd door een hostfirewall of worden beperkt door een cloudbeveiligingsgroep. Als UDP onbetrouwbaar lijkt maar TCP werkt, inspecteer dan MTU, fragmentatie, responsgrootte, EDNS-instellingen en DNSSEC-gerelateerd gedrag.

Als de poort open is maar zoekopdrachten mislukken, controleer dan zonegegevens, delegatie, lijmrecords, SOA- en NS-records, recursiebeleid, forwarders, DNSSEC-validatie, cachestatus en logbestanden. DNS-fouten zijn vaak het gevolg van beleids- of zoneconfiguratie en niet zozeer van de onbewerkte poortbereikbaarheid.

Voer niet per ongeluk een open recursieve solver uit. Beperk recursie tot vertrouwde clients, beperk zoneoverdrachten naar bekende secundaire servers, zorg dat DNS-software gepatcht blijft en controleer de querysnelheid, NXDOMAIN-pieken, SERVFAIL-pieken en ongebruikelijke bronnetwerken.

Gebruik voor openbare, gezaghebbende DNS redundante servers, DNSSEC waar nodig, voldoende TTL's voor operationele flexibiliteit en duidelijk eigenaarschap van zonewijzigingen. Voor interne DNS beschermt u records met een gesplitste horizon, omdat deze vaak infrastructuurnamen en privétopologie onthullen.