Un tool per migliorare il DNS

Sviluppato da GARR un nuovo strumento per misurare lo stato di salute del DNS e garantire il perfetto funzionamento della rete

Mai più indirizzi Internet non raggiungibili e una rete più ordinata e sicura: sono questi alcuni tra i principali obiettivi con cui è nato il nuovo strumento open source realizzato da GARR e messo a disposizione di tutta la comunità dell’istruzione e della ricerca.

LSi chiama DFD, DNS Faults Diagnostic, ed aiuta a monitorare lo stato di salute del DNS sulla rete GARR permettendo di conoscere in anticipo eventuali malfunzionamenti e configurazioni errate. Il tool è stato sviluppato e realizzato da GARR nell’ambito dei servizi LIR e NIC che si occupano dell’assegnazione degli indirizzi IPv4/IPv6 e della registrazione dei nomi a dominio .it e .eu. Il suo ideatore, Marco Gallo, ci guida alla scoperta di questo nuovo strumento spiegandoci in che modo può essere di grande aiuto per tutti gli enti connessi alla rete GARR.

Come è nato DFD e da quali esigenze prende avvio?

Marco Gallo
Consortium GARR
Coordinatore Internet Registration Services
Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.

Il servizio nasce dalla necessità di disporre di strumenti di automazione per controllare il funzionamento della rete, analizzando protocolli essenziali come il DNS. Sempre più ci accorgiamo che i problemi sono causati da configurazioni errate o dal mancato aggiornamento dei nameserver. Quest’ultimo è proprio uno dei problemi rilevati più frequentemente. Nel corso degli anni, può verificarsi un disallineamento tra i nameserver registrati come autoritativi e quelli attivati in un secondo tempo. Se GARR-NIC non viene informato delle modifiche non può aggiornare la registrazione. Si genera così quella che viene definita “delega zoppa” (lame delegation) tra i nameserver autoritativi dei ccTLD .it o .eu e i nameserver autoritativi dei domini di secondo livello per i quali sono stati cambiati i DNS. Ma cosa accade esattamente in questo caso? Se l’utente cerca di contattare un host in uno di questi domini, il DNS ritenterà la richiesta inutilmente per molte volte senza ottenere risposta. Questa dinamica improduttiva riguarderà tutti i DNS coinvolti nel processo di risoluzione, a partire dai nameserver di root lungo la catena gerarchica del DNS.

Al fine di individuare ed eliminare questo tipo di errore, il sistema DFD esegue un confronto tra i nameserver registrati presso le Authority del .it e del .eu e quelli effettivamente propagati, mostrando poi comodamente sull’interfaccia web quale sia la discordanza.

Quindi vi accorgete di un problema prima degli utenti?

Sì, perché spesso un’organizzazione possiede più di un nameserver e quindi non nota un reale problema se non un rallentamento della risposta ad una richiesta. Intercettare in anticipo problemi e malfunzionamenti è da sempre tra le caratteristiche principali della rete GARR che fa della proattività uno dei suoi punti di forza. Per questo motivo, abbiamo deciso di sviluppare uno strumento che possa aiutarci nella gestione delle risorse che assegniamo ai nostri enti. Sono stati necessari circa 4 mesi per il suo sviluppo. Le criticità maggiori sono state soprattutto nella raccolta e sincronizzazione dei dati che provengono da più database.

A chi si rivolge e quali problemi rileva?

DFD è utilizzato all’interno di GARR per monitorare il funzionamento del DNS in modo da poter avvertire tempestivamente i referenti tecnici delle reti all’interno degli enti connessi.

DNS SECONDARIO

GARR offre un servizio di DNS secondario per gli enti che ne fanno richiesta. Per la registrazione di un dominio .it è necessario disporre di almeno due DNS (primario, secondario). Agli istituti viene garantito supporto per la configurazione del DNS sia in fase di attivazione sia per tutte le operazioni di mantenimento del servizio.

I controlli che vengono eseguiti riguardano la corretta configurazione delle deleghe su tutte le zone gestite da GARR e, come detto in precedenza, la risposta dei nameserver propagati come autoritativi delle zone di cui GARR è Registrar e Maintainer e di cui gli enti assegnatari sono Registrant ed utilizzatori finali. Un altro importante controllo è quello sulla recursion, che consiste nel verificare che i nameserver siano interrogabili solo dalle persone autorizzate a farlo, tipicamente gli utenti della propria rete.

Quest’ultimo è un aiuto rilevante per prevenire i temibili attacchi DoS…

Esatto. Uno dei principali problemi sulla sicurezza del DNS infatti è la recursion aperta ad utenti non considerati trusted, ovvero a host con indirizzamento non facente parte della propria infrastruttura di rete locale. I nameserver con recursion aperta possono essere teoricamente utilizzati come amplificatori di traffico malevolo proveniente da macchine compromesse nel corso di un attacco di tipo DoS (Denial of Service), indirizzato verso un nameserver vittima. Segnalare tempestivamente la presenza di server con questa configurazione errata, riduce notevolmente il rischio.

Quanti sono i domini e gli indirizzi che controllate attraverso DFD?

Il tool DFD analizza tutte le zone di reverse look up IPv4 e IPv6 e i domini .it e .eu di nostra competenza che, ad oggi, sono complessivamente circa 5.000. Un numero considerevole se si pensa che sulla rete GARR, a differenza di quanto accade nelle reti di provider commerciali, il DNS viene da sempre gestito autonomamente dagli enti. Ciò costituisce sicuramente uno dei principali punti di forza e di robustezza del DNS all’interno della rete GARR, in particolare per ciò che riguarda la sicurezza. In caso di attacchi informatici infatti, più difficilmente il servizio potrebbe essere negato contemporaneamente a tutti gli enti, visto che un eventuale attacco al DNS di qualunque natura, potrebbe coinvolgere solo un numero limitato di utenze. Allo stesso tempo, però, la gestione autonoma del servizio, può contribuire a far perdere di vista, nel lungo periodo, il corretto funzionamento del DNS su tutte le zone che GARR amministra. Per questo motivo, abbiamo introdotto questo sistema in grado di monitorare in modo automatico il DNS sulla nostra rete.

Qual è il bilancio dei primi 6 mesi?

Prima dell’entrata in funzione di DFD non era mai stato fatto un monitoraggio di questo tipo sulla rete GARR, quindi il numero di errori nel DNS rilevato nella fase iniziale è stato considerevole. Il numero di segnalazioni è stato di circa 1.100 in soli sei mesi. Il 73% di questi allarmi è stato già gestito e risolto positivamente. Tra gli errori più comuni abbiamo rilevato la mancata corrispondenza tra nameserver registrati e quelli propagati (61%) ed errori di risoluzione del DNS (32%). Minori, per entità, le recursion aperte e le mancate configurazioni di indirizzi. Nei diversi ambiti in cui facciamo il controllo abbiamo registrato una sostanziale parità tra problemi relativi ad indirizzi IPv4 (51%) e domini (48%). L’IPv6 incide molto meno (1%) ma ciò è determinato dal limitato utilizzo di questo protocollo.

Questi controlli ci stanno aiutando anche a fare un’operazione di “pulizia” in rete, visto che siamo riusciti ad identificare e cancellare decine di domini che appartengono alla nostra comunità non più utilizzati.

Quali sono i prossimi passi?

Il tool si è già dimostrato di grandissimo aiuto, e ci auguriamo che grazie a questi nuovi controlli ed anche ad una più accorta configurazione dei nameserver da parte degli APM, gli errori sul DNS diminuiscano sempre più.

Nelle prossime versioni di DFD non escludo che potranno essere aggiunti ulteriori controlli su parametri del DNS. Ad esempio, per migliorare la funzionalità della posta elettronica, si potrebbe monitorare la presenza di configurazioni errate degli MX record, utilizzati per specificare il mail server autorizzato a ricevere messaggi, in modo da consentire ai messaggi di arrivare sempre correttamente a destinazione.

Ci piacerebbe, inoltre, rendere disponibile il servizio direttamente all’utente in modo che possa accedere in sicurezza ad un profilo personalizzato e monitorare in modo autonomo la situazione delle zone della propria organizzazione. Mi fa piacere sottolineare che DFD è un progetto completamente open source, quindi le organizzazioni che volessero usarlo per monitorare i propri sottodomini, che al momento non sono controllati da GARR, possono richiederlo per utilizzarlo in casa propria.

DFD è scritto in PHP, fa uso di una base dati MySQL in cui sono raccolte tutte le informazioni sulle zone, necessarie per eseguire i controlli richiesti. Dispone di un’interfaccia web che permette di effettuare l’analisi dei risultati ottenuti dall’acquisizione e di gestire i DNS faults mediante funzionalità di troubleshooting integrate nel tool stesso.

Il controllo sulla configurazione delle deleghe

DFD, esegue un confronto tra i nameserver registrati presso le Authority del .it e del .eu e i nameserver propagati. I nameserver propagati come autoritativi, vengono acquisiti mediante dei collectors, facendo uso di una libreria PHP. Quando si riscontra una mancata corrispondenza (mismatch) tra i nameserver registrati e quello propogati questa viene segnalata dal tool.

Il controllo sulle risposte alle query verso i nameserver autoritativi

DFD acquisisce periodicamente dati sulle zone lanciando alcuni collectors mediante il servizio di scheduling Cron. Esegue delle query sul record SOA (Start of Authority) verso tutti i nameserver autoritativi di ogni zona da controllare. Se in risposta non riceve il record SOA, DFD evidenzierà sull’interfaccia web un errore di configurazione del DNS. Mediante ulteriori funzionalità, è poi possibile restringere il campo di azione esclusivamente sui nameserver autoritativi che presentano un reale problema di configurazione, permettendo così di focalizzare il troubleshooting solo su di essi.

Il controllo sulla recursion aperta ad host not trusted

Quando il DFD esegue la query per ottenere il record SOA di ogni zona da controllare, esegue il parsing dell’output per l’individuazione del flag RA (Recursion Available). I nameserver dovrebbero rispondere alle query con flag RA abilitato solo ad host considerati trusted. In caso contrario il tool segnalerà l’errore.