Surviving Tips:Performance e DNS

Tra le cose piu spesso trascurate per quello che riguarda security e prestazioni, vi e’ sempre la struttura DNS.

I DNS sono un elemento fondamentale per garantire prestazioni sia per quello che concerne il trasferimento delle mail sia per quello che concerne la navigazione Web.

Anche utilizzando un SMTP Gateway o un Proxy non si puo’ prescidere dalle performance di un buon servizio di DNS. Paradossalmente poi in caso di uso di proxy un pessimo DNS puo’ dare origine ad una serie disparata di errori che, nei fatti, renderebbero la navigazione piu problematica e la use experience piu dura rispetto alla navigazione senza proxy.

Cerchiamo di capire a cosa serve e perche’ il servizio DNS e’ cosi importante, e come questo si integra nei servizi IronPort.

Come tutti sappiamo il servizio DNS (Domani Name System) serve per tradurre un nome nel relativo indirizzo IP.

da Wikipedia:

Domain Name System (spesso indicato con DNS) è un servizio utilizzato per la risoluzione di nomi di host in indirizzi IP e viceversa. Il servizio è realizzato tramite un database distribuito, costituito dai server DNS.

Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano, i server su cui questi girano, l’insieme di questi server che cooperano per fornire il servizio.

I nomi DNS, o “nomi di dominio”, sono una delle caratteristiche più visibili diInternet.

C’è confusione in merito alla definizione dell’acronimo: la S spesso viene interpretata come service, ma la definizione corretta è system.

L’operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è detto risoluzione inversa.

la struttura dei domini e’ ad albero, si parte dalla root (.) per poi creare DNS autoritativi sulle classiche zone .com, .net, .tv, .tel etc etc etc.

Vi rimando a Wikipedia per approfondire la questione. e per riferimento potete usare i seguenti link:

• DNS Security Extensions (DNSSEC)
• root-servers.org
• RFC 882
• RFC 883
• RFC 1034
• RFC 1035

 

Quando si crea un dominio si deve installare un DNS server che sia autoritativo per il proprio dominio, questa operazione viene fatta o in casa o dal providr che offre connettivita’.

Il DNS vienie quindi usato per offrire la risoluzione di nomi Host in IP, il problema e’ che tale risoluzione non e’ detto che sia veloce. tutti hanno sperimentato quanto possa durare la propagazione di un nome su internet (2448 ore) e tutti hanno sicuramente provato la lentezza derivante ad una cattiva risoluzione DNS, anche se spesso si attribuisce la lentezza di servizi e browsing a cause diverse.

Le soluzioni IronPort (ma non solo) usano pesantemente i servizi DNS in quanto questi sono essenziali per la corretta delivery dei servizi di Email e Web Browsing, inoltre il protocollo DNS viene utilizzato anche per interrogare Senderbase, lo scopo e’ quello di utilizzare un protocollo veloce, leggero, con una struttura ridondata.

Purtroppo la tendenza riguardo i DNS in italia e’ spesso quella di trascurarne l’importanza e la sicurezza, e questo si traduce nella cattiva abitudine di utilizzare il DNS come servizio secondario su macchine non sufficientemente performanti o, peggio, fare riferimento a DNS generici offerti piu o meno pubbicamente dai providers.

Questa cattiva abitudine porta spesso, come conseguenza, ad avere un calo sensibile di performance che viene, erroneamente, attribuita alle cause piu disparate.

Sebbene sia necessario consentire la risoluzione pubblica ai domini su cui si ha autorita’ questo non significa necessariamente che dobbiamo porre in DMZ il nostro DNS principale.

Esistono diverse tecnologie che ci consentono di esporre solo la porzione di zona che siamo vincolati (o ci serve) esporre, tipicamente si espone su un DNS apposito in DMZ la porzione di zona interessata, che verra’ utilizzata su internet per poter permettere la risoluzione degli host esposti.

il problema nasce dal fatto che oltre ad esporre contenuti (la risoluzione degli host dei domini di cui si ha autorita’) il servizio DNS viene utilizzato anche da sorgenti interne ed in DMZ che richiedono o possono richiedere:

1) la risoluzione di host in domini pubblici non gestiti da voi

2) la risoluzione di host in domni privati che on e’ il caso di esporre pubblicamente (si pensi, ad esempio, alle esigenze di Active Directory).

Buona norma implementativa, sia che abbiate o meno un DNS autoritativo pubblico, e’ quella di mettere in DMZ un sistema ridondato di DNS Cache Only.

A questi DNS potrebbero puntare sia le macchine in DMZ che, eventualmente, le macchine interne che cercando di fare risoluzione.

Questo semplice accorgimento consente di effettuare una ottimizzazione sensibile in termini di latenze prestazionali legate ai DNS worldwide.

Innanzi tutto un chache only e’ molto facile da gestire, un minimo di hardening e’ ovviamente consigliabile, ma la cosa interessante e’ che, se si sfruttano anche meccanismi di virtualizzazione, la messa i opera in caso di problemi di tale oggetto e’ estremamente rapida.

L’uso di un cache only in DMZ vi consente, inoltre, di abbassare il rischio di DNS poisoning, infatti risulta ovvio che tale DNS e’ meno esposto sia di un autoritativo che di un DNS di un provider.

Un altro vantaggio di un DNS in casa di tipo cache only e’ anche legato al fatto che in cache potete mettere solo quello che effettivamente vi interessa, gestendo opportunamente TTL potete quindi ottimizzare pesantemente le risposte.

Sempre in termini di vantaggi vi e’ anche un evidente guadagno in termini di velocita’ di risposta alle query dovuto alla vicinanza del DNS cache server ai vostri client. Il vantaggio si sente, ovviamente, sia in termni di performance sulla DMZ che in termini di performance sulla LAN interna.

Una delle osservazioni piu comuni cui vado incontro e’ legata alla considerazione che in ambiente AD esiste gia’ (ed e’ obbligatorio) un servizio DNS.

Active Directory, infatti, demanda alla risoluzione DNS la risoluzione dei nomi HOST e dei servizi, e quindi e’ un requisito fondamentale per la sua installazione. Ovviamente Microsoft offre un DNS integrato alla sua soluzione che serve a coprire egregiamente questa esigenza, offrendo anche, oltre alla integrazione in AD, il supporto dinamico di registrazione dei nomi e la capacita’ di rispondere a chiamate DNS standard.

Il risultato e’ che spesso ci si trova di fronte a realta’ in cui il dominio AD ha una estensione pubblica (.COM, .IT….)

Va da se che questa e’ una situazione poco gradevole in termni di security, in quanto nel caso, ad esempio, si forzi la sicurezza del DNS autoritativo si viene a conoscere l’intero indirizzamento delle macchine in AD. Non parliamo poi della sua diretta esposizione in DMZ (magari anche come global catalog….)

Una situazione piu prudente e’ quella di demandare al DNS interno di AD la gestione di un dominio non pubblico (.LOCAL, .BOH, .FATEVOI) e quindi non esporre semplicemente tale zona alla risoluzione su internet.

Nel caso le macchine interne debbano risolvere sia domini esterni che domini inetrni si pone allor ail problema di come configurare la cosa.

Dal punto di vista Ironpor il supporto dello split dns risolve il problema in maniera semplice ed efficace.

La idea di base e’ quella di puntare, per la risoluzione di un dominio pubblico generico, ad un DNS pubblico (o direttamente ai Root Server, in questo caso i Gateway Ironport si comportano come DNS chache only server, che pero’ accettano solo se stessi come client DNS), e per i domini privati a DNS opportunamente configurati per accettar query solo da un numero definito di macchine in DMZ (non aprite la porta a chiunque, MAI).

Nel caso abbiate soluzioni che non gestiscano lo split dns e’ possibile intervenire con DNS configurati in maniera ibrida (cache, forwarder….) in maniera che la risoluzione interna ed esterna sia possibile per le macchine che lo richiedano.

In realta’ l’uso del DNS cache sarebbe da consigliare sempre e comunque, persino per l’uso domestico. Provate ad installare sulle vostre macchine un DNS service (si trovano free o opensource per qualsiasi piattaforma) e vedete se ci sono differenze rispetto all’appoggiarvi al DNS del vostro provider.

ciao

Antonio