DNS (Domain Name System) is een essentiële dienst die voor mensen leesbare domeinnamen vertaalt naar IP-adressen, waardoor internetcommunicatie mogelijk wordt. Het primaire protocol voor DNS-query's is van oudsher UDP (User Datagram Protocol), maar TCP (Transmission Control Protocol) is ook een ondersteunde optie. RFC 5966 biedt specificaties en verduidelijkingen voor het gebruik van TCP in DNS als aanvulling op UDP. Dit artikel gaat dieper in op RFC 5966 en legt de communicatieprocessen tussen DNS-clients en -servers uit, evenals hoe load balancing kan worden geïmplementeerd voor zowel UDP- als TCP-verkeer.

UDP versus TCP in DNS-communicatie #

UDP voor DNS: de standaardbenadering #

DNS-query's worden meestal verzonden via UDP op poort 53. UDP is een verbindingsloos, lichtgewicht protocol dat uitblinkt in het verzenden van kleine datapakketten met minimale overhead. Een typische DNS-aanvraag bestaat uit een client die een query naar een DNS-server stuurt, waarna de server reageert met het bijbehorende IP-adres.

De reden dat UDP de standaard is voor DNS is de efficiëntie ervan:

• Lage latentie:UDP vereist niet dat er een verbinding tot stand wordt gebracht voor de gegevensoverdracht, waardoor vertraging tot een minimum wordt beperkt.
• Staatloze communicatie:Elke aanvraag is onafhankelijk, waardoor het snel en eenvoudig is.
• Kleine ladingen:DNS-verzoeken zijn vaak erg klein en UDP kan deze effectief verwerken zonder dat er congestie ontstaat.

UDP heeft echter beperkingen, met name op het gebied van betrouwbaarheid. Pakketten kunnen verloren gaan of in de verkeerde volgorde aankomen. Bovendien kunnen DNS-reacties de typische UDP-limiet overschrijden (512 bytes voor traditionele DNS, uitgebreid tot 4096 bytes met EDNS0), wat leidt tot afkapping.

TCP voor DNS: een betrouwbaar alternatief #

TCP is, in tegenstelling tot UDP, een verbindingsgericht protocol dat betrouwbare gegevensoverdracht biedt door een handshake tot stand te brengen en de levering van pakketten in de juiste volgorde te garanderen. Traditioneel was DNS over TCP gereserveerd voor zoneoverdrachten tussen DNS-servers (AXFR/IXFR-bewerkingen) en fallback-scenario's wanneer een DNS-respons te groot was voor UDP.

RFC 5966 verduidelijkt dat DNS-servers DNS over TCP moeten ondersteunen voor alle query's, niet alleen in uitzonderlijke gevallen. Belangrijke redenen voor het gebruik van TCP in DNS zijn onder andere:

• Grote reacties:DNSSEC (DNS Security Extensions) en andere verbeteringen hebben geleid tot grotere DNS-berichten. Als een antwoord de UDP-limiet overschrijdt, schakelt de client over naar TCP om het volledige antwoord op te halen.
• Betrouwbaarheid::TCP zorgt ervoor dat alle pakketten in de juiste volgorde worden ontvangen, waardoor de betrouwbaarheidsproblemen die bij UDP optreden, worden opgelost.

Hoe DNS-communicatie werkt via UDP en TCP #

UDP-communicatie #

• De client stuurt een DNS-query naar de server via UDP.
• De server verwerkt de query en stuurt een antwoord terug, meestal binnen de limiet van 512 bytes.
• Als het antwoord van de server deze limiet overschrijdt en er afkapping optreedt, verstuurt de client de query opnieuw via TCP.

TCP-communicatie #

• De client initieert een TCP-verbinding met een three-way handshake.
• De query wordt verzonden en de server reageert met het volledige DNS-antwoord.
• De verbinding wordt na de communicatie gesloten, maar om de overhead te beperken, kunnen er voor meerdere query's permanente verbindingen in stand worden gehouden.

Load Balancing voor UDP en TCP in DNS #

Load balancing speelt een cruciale rol bij het waarborgen van de betrouwbaarheid, beschikbaarheid en schaalbaarheid van DNS-services, met name in omgevingen met veel verkeer. Het kan DNS-verzoeken over meerdere servers verdelen, het resourcegebruik optimaliseren en de responstijden verbeteren. Voor DNS-verkeer zijn zowel UDP- als TCP-load balancing belangrijk, maar de methoden verschillen enigszins.

Load Balancing UDP DNS-verkeer #

Omdat UDP stateless is, houdt load balancing voor UDP in dat individuele verzoeken worden gebalanceerd zonder de verbindingsstatus bij te houden. Er zijn verschillende technieken voor UDP-load balancing:

• Round-Robin DNS:De DNS-resolver verdeelt query's willekeurig over meerdere DNS-servers, waardoor het verkeer eenvoudig kan worden verspreid.
• Anycast-routeringMet anycast wordt hetzelfde IP-adres geadverteerd door meerdere DNS-servers op verschillende locaties. Het netwerk routeert de query van de client naar de dichtstbijzijnde server, waardoor de latentie wordt verminderd.
• IP-hashing: Sommige load balancers gebruiken het bron-IP-adres om verkeer consistent naar dezelfde DNS-server te routeren. Dit zorgt ervoor dat dezelfde client gedurende een bepaalde periode naar dezelfde server wordt gerouteerd.

Load Balancing TCP DNS-verkeer #

Omdat TCP verbindingsgericht is, moet de load balancer de status van elke verbinding volgen om ervoor te zorgen dat alle pakketten van een sessie naar dezelfde DNS-server worden gerouteerd. Technieken voor TCP-load balancing zijn onder andere:

• Sessiepersistentie: Ook wel bekend als "sticky sessions", zorgt deze methode ervoor dat alle pakketten van dezelfde TCP-sessie naar dezelfde server worden gerouteerd. Dit is cruciaal voor het behoud van de integriteit van de TCP-verbinding.
• Laag 4 taakverdeling:Load balancers op laag 4 (transportlaag) verdelen het verkeer op basis van IP-adressen en TCP/UDP-poortnummers. Zo wordt ervoor gezorgd dat iedere verbinding of sessie door dezelfde server wordt afgehandeld.
• Laag 7 taakverdeling:Op laag 7 (toepassingslaag) kan de load balancer de DNS-query zelf inspecteren en intelligente routeringsbeslissingen nemen op basis van de inhoud van de query, zoals de aangevraagde domeinnaam.

Voordelen van het implementeren van load balancing voor DNS #

• Redundantie en failover:Load balancing zorgt ervoor dat als één server uitvalt, andere servers het naadloos kunnen overnemen, waardoor een continue DNS-omzetting wordt gegarandeerd.
• Schaalbaarheid:Naarmate de vraag toeneemt, kunnen er extra servers achter de load balancer worden toegevoegd zonder dat de configuratie aan de clientzijde hoeft te worden gewijzigd.
• Geografische distributieMet anycast-routing kunnen DNS-servers over verschillende geografische locaties worden verspreid, waardoor clients de dichtstbijzijnde server kunnen bereiken voor een snellere oplossing.

DNS-over-UDP en DNS-over-TCP Load Balancing-configuratie #

Om DNS-verkeer effectief te verdelen met Relianoid Load Balancer, kunt u twee afzonderlijke farms configureren, specifiek voor DNS-over-UDP en DNS-over-TCP, beide op poort 53. De DNS-over-UDP-farm verwerkt standaard DNS-query's, die doorgaans kleiner en verbindingsloos zijn, en optimaliseert zo de snelheid en het resourcegebruik. De DNS-over-TCP-farm is daarentegen ingesteld voor DNS-query's die de typische UDP-pakketgrootte (512 bytes) overschrijden of een betrouwbaardere levering vereisen, zoals zonetransfers. Door deze farms te segmenteren op basis van protocol, zorgt u voor een efficiënte verwerking van elk type verkeer op poort 53, waarbij u gebruikmaakt van protocolspecifieke loadverdeling, terwijl u tegelijkertijd de veerkracht vergroot en knelpunten vermindert.

Maak hiervoor de farms aan in het gedeelte LSLB > Farms met het L4xNAT -profiel en de NAT- modus zoals hieronder weergegeven.

Conclusie #

RFC 5966 benadrukt het belang van TCP-ondersteuning voor DNS-query's naast de traditionele UDP-gebaseerde verzoeken. Hoewel UDP het primaire protocol blijft vanwege de efficiëntie, biedt TCP betrouwbaarheid voor grote responsen en DNSSEC-query's. Om DNS-services schaalbaar en veerkrachtig te houden, met name bij intensief verkeer, is het essentieel om load balancing-strategieën te implementeren voor zowel UDP- als TCP-verkeer. Deze load balancing-technieken zorgen ervoor dat DNS-services responsief, veilig en in staat blijven om de groeiende vraag aan te kunnen.

Door beide protocollen te begrijpen en te benutten en daarnaast te zorgen voor een goede load balancing, kunnen netwerkbeheerders robuuste DNS-infrastructuren bouwen die voldoen aan de moderne internetvereisten.