Domain Name System (DNS) è un servizio critico che traduce nomi di dominio leggibili dall'uomo in indirizzi IP, consentendo la comunicazione Internet. Il protocollo principale per le query DNS è tradizionalmente UDP (User Datagram Protocol), ma anche TCP (Transmission Control Protocol) è un'opzione supportata. RFC 5966 fornisce specifiche e chiarimenti per l'uso di TCP in DNS per integrare UDP. Questo articolo approfondisce RFC 5966, spiegando i processi di comunicazione tra client e server DNS e come il bilanciamento del carico può essere implementato per il traffico UDP e TCP.
UDP vs. TCP nella comunicazione DNS #
UDP per DNS: l'approccio predefinito #
Le query DNS vengono solitamente inviate tramite UDP sulla porta 53. UDP è un protocollo leggero e senza connessione che eccelle nell'invio di piccoli pacchetti di dati con un overhead minimo. Una tipica richiesta DNS prevede che un client invii una query a un server DNS e che il server risponda con l'indirizzo IP corrispondente.
Il motivo per cui UDP è l'impostazione predefinita per DNS è la sua efficienza:
- Bassa latenza: UDP non richiede che venga stabilita una connessione prima della trasmissione dei dati, riducendo al minimo il ritardo.
- Comunicazione senza stato: Ogni richiesta è indipendente, il che la rende veloce e semplice.
- Piccoli carichi utili: Le richieste DNS sono spesso molto piccole e UDP riesce a gestirle efficacemente senza congestione.
Tuttavia, UDP ha delle limitazioni, in particolare in termini di affidabilità. I pacchetti possono essere persi o arrivare fuori ordine. Inoltre, le risposte DNS possono superare il limite di dimensione tipico di UDP (512 byte per DNS tradizionale, esteso a 4096 byte con EDNS0), portando al troncamento.
TCP per DNS: un'alternativa affidabile #
TCP, a differenza di UDP, è un protocollo orientato alla connessione che fornisce una trasmissione dati affidabile stabilendo un handshake e garantendo la consegna dei pacchetti in sequenza. Tradizionalmente, DNS su TCP era riservato ai trasferimenti di zona tra server DNS (operazioni AXFR/IXFR) e scenari di fallback quando una risposta DNS era troppo grande per UDP.
RFC 5966 chiarisce che i server DNS devono supportare DNS su TCP per tutte le query, non solo per casi eccezionali. Le ragioni principali per usare TCP in DNS includono:
- Grandi risposte: DNSSEC (DNS Security Extensions) e altri miglioramenti hanno portato a messaggi DNS più grandi. Se una risposta supera il limite di dimensione UDP, il client passa a TCP per recuperare la risposta completa.
- L’affidabilità: TCP garantisce che tutti i pacchetti vengano ricevuti nell'ordine corretto, risolvendo i problemi di affidabilità riscontrati con UDP.
Come funziona la comunicazione DNS su UDP e TCP #
Comunicazione UDP #
- Il client invia una query DNS al server tramite UDP.
- Il server elabora la query e invia una risposta, in genere entro il limite di 512 byte.
- Se la risposta del server supera questo limite e si verifica un troncamento, il client invia nuovamente la query tramite TCP.
Comunicazione TCP #
- Il client avvia una connessione TCP con un handshake a tre vie.
- La query viene inviata e il server risponde con la risposta DNS completa.
- La connessione viene chiusa dopo la comunicazione, anche se è possibile mantenere connessioni persistenti per più query per ridurre il sovraccarico.
Bilanciamento del carico per UDP e TCP in DNS #
Il bilanciamento del carico svolge un ruolo cruciale nel garantire l'affidabilità, la disponibilità e la scalabilità dei servizi DNS, specialmente in ambienti ad alto traffico. Può distribuire le richieste DNS su più server, ottimizzare l'utilizzo delle risorse e migliorare i tempi di risposta. Per il traffico DNS, sia il bilanciamento del carico UDP che TCP sono importanti, ma i metodi differiscono leggermente.
Bilanciamento del carico del traffico DNS UDP #
Poiché UDP è senza stato, il bilanciamento del carico per UDP comporta il bilanciamento di singole richieste senza tenere traccia degli stati di connessione. Esistono diverse tecniche per il bilanciamento del carico UDP:
- DNS round-robin: Il risolutore DNS distribuisce casualmente le query su più server DNS, offrendo un modo semplice per distribuire il traffico.
- Instradamento Anycast: Con anycast, lo stesso indirizzo IP viene pubblicizzato da più server DNS in diverse posizioni. La rete indirizza la query del client al server più vicino, riducendo la latenza.
- Hashing IP: Alcuni bilanciatori di carico utilizzano l'indirizzo IP sorgente per instradare il traffico in modo coerente allo stesso server DNS. Ciò garantisce che lo stesso client venga instradato allo stesso server per un determinato periodo di tempo.
Bilanciamento del carico TCP DNS Traffico #
Poiché TCP è orientato alla connessione, il bilanciatore del carico deve tracciare lo stato di ogni connessione per garantire che tutti i pacchetti di una sessione vengano instradati allo stesso server DNS. Le tecniche per il bilanciamento del carico TCP includono:
- Persistenza della sessione: Noto anche come "sticky session", questo metodo assicura che tutti i pacchetti della stessa sessione TCP vengano instradati allo stesso server. Ciò è fondamentale per mantenere l'integrità della connessione TCP.
- Bilanciamento del carico di livello 4: I bilanciatori di carico al Livello 4 (Livello di trasporto) distribuiscono il traffico in base agli indirizzi IP e ai numeri di porta TCP/UDP, garantendo che ogni connessione o sessione venga gestita dallo stesso server.
- Bilanciamento del carico di livello 7: Al Livello 7 (Livello applicativo), il bilanciatore del carico può ispezionare autonomamente la query DNS e prendere decisioni di routing intelligenti in base al contenuto della query, ad esempio il nome di dominio richiesto.
Vantaggi dell'implementazione del bilanciamento del carico per DNS #
- Ridondanza e failover: Il bilanciamento del carico garantisce che, se un server si guasta, gli altri possano subentrare senza problemi, garantendo una risoluzione DNS continua.
- Scalabilità: All'aumentare della domanda, è possibile aggiungere server aggiuntivi dietro il bilanciatore del carico senza modificare le configurazioni lato client.
- Distribuzione geografica:Con il routing anycast, i server DNS possono essere distribuiti in diverse posizioni geografiche, consentendo ai client di raggiungere il server più vicino per una risoluzione più rapida.
Configurazione del bilanciamento del carico DNS-over-UDP e DNS-over-TCP #
Per bilanciare efficacemente il traffico DNS utilizzando Relianoid Load Balancer, puoi configurare due farm separate specificamente per DNS-over-UDP e DNS-over-TCP, entrambe sulla porta 53. La farm DNS-over-UDP gestisce le query DNS standard, che sono in genere più piccole e senza connessione, ottimizzando la velocità e un utilizzo inferiore delle risorse. Nel frattempo, la farm DNS-over-TCP è configurata per le query DNS che superano la dimensione tipica del pacchetto UDP (512 byte) o richiedono una consegna più affidabile, come i trasferimenti di zona. Segmentando queste farm in base al protocollo, assicuri una gestione efficiente di ogni tipo di traffico sulla porta 53, sfruttando la distribuzione del carico specifica del protocollo, migliorando al contempo la resilienza e riducendo i colli di bottiglia.
Per fare ciò, crea le Farm nella sezione LSLB> Fattorie con L4xNAT profilo e NAT modalità come mostrato di seguito.

Conclusione #
RFC 5966 sottolinea l'importanza di supportare TCP per le query DNS oltre alle tradizionali richieste basate su UDP. Mentre UDP rimane il protocollo principale per la sua efficienza, TCP fornisce affidabilità per grandi risposte e query DNSSEC. Affinché i servizi DNS siano scalabili e resilienti, specialmente in condizioni di traffico intenso, è essenziale implementare strategie di bilanciamento del carico per il traffico UDP e TCP. Queste tecniche di bilanciamento del carico assicurano che i servizi DNS rimangano reattivi, sicuri e in grado di gestire la crescente domanda.
Conoscendo e sfruttando entrambi i protocolli insieme a un corretto bilanciamento del carico, gli amministratori di rete possono creare infrastrutture DNS solide che soddisfano le moderne esigenze di Internet.