DNS

cover story Risoluzione dei problemi DNS nel nuovo decennio [di Mark Minasi]

Come semplificare la risoluzione dei nomi sulla rete W1103022.indd 22

30/05/11 16:19

cover story

A

vete un problema con Active Directory (AD)?

Ci sono buone possibilità che in realtà si tratti di un problema di DNS. Non riuscite a connettervi al vostro account di posta elettronica, di Twitter o di Facebook? È molto probabile che il vero problema sia ancora nel DNS. Snidare problemi legati a DNS è il secondo passaggio della procedura di risoluzione praticamente di qualsiasi problema di rete, ma sapere come risolvere un problema di DNS è come colpire un bersaglio in movimento, visto che continua a cambiare.

Essendomi già occupato in passato nei miei articoli dei concetti fondamentali della risoluzione dei problemi di DNS, oggi daremo per scontata la conoscenza della basi, per dare un’occhiata a una vecchia idea.

Scopriremo come semplificare la risoluzione dei nomi utilizzando un paio di strumenti di risoluzione dei problemi di DNS decisamente superiori a Nslookup e scagioneremo Extension Mechanisms for DNS (EDNS), un nuovo arrivato in Windows Server 2008 R2, spesso imputato di alcune mancanze.

Disabilitare WINS Quando si dice, “Controlla DNS”, è solitamente un modo breve per dire “Controlla l’intera infrastruttura di risoluzione dei nomi”, che include broadcast NetBIOS locali, WINS e il nuovo Network Discovery, che ha fatto la sua comparsa con Windows Vista, per non parlare dei file HOSTS e LMHOSTS. Non sorprende pertanto che la risoluzione dei problemi di risoluzione dei nomi sia così complicata.

Prima di disabilitare WINS, dovreste naturalmente testare la vostra configurazione di rete senza tale servizio (compresa l’impostazione di NetBIOS su TCP/IP nelle proprietà TCP/IP).

Penso che rimarrete sorpresi da quante poche cose, per non dire poco o nulla, hanno ancora bisogno di WINS, sebbene ciò dipenda dal livello di modernità dei vostri sistemi operativi client e server.

Disabilitare WINS è infatti una pessima idea in Windows 2000 Server, fattibile ma occasionalmente seccante in Windows

Server 2003 e in Windows XP e praticamente indolore in Vista e nei sistemi operativi successivi. C apite tuttavia che il solo fatto che il sistema operativo funzioni in un ambiente senza NetBIOS, non significa che la cosa vada bene anche alle vostre applicazioni.

Ho sentito per esempio che molte applicazioni anti-malware richiedono NetBIOS, anche se non mi sono mai imbattuto in una situazione di questo tipo.

Nel caso abbiate occasionalmente bisogno di WINS per questa o quella applicazione, studiatevi come si utilizza la zona GlobalNames di Server 2008, in quanto questo può aiutare DNS a svolgere parte del lavoro di WINS

Utilizzare Network Monitor Tutti conoscono Network Monitor, ma la maggior parte ha ancora timore a utilizzarlo, mentre in realtà non dovrebbe.

Network Monitor acquisisce e visualizza ogni pacchetto di rete che entra o esce dal sistema, mettendo a nudo per l’ispezione ogni singolo bit che attraversa la vostra NIC. Netmon inizialmente sembra uno strumento per cinture nere, mentre per certi versi è anche più adatto per chi si occupa quotidianamente di risolvere i problemi legati a DNS, in quanto consente agli amministratori di impiegare un vecchio detto, ossia "è difficile riconoscere il ‘malato’ se non sia che aspetto ha il ‘sano’”.

Se pertanto eseguite Netmon sul vostro sistema quando funziona, continuate a farlo anche quando le cose non funzionano.

Confrontate quindi le due acquisizioni e giocate un po’ a “Trova le differenze”, prima di quanto crediate inizierete a racimolare indizi.

So che il solo menzionare Netmon fa scappare a gambe levate molti, ecco allora una veloce introduzione a Netmon e DNS. In questo esempio, imposterò un server DNS Server 2008 R2, che ho configurato per guardare a se stesso per risolvere gli indirizzi DNS. Ho detto al server di eseguire il ping di www.bigfirm.com e di acquisire il traffico di rete ottenuto con Netmon.

Il risultato sarà un caos totale di chiacchiericcio di rete per lo più irrilevante, un quintale di minerale da cui vogliamo estrarre qualche piccola pagliuzza d’oro.

Il primo passo consiste nell’installare Network Monitor (lo strumento può essere scaricato gratuitamente all’indirizzo www.microsoft.com/downloads/en/details. aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f).

Figura 1: Schermata iniziale di Network Monitor

23 W1103022.indd 23

30/05/11 16:19

cover story per scaldare i motori, quindi tornate al prompt dei comandi e digitate ping -n 1 www.bigfirm.com

Figura 2: Schermata Capture di Network Monitor

Figura 3: Visualizzazione del traffico specifico di DNS

Quando si avvia Netmon, è bene assicurarsi di fare clic con il pulsante destro del mouse sulla relativa icona e scegliere Esegui come amministratore.

La prima volta che si avvia Netmon, viene chiesto se si desidera utilizzare Microsoft Update. Dopo aver chiuso questa finestra di dialogo, verrà visualizzata una schermata iniziale come quella illustrata nella figura 1.

La finestra inferiore sinistra controlla il traffico che si desidera acquisire.

Non ci occuperemo del traffico isatap e Teredo, per cui potete deselezionare queste caselle di controllo e lasciare selezionata solo la casella Local Area Connection.

Ignorate anche l’opzione P-Mode, abilitarla complicherebbe solo le cose. Fate clic sulla scheda New capture nella finestra superiore sinistra.

La schermata Capture che viene aperta, illustrata nella figura 2, è una delle ragioni per cui gli amministratori hanno tanta paura di Netmon. Per semplificarla, chiudete il riquadro Network Conversation sul lato sinistro e il riquadro Hex Details nell’angolo inferiore destro, lasciando solo Display Filter, Frame Summary e Frame Details.

Per mettere all’opera Netmon, aprite un prompt dei comandi e fate clic sul triangolo verde accanto a Start nella finestra Netmon. Date a Netmon un secondo

Eseguito il comando Ping, tornate a Netmon e fate clic sul quadretto blu accanto a Stop.

Congratulazioni, avete eseguito la vostra prima acquisizione! Osservate le informazioni di stato nella parte inferiore della finestra di Netmon per vedere quanti pacchetti di rete avete acquisito.

A seconda della velocità con cui avete lavorato e dell’attività della rete, potreste trovare da una decina a un centinaio o più di frame. Indipendentemente dal numero, questi frame avranno l’aspetto di un caos completo.

Per separare la pula dal grano, dovrete creare un filtro di visualizzazione.

Per visualizzare solo il traffico specifico di DNS, immettete DNS nel campo di testo Display Filter e fate clic su Apply.

Vedrete una schermata come quella illustrata nella figura 3. Questa schermata di esempio mostra solo i sei pacchetti che mi interessano (ho rimosso le colonne Process, Time Offset e TimeDateLocalAdjusted, in quanto non erano rilevanti ai fini di questa acquisizione).

Questi sei pacchetti mostrano come un server DNS trova praticamente qualsiasi host in un dominio .com. Per prima cosa, il server DNS locale interroga un server radice alla ricerca dell’indirizzo host www.bigfirm.com (pacchetto 6, da notare “Query for www.bigfirm.com…”).

Il server radice risponde, “Non ho idea, ma se chiedi a uno dei server DNS .com, potrà aiutarti” (pacchetto 7, da notare “Response-Success”).

Quindi il server DNS chiede a un server DNS .com l’indirizzo host di www.bigfirm.com (pacchetto 8) e gli viene detto che no, il server DNS .com non è in grado di aiutarlo, ma che il server DNS potrebbe provare a chiedere al server DNS di bigfirm.com (pacchetto 9).

Il server DNS allora chiede allora al server DNS di bigfirm.com l’indirizzo host di www.bigfirm.com (pacchetto 10) e finalmente ottiene la risposta che desidera (pacchetto 11).

Da notare che Netmon tiene traccia di chi semplifica la conversazione tramite

24 W1103022.indd 24

30/05/11 16:19

cover story le colonne Source e Destination: il mio server DNS locale è 19.168.1.125, il server radice è 192.203.230.10, il server DNS .com è d.gtld-servers e il server DNS di bigfirm.com è web2.minasi.com.

Questa è ovviamente una panoramica molto generale.

Per visualizzare la gerarchia di un pacchetto, fate clic sul primo dei frame filtrati e guardate nel riquadro Frame Details. La figura 4 mostra la gerarchia del pacchetto, che Netmon chiama frame.

Questo frame contiene il pacchetto Ethernet, che a sua volta contiene il pacchetto IPv4. All’interno di IPv4 si trova il pacchetto UDP (potrebbe essere TCP, ma la maggior parte del traffico DNS viene eseguito su UDP) e all’interno di questo si trova la query DNS vera e propria. Il riepilogo di ogni livello include gli indirizzi o le porte rilevanti e la lunghezza.

Per entrare più nel dettaglio nella query DNS, fate clic sul segno più (+) per espandere il frame DNS, come illustrato nella figura 5. Il livello di dettaglio di Netmon in questo frame è piuttosto chiaro da capire. Si vede una query (anziché di una risposta), una risposta (record host per www.bigfirm.com) e un ulteriore record che spiegherò tra un istante.

Nei dettagli DNS del frame successivo noterete che il server radice risponde dicendo al server DNS, “Vai a parlare con un server DNS .com” semplicemente restituendo l’elenco dei 13 server DNS .com. Il server DNS rivolge la stessa query ai server DNS .com, ripetendo la procedura in tutta la gerarchia DNS fino a quando non ottiene la risposta.

Ma in che modo queste informazioni possono aiutarci a risolvere problemi di DNS? Di recente, uno dei miei server DNS ha smesso di rispondere alle query DNS. A peggiorare le cose, dando un’occhiata alla registrazione dettagliata offerta dai server DNS Windows ho scoperto che il server DNS non aveva ricevuto alcuna query.

Era possibile che in qualche modo il firewall avesse iniziato a bloccare il traffico DNS? Il modo più rapido per scoprirlo era eseguire Netmon, che mi ha confermato che era esattamente così, la NIC riceveva le query DNS da altri sistemi, potevo vedere i frame e potevo vedere che

Figura 4: Visualizzazione dei dettagli di un frame

il mio server DNS non aveva risposto a nessuna di queste. Ero fiducioso che non si trattasse di un problema DNS, ma piuttosto che riguardasse qualcosa nel routing e nell’IP stesso. Ero abbastanza sicuro che disabilitando RRAS il problema sarebbe stato risolto (la risposta definitiva sembrava essere che una patch aveva danneggiato i miei server VPN basati su RRAS e in qualche modo era riuscita anche a passare allo stack IP). Senza il chiarimento fornito da una traccia Netmon, avrei trascorso delle ore a scartare i possibili colpevoli.

Basta Nslookup.

Ben arrivato DIG Lo strumento di base per la risoluzione dei problemi di DNS fornito con Windows è ovviamente Nslookup.

Ma lo sapevate che gli utenti UNIX dispongono da anni di un'alternativa decisamente migliore, che si chiama Domain Information Groper (DIG)? DIG non è inserito in Windows, ma è facile da trovare e è un ottimo strumento da aggiungere alla vostra cassetta degli attrezzi DNS. Per ottenere DIG, visitate il sito web di

download di Internet Systems Consortium all’indirizzo www.isc.org/downloads e scaricate l’ultima versione di BIND, attualmente BIND 9.7.2-P3. BIND è un programma gratuito che è anche il server DNS più popolare di Internet.

Create quindi una cartella sul disco rigido del vostro sistema, aggiungete la cartella alla variabile di ambiente PATH del vostro sistema e copiate i file dal file zip BIND nella cartella (se preferite, potete eliminare tutto quanto si trova nella cartella a eccezione dei file DLL, dig.exe e di dig.html, ossia il file di Help di DIG, in quanto non stiamo eseguendo BIND, per cui non abbiamo bisogno di tutti gli altri file).

La sintassi di base di DIG è la seguente: dig record-to-query-for [@dnsserver] [querytype] [+option1, +option2…]

Per cui una query come la seguente: dig bigfirm.com ns @192.168.1.125

dirà a DIG di domandare al server DNS all’indirizzo 192.168.1.125 di cerca-

Figura 5: Frame DNS espanso

25 W1103022.indd 25

30/05/11 16:19

cover story rezza ci costringe a eseguire le nostre gerarchie DNS che servono AD al di fuori della gerarchia pubblica, il che determinare una serie di errori di configurazione che +trace può aiutarci a stanare.

Copiate DIG su uno stick USB ed eseguitelo su un sistema che presenta dei problemi, utilizzando +trace per trovare il record host del controller di dominio.

Questa operazione aiuta spesso a far luce sul problema. Una volta data un’opportunità a DIG, scommetto che non tornerete più a Nslookup.

Controllare EDNS

Figura 6: Output di una query DIG

re tutti i record di server dei nomi per bigfirm.com.

La figura 6 mostra l’output di questa query, da notare il livello di dettaglio maggiore dell’output di DIG rispetto a quello di Nslookup.

Saltate alcune righe e passate alle due che iniziano con ->>HEADER<<-, contengono le informazioni dell’intestazione DNS prese sostanzialmente dal frame e riformattate leggermente.

Le informazioni di status dicono se la query non è andata a buon fine perché il record non esisteva (NXDOMAIN), se si è verificato qualche tipo di errore di configurazione sul server (SERVFAIL), se non si è verificato alcun errore (NOERROR) o se è stata inviata una query non valida, come domandare un tipo di record che non esiste (FORERR).

Vengono quindi i flag nell’intestazione DNS. Una bella funzionalità di DIG consente di costringere i flag dell’intestazione DNS ad assumere particolari valori quando si esegue la query. Così, per esempio, se avessimo aggiunto +norecurse, DIG avrebbe impostato il flag per dire al server DNS in questione di eseguire solo il primo passo della risoluzione di bigfirm.com, il che in questo caso avrebbe restituito solo i server radice.

L’opzione +trace va oltre e fa sì che DIG stampi esattamente ciò che il server DNS sta facendo quando trova il server DNS di bigfirm.com.

Questo strumento è molto utile per chiunque esegua AD, in quanto la sicu-

Terminiamo con un argomento in cui mi imbatto di continuo e in merito a cui mi vengono continuamente poste delle domande.

Ho scoperto che molti pensano che una funzionalità DNS denominata EDNS stia rendendo i server DNS basati su Server 2008 R2 incapaci di risolvere i comuni nomi di domini Internet e che la soluzione sia quella di disabilitare EDNS. In realtà EDNS non è nuovo, né è in errore. Come molti protocolli Internet di base, i nostri requisiti per DNS sono passati dalle specifiche 1983 (RFC 882) originali, costringendo le autorità Internet a cercare di escogitare dei modi per far entrare nuove funzionalità in uno spazio piccolo e progettato in maniera assolutamente non flessibile.

Dico che DNS è stato progettato in maniera non flessibile perché fa un utilizzo massiccio di un piccolo numero di flag da 1 bit, che indicano cose come se una query deve essere ricorsiva e se un dato server DNS è in grado di eseguire una ricerca ricorsiva.

Le specifiche RFC originali consentono spazio sufficiente per sette flag di questo tipo, di cui uno solo non viene utilizzato. Avete avuto una fantastica idea per risolvere un problema DNS utilizzando un nuovo flag? Peccato, a meno che non cambi qualcosa, non c’è posto nella locanda.

Il problema dello spazio ridotto deriva dal fatto che ogni volta che DNS comunica tramite UDP, cosa che è preferibile, in quanto UDP è velocissimo e Internet contiene molto traffico DNS, è limitato da una dimensione di pacchetto massima di 512 byte.

Questo limite di 512 byte è stato imposto dalle RFC 883 (1983) e 1035 (1987) e si basa su una serie di considerazioni legate alle reti degli anni ‘80 che oggi sono del tutto superate.

Per esempio, avete mai notato che ben pochi domini in Internet annunciano più di 13 server DNS? Anche il dominio radice oberato di lavoro pubblicizza 13 server DNS, mentre in realtà ne ospita 236 e utilizza il clustering per far sembrare che siano pochi.

Questo perché annunciare più di 13 server creerebbe un pacchetto superiore a 512 byte, costringendo a tornare al più lento TCP. Come dicevo, avevamo bisogno di più flag e di pacchetti più grandi, ma non volevano espandere DNS in modo da creare un incubo di compatibilità DNS a livello planetario. La risposta?

Le RFC 2671 del 1999 ed EDNS. EDNS fornisce un modo intelligente per consentire

a una popolazione in continua crescita di server DNS che supportano EDNS di rilevare se stanno parlando con altri server DNS che supportano EDNS (e quin-

26 W1103022.indd 26

30/05/11 16:19

cover story di poter sfruttare i vantaggi di più flag e più spazio) oppure con server che non supportano EDNS (nel qual caso continuano a mantenere le cose precedenti alle RFC 2671, evitando problemi di compatibilità).

Quando un richiedente che supporta EDNS interroga un risponditore alla ricerca di un record DNS, formatta la richiesta nel formato DNS standard ma aggiunge anche un altro record alla propria richiesta: un tipo di record DNS nuovo per EDNS denominato record OPT. OPT non assomiglia agli altri record DNS più familiari, come A, MX, NS, SOA e CNAME, non vedrete mai un record OPT in un file di zona. È più come un handshake segreto che solo i server che supporta-

no EDNS conoscono, un bit di dati aggiunto a una query.

Supponiamo per esempio che un richiedente che supporta EDNS voglia recuperare il record A per un sistema denominato PC1 nella zona bigfirm.com dal server DNS di bigfirm. Un richiedente precedente a EDNS richiederebbe solo il record A del risponditore.

Al contrario, un richiedente che supporta EDNS direbbe, “Ho due richieste per te.

Primo, ho bisogno del record A per ‘PC1’ in bigfirm.com, e secondo, ecco una query OPT con il valore ‘4000’”.

Il valore 4000 è il modo con cui il richiedente dice, “Hey, supporto EDNS e se vuoi inviarmi un pacchetto superiore a 512 byte, sono in grado di gestire qualsiasi pacchetto UDP fino a 4.000 byte”.

Se il risponditore non supporta EDNS, non riconoscerà il record OPT, nel quale caso lo ignorerà e risponderà solo al tipo di query familiare del record A, senza generare alcun messaggio di errore (in tal modo conservando la compatibilità con le versioni precedenti).

Se invece il risponditore supporta EDNS, risponderà sia alla richiesta del record A che alla richiesta del record OPT. Nella risposta OPT includerà anche un numero che dichiara quanto è grande il pacchetto UDP che è in grado di gestire.

Pertanto, se un richiedente inviasse una query OPT=4096 alla fine di un’altra query e se il risponditore rispondesse con una risposta OPT=1280, il richiedente saprebbe per prima cosa che l’altro lato supporta EDNS e in secondo luogo che può utilizzare pacchetti UDP di dimensione maggiore, ma comunque non superiore a 1.280 byte.

Che cosa può andare storto in questo processo? Immaginiamo che il server Server 2008 R2 che supporta EDNS interroghi un altro server che supporta EDNS e che decidano di utilizzare un pacchetto UDP superiore a 512 byte.

Questa dimensione del pacchetto viene frammentata (mentre i pacchetti da 512 byte non vengono mai frammentati) e

molti router NAT (Network Address Translation) economici scartano i pacchetti frammentati.

Peggio ancora, alcuni firewall dispongono di regole di sicurezza che dicono, “Se è DNS ed è UDP e se è anche superiore a 512 byte, deve essere cattivo, per cui scartatelo”. In entrambi i casi, si ottiene lo stesso risultato, una risoluzione che non va a buon fine.

La soluzione migliore è calcolare quale hop nel viaggio causa il problema, cosa non sempre è possibile.

Un altro approccio consiste più semplicemente nel dire al server Server 2008 R2 di non inviare più query OPT e quindi di non avviare mai transazioni EDNS. È possibile farlo da un prompt dei comandi con privilegi elevati utilizzando il comando che segue: dnscmd /config /enableednsprobes 0

Non è necessario alcun riavvio dopo questo comando e sostituendo il valore 0 con il valore 1 si annulla l’effetto.

Tuttavia, l’unico effetto di questo comando è impedire a Server 2008 R2 di avviare una conversazione EDNS. Se un server DNS interroga il server Server 2008 R2 con un pacchetto OPT, il server Server 2008 R2 risponderà tranquillamente in modalità EDNS, per cui accertatevi che i vostri router e firewall non dispongano di un filtro in uscita che uccide i pacchetti DNS UDP grandi.

EDNS non è nuovo di Windows Server; Windows DNS lo supporta fin da Server 2003.

L’unica modifica di Server 2008 R2 è stata abilitare le richieste di tipo probe.

EDNS non è nemmeno un qualche tipo di protocollo futuristico esotico, considerato che alcune intercettazioni del mio traffico Internet mostrano che almeno l’85% dei server DNS di ogni tipo supporta EDNS e lo utilizza a proprio vantaggio.

Sarebbe un peccato che il vostro server DNS Server 2008 R2 non potesse sfruttare i vantaggi di EDNS, per cui non vi resta che procedere con un po’ di lavoro di riconfigurazione dei router prima di testare il vostro server DNS.

27 W1103022.indd 27

30/05/11 16:19