dns | Rev0lut1on 2.0 of my mind engine

Ago 21 2008

Dig e il DNS Response Time: come verificare che i server OpenDNS rispondono più lentamente alle query DNS rispetto a quelli italiani di Alice di Telecom Italia

Sinora ho parlato spesso dei DNS e in particolare degli OpenDNS (un servizio che offre liberamente i propri DNS per uso pubblico), sia quando i server DNS di Telecom Italia furono messi in ginocchio, sia per l’annuncio di una vulnerabilità insita nel protocollo DNS stesso che potrebbe permettere ad un malintenzionato, tramite il DNS Cache Poising, di controllare il traffico internet e fare del Pishing (per controllare se i vostri DNS sono sicuri, potete verificare sul completo e chiaro dns-oarc.net o sul più sintetico doxpara.com), sia, per finire, per i test di velocità che feci tra i server DNS di Alice Telecom Italia e quelli OpenDNS in cui i primi risultarono, al ping, molto più veloci dei secondi.
Ed è proprio a proposito di quest’ultimo articolo che vorrei riprendere e, al contempo, ampliare, l’argomento della velocità dei server DNS, stimolato anche da un commento di un mio lettore nel suddetto articolo, che asserisce:

ICMP non è UDP (o TCP). Può darsi comunque che i server OpenDNS siano più veloci alle query DNS anche se sono più lenti al ping.

In effetti le sue affermazioni sono teoricamente ineccepibili, anche se, a parer mio, poco probabili. Infatti le mie analisi partivano dal presupposto che non vi esistessero filtri tra i vari protocolli usati. Per fugare ogni dubbio, ho deciso quindi di rendere più precise le mie valutazioni, misurando anche quanto impiegano i server DNS a rispondere alle query.

Ma prima di partire con queste analisi, è necessario rispolverare un po’ di teoria sul DNS.

Un po’ di teoria sul DNS

Il DNS (Domain Name Service) è un servizio che permette di tradurre nomi di dominio come www.levysoft.it in indirizzi IP come 64.57.102.34 (grazie ad un database distribuito di servers DNS). Infatti, i computer non sono in grado di instradare i pacchetti verso un nome di dominio ma solo verso il corrispondente indirizzo IP. L’adozione del DNS, quindi, ha il solo scopo di semplificare la vita a noi esseri umani, in quanto risulta molto più facile ricordare una stringa testuale mnemonica piuttosto che un anonimo indirizzo IP.
Se, quindi, assegnare nomi ai computer rende la memorizzazione molto più semplice, è evidente che a questo punto è necessario uno strumento, come quello del DNS, in grado di associare automaticamente i nomi agli indirizzi IP.

Per risolvere l’indirizzo IP esistono diversi comandi:

host: viene usato per associare nomi ad indirizzi IP. È una utility, per Linux e Mac OS X, molto rapida e semplice, con poche funzioni:
host levysoft.it
levysoft.it has address 69.71.248.10 levysoft.it mail is handled by 0 levysoft.it.

host è considerato insieme a dig il sostituto ufficiale di nslookup.
nslookup: (Name Server Lookup) è uno strumento consolidato presente in tutti i sistemi operativi che utilizzano il protocollo TCP/IP (Gnu/Linux, Unix, MAC OS X, Windows) ma che, essendo superato, potrebbe anche essere rimosso in molte future versioni delle distribuzioni Linux.
Nslookup consente di effettuare delle query (richieste) ad un server DNS per la risoluzione di indirizzi IP o Hostname, per poter ottenere da un dominio il relativo indirizzo IP o nome host e viceversa.

nslookup levysoft.it
Non-authoritative answer: Name: levysoft.it Address: 69.71.248.10

Nonostante sia considerato obsoleto, in quanto è stato uno dei primi tool in grado di lavorare con il DNS, nslookup è un comando ancora molto potente. Per esempio, con due soli comandi, whois e nslookup, è possibile scovare i DNS Pubblici di un provider. Il primo serve a determinare chi ha registrato il nome di dominio, mentre il secondo interroga i DNS per risolvere l’indirizzo IP del server.
dig: (Domain Information Groper) è il comando più potente per recuperare informazioni relative al Domain Name Server indicato, inclusi reverse lookup, A, CNAME, MX, SP e record TXT. Dig è molto usato sia per la sua grande flessibilità che per i suoi output molto chiari. Contrariamente a nslookup, dig non contempla una modalità interattiva, ma è disponibile solamente in modalità non interattiva o batch che permette di fargli leggere le richieste da un file.
Dig ha una tale infinità di opzioni (tanto che da molti viene considerato l’alternativa più verbosa e completa a nslookup), che nella sua pagina di manuale gli sviluppatori fanno dell’ironia su questo fatto tanto che, sotto la voce BUGS, si trova “There are probably too many query options“.

La sua sintassi è la seguente:

dig [@nameserver] [opzioni] [nome_risorsa] [tipo_di_richiesta] [ulteriori_opzioni])

ma, di norma, si utilizza nel modo seguente:

dig @server name type

Se non specificato, dig utilizza come server per le richieste quello presente in /etc/resolv.conf.

Dig, il cui nome deriva dal verbo inglese to dig (scavare, scoprire o investigare), è una utility presente in qualsiasi sistema operativo all’interno del quale è installato l’ambiente DNS BIND; pertanto essa è disponibile nativamente in ambiente Linux/Unix e Mac OS X, mentre è assente su Windows.
Se volete usarlo anche sui sistemi Windows, allora dovrete scaricarvi la versione compilata per Windows, DIG, che permette la restituzione dei record DNS per un dominio specifico anche sulla piattaforma di casa Microsoft.

Calcolare il time response delle query DNS

Ora che abbiamo superato la parte più noiosa della teoria, passiamo alla pratica, basandosi sempre sui primi test di velocità effettuati con il classico ping che misurava il tempo, espresso in millisecondi, impiegato da uno o più pacchetti ICMP di echo request a raggiungere un server DNS.

Questa volta, però, sfruttando il potente comando DIG, ho inviato delle query dirette ai server DNS e calcolato il DNS Response Time, ovvero il tempo che il server impiegava a risolvere un nome di dominio che gli veniva passato. Questo valore ovviamente è direttamente proporzionale alla distanza geografica del server (come per il ping) e alla velocità di elaborazione del server, teoricamente molto bassa e che a sua volta dipende dal carico di sistema. In poche parole, con queste due componenti avremo la possibilità di effettuare test i più veritieri possibili, ponendosi proprio come se fosse il PC ad interrogare il server DNS.

In pratica, i comandi da lanciare dal proprio PC, per i vari server presi in esame saranno:

OpenDNS
dig http://www.levysoft.it @resolver1.opendns.com
;; Query time: 37 msec

DNS TIN
dig http://www.levysoft.it @212.216.112.112
;; Query time: 3 msec

Esistono, poi diversi tool online per calcolare il tempo di risposta di una query DNS. Tra questi, ne ho presi in esame 2 colocati all’estero: DIG: look up DNS domain IP address information e Dig DNS Check.

Ed ecco i risultati:

DNS Response Time dei server DNS Alice
DNS	Average Time [PC]	Average Time [kloth.net t]	Average Time [ip-plus.net]
212.216.112.112	3 ms	26 ms	19 ms
212.216.172.62	3 ms	28 ms	16 ms
194.243.154.62	1 ms	26 ms	16 ms
195.31.190.31	3 ms	27 ms	15 ms

Ed ecco i risultati per i server OpenDNS:

Tempo di risposta dei server DNS OpenDNS
DNS	Average Time [PC]	Average Time [kloth.net t]	Average Time [ip-plus.net]
208.67.222.222	38 ms	22 ms	22 ms
208.67.220.220	38 ms	21 ms	22 ms

Come vedete, i risultati sono molto simili a quelli ricavati con il PING ICMP. Qui in Italia, i tempi di risposta sono nettamente superiori per i server OpenDNS, a causa, appunto, della localizzazione geografica.
Discorso inverso, invece, si applica se la query viene lanciata da un server estero: gli OpenDns sono più veloci di quelli Alice.

Con questo articolo quindi ho dimostrato che le analisi effettuate con un PING ICMP assumono la stessa valenza statistica di quelle effettuate con i DNS Response Time delle query inviate direttamente al server DNS.

Ovviamente con questi test non voglio assolutamente affermare quale server DNS prediligere: i motivi per cui è vantaggioso scegliere gli OpenDNS sono innumerevoli, per cui sta a voi decidere cosa è meglio per il vostro sistema in base alle vostre esigenze ed aspettative.

Tag:Alice, dig, dns, opendns, tin

6 comments

Ago 12 2008

Tips Mac: come aggiungere il suffisso DNS su Mac OS X

Posted by Antonio Troise

In una rete locale, solitamente, il DNS è utilizzato per denominare i nodi TCP/IP, come i computer Windows o gli host Unix, in modo da risolvere i nomi simbolici. Lo schema dei nomi è gerarchico e consiste di nomi come wks1.domain.com. Perché un nome di dominio sia qualificato, occorre che sia combinato con il nome dell’host, per creare quello che i gergo tecnico si chiama FQDN (Fully Qualified Domain Name), ovvero un nome di dominio non ambiguo che specifica la posizione assoluta di un nodo all’interno della gerarchia dell’albero DNS:

FQDN = nome di host + nome di dominio

Quindi, se il nome di dominio è STARGATE.COM, il nome FQDN per l’host WKS1 è il seguente:

FQDN = WKS1 + STARGATE.COM = WKS1.STARGATE.COM

Quando un computer ricorre ad una interrogazione DNS per risolvere un nome costituito da un semplice nome di host senza l’estensione di dominio, il nome di dominio del DNS primario è aggiunto di default al nome di host.
L’opzione, presente in qualsiasi sistema operativo, di aggiungere altri suffissi DNS rispetto a quello indicato dal DNS Primario configurato, serve ad indicare un elenco di suffissi DNS (nell’ordine desiderato) che possono essere aggiunti al nome di dominio non qualificato. Così, se il nome del computer è WKS1 e il nome di dominio è STARGATE.COM e si tenta di fare un telnet, o una qualsiasi altra connessione, al server col solo nome del computer WKS1:

telnet WKS1

il nome di host inizialmente cercato sarà WKS1.STARGATE.COM. Nel caso il nome di host non sia risolto, quindi, verranno scansionati tutti gli altri suffissi DNS alla ricerca di un risoluzione del nome FQDN.

Aggiungere il suffisso DNS su Mac OS X

Per abilitare questa possibilità su un sistema Mac OS X, basterà aprire le Preferenze di Sistema, cliccare sull’icona Network, e dopo aver selezionato la rete usata (Ethernet o Wi-Fi),

cliccare sul tasto Avanzate e, nella finestra che si aprirà, selezionare il tab DNS e nel campo Domini di ricerca aggiungere i suffissi di dominio desiderati:

Tag:dns, dominio, Mac os x, risoluzione, Tips, Tips Mac, unix, wi-fi, Windows

0 comments

Lug 30 2008

Controllate che i server DNS del vostro Provider non soffrano della grave vulnerabilità che permette ad un malintenzionato di controllare il traffico internet e fare del Pishing!

Posted by Antonio Troise

Avete presente quella notizia di qualche mese fa di una vulnerabilità insita nelle specifiche del DNS (Domain Name System), scoperta da Dan Kaminsky, che permetteva di alterare il funzionamento del DNS stesso in modo da fornire agli utenti delle “traduzioni” sbagliate e quindi far credere agli utenti di stare visitando un sito fidato? Questa falla del DNS è in grado di dare la possibilità ad un aggressore di sostituirsi perfettamente e in tutta semplicità ad un sito fidato, mettendo di fatto in ginocchio la sicurezza della rete mondiale.

A differenza di altre falle informatiche, però, questa vulnerabilità interessa praticamente tutti i programmi di gestione del DNS proprio perché seguono le specifiche tecniche: tutti i più diffusi sistemi operativi, da Windows a Linux, da BSD a Mac OS X e quasi tutti i provider sono quindi potenzialmente vulnerabili!

L’incontro segreto

Fortunatamente, dati gli effetti devastanti di questa vulnerabilità, in quanto minava alla base la fiducia nei sistemi di internet, dopo una riunione segreta (per non dare la possibilità di rendere di dominio pubblico le specifiche tecniche ancora prima di poter diffondere una patch), il 31 Marzo 2008 presso il campus di Microsoft, a Redmond, si sono riuniti i più grandi nomi del mercato informatico (tra cui Microsoft, Sun e Cisco) per trovare una soluzione al problema.

La diffusione della patch

Così, l’8 Luglio 2008, tutti i maggiori sistemi operativi (sorprendentemente Apple quel giorno arrivò in ritardo forse distratta dall’imminente uscita del iPhone 3G e del servizio .Me) hanno distribuito, più o meno velatamente, tramite i meccanismi di aggiornamento automatico, questa patch. Infatti, gli accordi erano che tutti i sistemi operativi, e quindi tutti gli utenti e tutti i provider di accesso a Internet, dovevano applicare questa patch al proprio software di gestione del DNS o, nei casi limite, passare ad una sua versione aggiornata.

Non tutti i provider hanno chiuso la falla

Il problema, però, è che non tutte le aziende e i provider che gestiscono un domain name server, si sono mossi in tempo e molti provider, fra cui anche alcuni italiani, non hanno ancora provveduto a bloccare questa grave vulnerabilità.
Sul sito del CERT trovate la lista di tutti i sistemi e dei sistemi operativi che sono vulnerabili o meno a questa falla: il problema è che qui, come immaginabile, non sono elencati tutti i provider che hanno risolto il problema per cui, se mentre navighiamo su internet, usiamo fiduciosi dei DNS assegnati dal nostro provider, potrebbe accadere che questi possano essere attaccati e, quindi, potrebbe aumentare la possibilità di subire attacchi di pishing (in effetti stanno ad iniziare a spuntare alcuni esperimenti di attacco basate su questa vulnerabilità).

In ogni caso i dettagli circa la falla non verranno rilasciati prima di un mese circa, tempo in cui si spera che ormai le patch siano state installate su tutti i computer del mondo. Inoltre, a detta di Kaminsky, le patch non dovrebbero permettere il reverse-engineering (o per lo meno, non in tempi brevi), dato che un’analisi di questo tipo potrebbe consentire di concretizzare un exploit funzionante.

Come controllare che i propri server DNS non soffrano del bug

Se volete essere, quindi, certi di poter navigare sicuri, allora vi consiglio di usare un test, come suggerito dal sempre informato Paolo Attivissimo, presente sulla homepage del sito Doxpara Research. E’ sufficiente cliccare sul tasto “Check My DNS” presente nella sidebar a destra del sito, per sapere se il vostro provider ha già provveduto ad installare la patch. Sfortunatamente, come ho potuto appurare io stessi, alcuni server DNS di Telecom Italia, soffrono ancora di questa vulnerabilità. Vi consiglio, quindi, di usare direttamente i server OpenDNS: essendo un sistema centralizzato è stato più facile aggiornarli velocemente.

Ovviamente, quando scrissi che, per un utente italiano, a causa di latenze georgrafiche molto alte dei server OpenDNS rispetto a quelli Telecom, consigliavo di usare i server DNS italiani di Alice, oggi la situazione si è completamente ribaltata perché ad essere a rischio è la nostra navigazione su internet, per cui invito tutti, a meno che tutti i provider non risolvano presto la situazione, ad usare i server OpenDNS.

Tag:Alice, cisco, Dan Kaminsky, dns, exploit, Internet, Linux, microsoft, opendns, patch, Provider, sicurezza, Windows

2 comments

Apr 7 2008

DNS Alice vs OpenDNS: confronto tra i tempi di risposta dei server DNS. I server Alice sono nettamente più veloci ma solo per un utente italiano per via delle latenze geografiche

Posted by Antonio Troise

Spesso mi capita di sentirmi chiedere quali DNS inserire per la propria connessione Alice. Io di solito snocciolo quelli classici di Telecom Italia anche se l’ultima esperienza che ho avuto mi ha fatto propendere verso quelli OpenDNS. I vantaggi degli OpenDNS sono indubbi:

Proteggono dal phishing: riconoscono automaticamente i siti “finti” che cercano di rubarvi soldi e/o informazioni.
Sono veloci: grandi quantità di cache riducono la consultazione di molti server diversi.
Correggono gli errori di digitazione: tutte le volte che sbaglio a digitare un indirizzo, OpenDNS cerca di capire dove avrei voluto veramente andare.
Infine, un innegabile vantaggio per la privacy, è senza dubbio quello di riuscire a svincolare la propria connessione utente dal controllo, spesso invadente, dei providers.

Il sistema mantiene i propri costi di gestione in maniera molto semplice; quando ci si collega ad un sito inesistente visualizzerà una pagina pubblicitaria.

Indirizzi DNS Alice e Tin

Ecco i più comuni indirizzi DNS di Alice: se avete problemi di lentezza, latenza o di risoluzione domini (con il comando nslookup dominio.it potete accertarvi del problema), provate questi:

212.216.112.112
212.216.172.62
194.243.154.62
195.31.190.31

Indirizzi DNS OpenDNS

Questi, invece, sono gli indirizzi DNS di OpenDNS:

208.67.222.222
208.67.220.220

Confronto dei tempi di risposta tra DNS Alice e Open DNS

Premetto che queste non sono prove assolute e non hanno l’ardire di dare un responso univoco, ma sono relative solo alla mia connessione Alice. Ho notato, però, una certa lentezza di risposta al ping dei server OpenDNS rispetto a quelli Telecom Italia. Ora non so se ciò sia da imputarsi al fatto che la mia connessione è Alice o ad altro, ma sta di fatto che lanciando un semplice Ping (ping -n 10 -l 32 IP) dal mio computer, ottengo tempi di risposta nettamente inferiori a quelli OpenDNS.

Per essere più obiettivo possibile ho eseguito i test anche da un server che eseguiva i Ping ICMP via web (ma posizionato in Italia), come Visual Route, con 10 pacchetti da 32 byte l’uno (valore di default), e un’altra serie di test con il sito Network-Tools (posizionato in America).

Ecco i dati:

Tempo di risposta dei server DNS Alice
DNS	Average Time [PC]	Average Time [VisualRoute.it]	Average Time [Network-Tools.com]
212.216.112.112	1 ms	21 ms	163 ms
212.216.172.62	1 ms	15 ms	167 ms
194.243.154.62	1 ms	15 ms	153 ms
195.31.190.31	1 ms	27 ms	155 ms

Ed ecco i risultati per i server OpenDNS:

Tempo di risposta dei server DNS OpenDNS
DNS	Average Time [PC]	Average Time [VisualRoute.it]	Average Time [Network-Tools.com]
208.67.222.222	102 ms	153 ms	52 ms
208.67.220.220	102 ms	128 ms	53 ms

Come vedete, qui in Italia, i tempi di risposta sono nettamente superiori per i server OpenDNS. Anche aumentando le dimensioni del pacchetto a 512 byte, i risultati non cambiano: 2 ms per Alice e 102 ms per OpenDNS.
Discorso inverso, invece, si applica se il ping si effettua da un server estero: gli OpenDns sono più veloci di quelli Alice.

Interpretare i risultati e conclusioni

Quel che è certo è che, di solito, in provider grandi come è quello di Telecom Italia, si può contare su apparati proprietari fin dalla centrale con la possibilità di dirottare il segnale dell’utente subito nelle loro reti con ovvi benefici sulle prestazioni.

Inoltre, come si vede dalla differenza di tempi di risposta tra un server posizionato in Italia (visualroute.it) e uno posizionato in America (network-tools.com) occorre tenere ben presente che questi test sono sempre influenzati dalla posizione geografica dei server DNS: quelli Alice sono in Italia, mentre quelli OpenDNS all’estero, in particolare sono presenti 5 in America e 1 in Inghilterra:

Palo Alto, California, USA
Seattle, Washington, USA
Washington, DC, USA
New York, New York, USA
London, England, UK

E’ noto che in Italia un ping medio gira al massimo intorno ai 50ms mentre per i server all’estero il ping aumenta (per esempio 90-120ms in Inghilterra e da 150ms in poi per l’America). Certamente un instradamento opportuno potrebbe portare a ridurre i salti (hop) migliorando di una certa percentuale anche i tempi di risposta, ma certamente un utente normale non ha molte possibilità in merito e le latenze geografiche sono un problema da affrontare.

Quindi, a quanto sembra, se cercate prestazioni, vi consiglio l’uso dei server DNS Alice, mentre se tenete alla vostra privacy, cercate la correzione automatica degli errori nei domini e un valido sistema di antipishing, allora i server OpenDNS saranno per voi.
Se poi, un giorno, metteranno qualche altro server OpenDNS anche in Italia, allora sarà indubbio che la scelta dovrebbe inevitabilmente ricadere su questi ultimi!

Al momento, per esempio, io uso i DNS Alice e all’occorrenza, in caso di problemi o latenze molto alte (per fortuna per ora molto rare), mi sposto su quelli OpenDNS (che sembrano fatti più per gli americani e gli inglesi che per noi italiani).

Tag:Alice, dns, opendns

19 comments

Mar 18 2008

Risolvere alcuni problemi delle connessioni di rete con il Repairing delle Network Connections di Windows XP e come ricreare la stessa funzione con 6 comandi DOS

Posted by Antonio Troise

A volte può capitare di imbattersi in problemi di rete su Windows XP che non permettono la normale navigazione sul web o sulla vostra rete aziendale. In questi casi, la maggior parte delle volte, è sufficiente, senza essere dei veri professionisti del TCP/IP e senza leggere alcun manuale di Networking, utilizzare un comodo tool di troubleshooting delle reti incluso nella installazione di Windows che può risolvere, in pochi secondi, la maggior parte dei problemi più comuni: sto parlando del Repair delle Connessioni di Rete.

Dove trovare il Repair Network Connections

Se avete abilitato la visualizzazione nella Tray Area, nell’angolo in basso a destra, verrà visualizzata l’icona di notifica delle connessioni di rete; qui sarà sufficiente andarci col tasto destro del mouse e quindi cliccare su Repair (su Windows XP in italiano troverete la voce “Ripristina“).

Altrimenti, bisognerà cliccare sul Menu Start -> Control Panel (Pannello di Controllo).

Quindi, dalla finestra che vi si aprirà, bisognerà selezionare “Network and Internet Connections”

e infine cliccare sull’icona “Network Connections”

Ora verranno mostrate tutte le connessioni di rete del vostro PC. Nel caso ne disponiate più di una, selezionate quella relativa alla vostra connessione difettosa e, cliccate col tasto destro la voce “Repair“. Se la voce non fosse disponibile, assicuratevi che il cavo di rete sia collegato alla vostra scheda di rete o che la vostra connessione sia nella stato Enable (Abilitato).

A questo punto vi verrà mostrata una finestra a popup che, molto velocemente, vi elencherà tutte le operazioni di fixing che il sistema esegue, per poi dare l’esito positivo con questa finestra.

I passi che esegue il Repair di Windows

Sebbene questa operazione sia alla portata di tutti e non invasiva, a molti sarà venuto in mente di chiedersi il significato dell’elenco delle operazioni di fix sulle Network Connections.
E’ per questo che, basandomi su un esaudiente articolo di SearchNewtorking, vorrei esaminare ciascuno degli step che avvengono quando usate la funzione Repair per capire cosa fanno e perché vengono effettuati. Lo scopo è capire cosa fa Windows XP per risolvere i problemi di rete, per poi eseguire delle operazioni puntuali e magari determinare il vero problema che affligge la vostra connessione di rete.

1. DHCP Renew
Se il vostro collegamento di rete è configurato per ottenere il suo indirizzo automaticamente tramite DHCP, e solo in questo caso, Windows esegue questo primo passo che, in pratica, permette al sistema operativo di mettersi in contatto con il server DHCP da cui l’indirizzo del computer è stato precedentemente acquisito in modo da confrontare la sua configurazione corrente TCP/IP.
Se volessimo ripetere la stessa operazione da riga di comando, quello che si avvicina di più è:

ipconfig /renew

Questo comanda, in realtà, si comporta in modo leggermente diverso dalla funzione Repair; infatti mentre la funzione Repair manda un messaggio Renew multicast a qualsiasi server DHCP disponibile in rete (ovvero chiede a tutti i nodi DHCP delle rete), il comando ipconfig manda un messaggio Renew unicast DHCP (ovvero solo al server DHCP dal quale il computer ha ottenuto la configurazione del DHCP). Ma in definitiva, dato che nelle reti Lan aziendali, solitamente il server DHCP è unico, i due comandi si possono benissimo equiparare.

2. Svuotare la cache ARP
Il secondo passo della funzione Repair è quello di svuotare la cache Address Resolution Protocol (ARP); in pratica la cache ARP contiene gli indirizzi MAC definiti più di recente per i nodi IP sulla rete. Tali indirizzi MAC sono memorizzati nel computer in modo che possa avvenire la comunicazione con i nodi IP senza avere bisogno di doverli definire ripetutamente. Se uno o più dei valori presenti nella cache ARP è errato, può venire a mancare la comunicazione della rete con alcuni nodi IP. Se il valore errato della cache si riferisce al gateway di default verrà a mancare la comunicazione con i nodi sulle sottoreti remote.