Qualche necessario strumento software

Tool di rete classici



Per risolvere i casi di spam l'esperienza è sicuramente molto utile, tuttavia gli strumenti sono fondamentali. A completamento di quanto si è visto nella trattazione dei casi pratici, ora passeremo in rassegna le principali interrogazioni di cui ci si può avvalere.


Operazioni DNS elementari
Whois delle autorità di registrazione domini
Whois della Abuse.net
Whois delle autorità di assegnazione indirizzi IP
Traceroute
Query sulle blacklist
Operazioni DNS complesse (dig)


Operazioni DNS elementari

Normalmente tra le prime operazioni che si compiono durante l'investigazione su uno spam c'è il lookup sul DNS. Il DNS diretto è quello che parte da un nome host per fornire il corrispondente indirizzo IP. Si tenga presente che ad un unico nome possono corrispondere più computer, ognuno con un suo indirizzo ip; in particolare, è normale che la query sul nome del mailserver di un grosso provider produca anche 7-8 indirizzi ip. Quanto al reverse DNS, ossia quello che parte da un indirizzo ip per fornire il corrispondente nome host, il discorso si complica. Va tenuto presente che, pur essendo talvolta gestiti da un medesimo soggetto, i DNS diretto e inverso sono non di rado competenza di soggetti diversi e non sempre sono allineati. Un reverse DNS (quando c'è, dato che in un'ampia percentuale dei casi manca del tutto) va sempre verificato eseguendo un DNS diretto sul risultato ottenuto. Si possono avere casi in cui spammer con una propria rete hanno facoltà di definire loro i reverse DNS e se ne avvalgono per fuorviare chi investiga (si parla allora di DNS forgery). In generale, per avere idea di cosa ci si può aspettare, va tenuto presente che colui che ha facoltà di definire il DNS diretto per un dominio può tranquillamente inserire nel proprio dominio nomi di host che, come indirizzo ip, puntino a computer o inesistenti o appartenenti ad altri soggetti che nulla sospettano. Analogamente, colui che ha facoltà di definire il reverse DNS per un blocco di indirizzi può ficcarvi corrispondenze a nomi di fantasia quanto nomi di host realmente esistenti e non suoi.

Va inoltre tenuto presente che i dati DNS sono soggetti a caching e che quindi possono, in certe circostanze, fornire risultati contraddittori (tipicamente a fronte di aggiornamenti).

Un trucco usato dagli spammer

Va segnalato che, mediante speciale programmazione dei propri server DNS, a volte gli spammer riescono a dare l'impressione che il loro sito si trovi non all'indirizzo a cui è realmente, bensì ad un altro indirizzo ip del tutto al di fuori della rete dello spammer. Questo stratagemma è alla portata solo degli spammer meglio organizzati tecnicamente e richiede l'utilizzo (abusivo, ovviamente) di un proxy insicuro che lo spammer abbia potuto trovare. Chi indaga su tali spam trova quindi, come indirizzo del sito, l'indirizzo che in realtà è del proxy. Il sito funziona in quanto il proxy accetta le richieste http e le trasmette al vero sito dello spammer. Risolvere questi casi è, per un normale utente, piuttosto difficile. Ci si può insospettire quando si constata che il sito dello spammer appare essere su un ip noto come proxy aperto e il dominio incluso nel nome del sito è servito da un server dns che stia in tutt'altro blocco di ip. In generale, se il sito dello spammer appare essere ad un indirizzo ip catalogato nelle blacklist di proxy aperti, conviene esaminare gli header della risposta http che si ottiene accedendo al sito in questione, cosa che si può fare tramite una connessione telnet aperta manualmente verso l'indirizzo apparente del sito dello spammer. Se tra gli header della risposta vi succedesse di notarne uno del tipo:

         X-Cache: MISS from squidcache    oppure    X-Cache: HIT from squidcache

magari seguito da un header "Via:", con ogni probabilità siete incappati nel trucco (si noti che, al posto di "squidcache", possono comparire nomi di host o altre parole).

Whois delle autorità di registrazione domini

Tra i dati relativi alla registrazione dei domini risultano interessanti i contatti e i name server. Vedere come si chiama e dove abita il titolare della registrazione di un dominio spesso può essere assai indicativo, dato che non è infrequente che gli spammer, dopo un certo periodo di attività intensa, comincino ad essere conosciuti per nome. Quando invece si tratta del dominio cui appartiene un relay aperto, se si sospetta di non riuscire a farsi adeguatamente sentire scrivendo al postmaster può essere opportuno cercare altri contatti utili. In mancanza d'altro, eventualmente si potrebbe provare ad avvisare il contatto tecnico trovato nella registrazione di dominio e, valutando caso per caso, anche il titolare del dominio (tenendo presente che quest'ultimo potrebbe spesso non avere la più pallida idea di cosa sia un server di posta).

Riguardo alla indicazione dei name server, spesso da lì si riesce già a vedere chi sia il provider che fornisce hosting al dominio. Talvolta, si trova che i server DNS hanno un nome che rientra nel dominio in questione (per esempio, il dominio taldeitali.com potrebbe avere come nameserver ns.taldeitali.com). Per domini di un certo rilievo, può effettivamente succedere che gestiscano il proprio stesso DNS, tuttavia la cosa va verificata osservando l'indirizzo numerico del server, in quanto non è affatto un problema, per chi fosse titolare del dominio e potesse quindi definirne i nomi sotto DNS, creare nomi di suo piacimento e farli puntare, per esempio, agli ip dei server DNS del proprio provider. In altri casi niente affatto rari si troveranno domini che, anziché avvalersi del DNS del medesimo provider che fornisce loro la connettività, utilizzano i servizi di altre aziende, specializzate appunto nel fornire servizio DNS (pare che in questo modo si riesca ad avere un servizio più affidabile e di migliore qualità rispetto al DNS tipicamente fornito da un provider generico, oltre al vantaggio di poter controllare e variare in maniera più semplice, diretta e completa il contenuto dei propri record DNS). È opportuno pertanto verificare sempre se la connettività e il DNS al dominio di uno spammer vengono forniti da un medesimo soggetto, dato che in caso contrario è utile reclamare ad entrambi. Si tenga anche presente che, nella registrazione di dominio, sono dati almeno due differenti name server: un primario (quello sul quale vengono manualmente apportati tutti gli aggiornamenti) ed un secondario (di solito aggiornato periodicamente in maniera automatica). Si può dire con sufficiente certezza che, tra il titolare del dominio ed il fornitore del DNS primario, esiste una qualche relazione di natura contrattuale; non così per il DNS secondario (o terziario, se c'è). Talvolta il DNS secondario viene affidato a grossi backbone o ad altri soggetti, magari in base ad accordi di mutuo scambio di questo servizio, stipulati senza la partecipazione diretta dei domini che ne risultano serviti. È quindi fuori luogo segnalare uno spammer a chi gli fornisce solamente servizio di DNS secondario. Va anche osservato che, per trovare chi sia a fornire servizio DNS ad un certo dominio, un'altra via in fin dei conti preferibile (almeno a titolo di verifica) è mediante il dig, di cui si parlerà tra poco.

Ultima cosa da osservare è che per certi TLD nazionali (un esempio è '.tv') non esiste un whois server, oppure esiste ma non è liberamente consultabile. Problemi analoghi possono pure aversi per certi TLD dell'estremo oriente, per i quali la ricerca della corrispondente authority di registrazione si arena su pagine web piene di caratteri non visualizzabili. Anche in questi casi si deve fare affidamento sul dig.

Whois della Abuse.net

Una fase importante dell'investigazione, che può occasionalmente risultare anche complicata, è la determinazione del corretto indirizzo a cui inviare le segnalazioni per gli abusi relativi ad un dato dominio. È vero che l'indirizzo postmaster dovrebbe sempre esistere e venire letto, tuttavia in molti casi esistono indirizzi specifici che è meglio utilizzare. Determinare questi indirizzi può richiedere tempo, tempo che molti utenti si troverebbero talvolta a dover dedicare contemporaneamente per giungere al medesimo risultato. La Abuse.net centralizza quindi questa informazione, che viene inserita soprattutto dai vari postmaster direttamente, ognuno per quanto lo riguarda. Un tempo, era possibile scaricare dal sito della Abuse.net una enorme pagina con tutti i contatti, poi la dimensione di tale pagina è talmente cresciuta da rendere il download improponibile. Ora quindi i dati possono essere richiesti per un dominio alla volta, o tramite form sul sito della Abuse.net o tramite il relativo server Whois. Anche se oramai l'uso della Abuse.net è diventato abituale per chiunque agisca contro gli spam, appare sempre molto evidente quanto questa risorsa sia preziosa. Qualunque postmaster dovrebbe provvedere a registrare presso la Abuse.Net l'indirizzo di contatto per segnalare abusi dai domini di sua competenza.

Whois delle autorità di assegnazione indirizzi IP

Si tratta di ARIN, LACNIC, RIPE e APNIC, la cui consultazione è un passo inevitabile quando occorre sapere qualcosa di più su un dato indirizzo ip. L'informazione relativa al blocco cui l'indirizzo sotto indagine appartiene è talvolta risolutiva ma ha bisogno di riscontri. Si deve infatti avere chiaro che le indicazioni sulla titolarità dei blocchi di ip possono talvolta non essere aggiornate e, soprattutto, possono non essere indicative. Non è impossibile che un blocco sia intestato ad una organizzazione la quale lo abbia assegnato ad un cliente, il quale cliente si sia poi trasferito sotto un'altra rete, portandosi dietro il blocco di indirizzi. È frequente in casi del genere che, consultando ARIN, il blocco risulti ancora intestato all'originale assegnatario, il quale non sarebbe quindi più il contatto giusto da considerare responsabile per le attività imputabili a quegli ip. Ci sono poi reti (normalmente grossi backbone) che, essendo intestatarie di grossi blocchi ip, li hanno poi a loro volta suballocati ad altre reti più piccole o clienti in genere, senza registrare sotto ARIN queste suballocazioni. Occorre allora individuare queste assegnazioni finali, cosa che per alcune reti (per esempio Exodus, Verio, Dialtone) si può fare mediante una query ai rispettivi rwhois. L'rwhois funziona in maniera analoga ad un normale server whois, salvo il fatto che utilizza la porta 4321 anziché la 43 e salvo il differente formato dell'output (peraltro abbastanza comprensibile). In generale, se l'informazione disponibile tramite questi whois ed rwhois è accurata e aggiornata, contiene molti dati e risulta di grande aiuto. Quando invece questa informazione non sia attendibile, resta ancora una volta da rivolgersi ai record DNS mediante dig.

Gli "zombie"

Un fenomeno le cui dimensioni sono in crescita è quello dell'utilizzo, da parte degli spammer, di blocchi di ip "zombie". In sostanza, lo spammer individua delle allocazioni di spazio ip effettuate molti anni prima, in favore di organizzazioni che nel frattempo hanno cessato le attività o che comunque non utilizzano più tali indirizzi. Allo stesso modo lo spammer può reperire pure degli Autonomous System non più in uso. Si trovano facilmente dei blocchi e degli AS con siffatte caratteristiche soprattutto (ma non solo) nello spazio di APNIC. Lo spammer riesce ad acquisire il controllo di tali risorse in vari modi, anche presentando documentazione falsificata. L'opera è poi completata generando annunci BGP per il routing e trovando un upstream provider compiacente che propaghi tali annunci. Alla base di questa pratica c'è sicuramente l'assoluto menefreghismo da parte delle authority di registrazione (che in genere, quando messe al corrente, restano abbastanza indifferenti) e il comportamento delle grosse reti che, o per inadeguatezza dei controlli o per vera e propria complicità, rendono funzionanti gli indirizzi zombie. Queste cose danno anche misura di quale sia la potenza economica dei grossi spammer. Per ciò che riguarda il normale utente che indaga sullo spam, ciò che possiamo consigliare è di verificare sempre ogni indirizzo ip sulle blacklist: i blocchi zombie sono infatti per la maggior parte noti e catalogati.

Traceroute

Il traceroute è soprattutto uno strumento diagnostico, che consente di verificare quale percorso di rete viene seguito dai pacchetti in viaggio da una certa provenienza verso una certa destinazione. Il traceroute funziona sfruttando come segue il time-to-live assegnato a pacchetti ICMP. Il time-to-live è un parametro previsto dal protocollo ip e usato durante il percorso di un pacchetto da un host all'altro: ogni host che riceve il pacchetto provvede, prima di inoltrarlo al successivo host che deve riceverlo, a decrementare il time-to-live e controllare che non sia azzerato. Se fosse azzerato, considera il pacchetto scaduto e non gli fa proseguire il percorso. Lo scopo per cui esiste il time-to-live è di impedire che, in situazioni di errore in qualche configurazione, si abbiano pacchetti che girino per la rete su percorsi chiusi e senza fine.

L'host che esegue il traceroute inizia emettendo 3 pacchetti ICMP diretti all'host destinazione, nei quali il time-to-live è settato in modo che, appena ricevuti dal primo host del loro percorso, questo li debba considerare scaduti. Ne consegue che tale host, anziché passarli al successivo host del percorso, si limita a rispondere con un ICMP di errore al mittente. Il mittente registra quindi il tempo impiegato per ricevere questi ICMP di errore nonché l'ip dell'host che li ha emessi, e provvede a ripetere l'invio dei 3 pacchetti, settando però questa volta il time-to-live in modo che essi riescano a sopravvivere fino al secondo hop. Anche in questo caso otterrà i 3 ICMP di errore, i quali proverranno però dal secondo host, e così via, incrementando il time-to-live iniziale finché, eventualmente, si raggiungerà la destinazione richiesta.

Ne risulta quindi un elenco di indirizzi ip che descrivono, nell'ordine, il percorso di rete seguito. Questo consente di vedere attraverso quali reti si passi per andare da un dato punto di partenza ad un punto di arrivo. Inoltre, i tempi di ritorno registrati sui vari hop consentono di valutare la qualità del collegamento e individuare quali siano i tratti che introducono i maggiori tempi di latenza.

L'utilità di questo strumento ai fini dell'investigazione antispam risulta, nella pratica, non elevatissima, anche se in molti casi può risultare di aiuto, tipicamente quando con altri mezzi non si siano avute indicazioni del tutto chiare o quando, come che sia, si desideri una conferma a conclusioni che ormai si andassero profilando.

Il ragionamento che sta dietro la decisione di provare un traceroute è del tipo: "se la rete X fornisce connettività allo spammer Y, allora eseguendo un traceroute verso Y mi aspetterei di vedere, subito prima delle risorse di Y, quelle di X." Se vedo quel che mi aspetto, ok. Se no, il traceroute comunque non costituisce una prova che quel certo collegamento non esista. Si tratterà di ripetere il traceroute da diversi punti di partenza, e magari questo porterà a scoprire più di un altro percorso, del tutto differente, che giunge alla stessa destinazione. Per eseguire traceroute da altri punti di partenza basta trovare siti che mettano a disposizione dei traceroute pubblicamente utilizzabili (una lunga lista si può trovare a http://www.traceroute.org/). Si tenga comunque presente che, se anche eseguite il traceroute da centinaia di punti di partenza da tutte le parti del mondo, i risultati non potranno mai dimostrare che un dato collegamento non esista.

Riguardo alla lettura dell'output di un traceroute, bisogna tenere conto di alcune cose:

Si può osservare che, non essendo attendibili i reverse DNS, risulta vantaggioso avvalersi di traceroute che forniscano, per ogni hop, anche il numero di Autonomous System cui quell'ip appartiene. Un esempio è il traceroute disponibile sul sito SamSpade.org (il sorgente di un traceroute con questa prerogativa è disponibile, per sistemi Unix, sugli archivi FTP del RIPE; inoltre questa ed altre funzionalità si possono trovare nel programma Looking Glass, disponibile pur esso presso vari siti). Disponendo del numero di AS si possono cercare i relativi dati su ARIN, LACNIC, RIPE o APNIC, avendo così una indicazione attendibile su quale sia la rete di appartenenza (anche se non certo a livello di microdettaglio, dato che gli AS vengono attribuiti solo a reti di una certa importanza).

Seguendo questa linea, comunque, il discorso si fa complicato e richiede sempre più conoscenza di problematiche di routing. In genere, per problemi di spam basta meno. L'utilità di uno strumento come il traceroute, in definitiva, è che contribuisce a completare qualche pezzo del mosaico che rappresenta la situazione generale della rete a cui ci si sta interessando, mettendo magari in evidenza qualche collegamento secondario attraverso altre reti. Lo scopo per chi stia indagando su uno spam è, in effetti, quello di avere una visione della situazione generale, in modo da individuare dove, tra i vari soggetti che appaiono, esistano effettivamente relazioni di affari o di altro genere. Se la situazione non è chiara subito, non è lungo questa via che conviene insistere.

Query sulle blacklist

Testando specifici indirizzi rispetto alle blacklist si può spesso risparmiare lavoro e tempo. Per esempio, supponete di ricavare dagli header del messaggio di spam l'indirizzo da cui il server del vostro provider ha ricevuto il messaggio. Possono verificarsi vari casi:

Operazioni DNS complesse (dig)

Il DIG è un comando normalmente disponibile sui sistemi Unix. Tramite questo comando si effettuano query che si rivolgono ai server DNS, per richiedere varie tipologie dei record in essi definiti. Un uso disinvolto del DIG richiede una conoscenza del DNS quale solo gli amministratori di rete (che effettuano queste definizioni come parte del loro quotidiano lavoro) possono avere. Tuttavia alcune di queste query hanno un significato sufficientemente chiaro e possono essere utilizzate da tutti. Un'analisi rigorosa dei record DNS sarebbe pesante ed esulerebbe dai nostri scopi, per cui qui ci si limiterà a far notare (semplificando e banalizzando il più possibile) unicamente un po' di cose che possono aiutare chi stia indagando su uno spam. In particolare, tra i record che possono avere interesse nelle investigazioni antispam menzioniamo i seguenti (guardando gli esempi riportati, si consideri che il formato e il contenuto delle risposte al comando possono variare in dipendenza dalla versione di DIG utilizzata e dalla completezza delle definizioni che si incontrano):

MX
Mail Exchanger.
Questo record viene normalmente definito per i domini, in modo da indicare quale sia il mail server cui indirizzare le email dirette a caselle di un certo dominio. Un esempio del risultato di questa query su un nome dominio può essere il seguente:
; <<>> DiG 8.2 <<>> nomedominio.net mx
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; QUERY SECTION:
;;  nomedominio.net, type = MX, class = IN

;; ANSWER SECTION:
nomedominio.net.     2d16h55m55s IN MX  20 mailserver1.nome.net.
nomedominio.net.     2d16h55m55s IN MX  10 mailserver2.nome.net.

;; AUTHORITY SECTION:
nomedominio.net.     1d16h55m55s IN NS  ns1.altronome.net.
nomedominio.net.     1d16h55m55s IN NS  mailserver1.nome.net.

;; ADDITIONAL SECTION:
mailserver1.nome.net.      8h13m30s IN A   192.0.2.35
mailserver2.nome.net.      15h16m19s IN A  192.0.2.36
ns1.altronome.net.         8h13m30s IN A   192.0.2.120
Qui si vedono indicati (nella Answer section) gli host che fanno da mail exchanger per il dominio "nomedominio.net" (ne sono indicati due con differente priorità). Pertanto, inviando email a qualunquecosa@nomedominio.net il messaggio verrà consegnato al primo di quei due host disponibile. La stessa query indica poi i name server autorevoli per il dominio in questione (Authority Section) e, nell'ultima sezione, gli indirizzi ip corrispondenti a tutti i server indicati nelle precedentementi sezioni.
NS
Name Server.
A seconda della query, questo record indica quale sia il server DNS autorevole per un dato dominio. Normalmente comunque può essere che, come si è visto sopra, la query MX per un dominio già contenga l'informazione relativa ai name server, nel qual caso questa query non porta risultati aggiuntivi utili per una investigazione antispam. La query NS può essere effettuata anche su un indirizzo ip, nel qual caso fornisce generalmente la Authority section relativa all'indirizzo specificato. Per vedere un esempio di authority section rimandiamo al successivo punto, riguardante le query SOA.
SOA
Start Of Authority.
Con questa query si può individuare chi ha autorità sulle definizioni relative ad una certa risorsa, sia essa un dominio o un indirizzo ip completo o parziale. Si riesce anche a vedere a quale livello esattamente sia stabilita l'autorità. Nell'esempio che segue è stato fatto un dig SOA sull'indirizzo 12.1.2.3:
; <<>> DiG 8.2 <<>> soa -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;  3.2.1.12.in-addr.arpa, type = SOA, class = IN

;; AUTHORITY SECTION:
2.1.12.in-addr.arpa.    2h59m31s IN SOA  cbru.br.ns.els-gms.att.net. hostmaster.mail.att.net. (
                    2       ; serial
                    1D      ; refresh
                    2h46m40s    ; retry
                    6d22h40m    ; expiry
                    1D )        ; minimum
L'indirizzo oggetto di questa query è di AT&T (cui appartiene l'intera classe A degli indirizzi inizianti per "12."). Si presti attenzione a ciò che compare come oggetto del record, in questo caso il "2.1.12.in-addr.arpa." qui evidenziato in rosso: da lì si nota che lo start of authority qui indicato vale per tutti gli indirizzi inizianti per "12.1.2." (ciò che precede "in-addr.arpa" va rovesciato per assumere significato come indirizzo ip). I dati interessanti visibili in questo ouput sono due:
Altro esempio, questa volta relativo al SOA su un nome di dominio:
; <<>> DiG 8.2 <<>> linux.it soa
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; QUERY SECTION:
;;  linux.it, type = SOA, class = IN

;; ANSWER SECTION:
linux.it.       1D IN SOA   spock.linux.it. postmaster.linux.it. (
                    2000122001  ; serial
                    2H      ; refresh
                    15M     ; retry
                    6W      ; expiry
                    1D )        ; minimum


;; AUTHORITY SECTION:
linux.it.       1D IN NS    spock.linux.it.
linux.it.       1D IN NS    ns2.publinet.it.
linux.it.       1D IN NS    dns2.nic.it.
linux.it.       1D IN NS    ns.vitaminic.net.
linux.it.       1D IN NS    dns.mixadlive.com.

;; ADDITIONAL SECTION:
spock.linux.it.     1D IN A     151.99.137.27
spock.linux.it.     1D IN AAAA  3ffe:1001:210:1::1
ns2.publinet.it.    1D IN A     151.99.137.5
dns2.nic.it.        1d22h17m23s IN A  193.205.245.8
ns.vitaminic.net.   2h49m5s IN A    209.207.238.101
dns.mixadlive.com.  1d22h46m54s IN A  213.254.5.3
Il risultato di questa query va letto in maniera del tutto analoga a quello precedentemente esaminato, salvo che qui il record SOA compare entro una Answer section, mentre la Authority section elenca i server DNS autorevoli per il dominio oggetto della query. Si noti che uno dei name server elencati possiede, oltre al normale indirizzo ip, anche un indirizzo IPv6 (quel 3ffe:1001:210:1::1, notazione a cui prima o poi bisognerà iniziare ad abituarsi).
ALL
Questa query, utilizzabile essenzialmente su indirizzi IP, dà come risultati vari tipi di record DNS, il che la può rendere utile in molti casi. Per esperienza può capitare che dalle query SOA o NS non si riesca a ricavare molto (non tutte le reti, purtroppo, tengono perfettamente in ordine le definizioni DNS) e che, in questi casi, la query ALL sia l'unica che consente di vedere dei dati e individuare quindi il soggetto competente su una certa risorsa.
; <<>> DiG 8.2 <<>> all -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;  27.137.99.151.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
27.137.99.151.in-addr.arpa.  1D IN PTR  spock.linux.it.

;; AUTHORITY SECTION:
137.99.151.in-addr.arpa.  1D IN NS  ns.publinet.it.
137.99.151.in-addr.arpa.  1D IN NS  dns.interbusiness.it.

;; ADDITIONAL SECTION:
ns.publinet.it.     1D IN A     151.99.137.2
dns.interbusiness.it.   4h29m26s IN A   151.99.125.2
Qui non compare il record SOA, ma nella Answer section compare il record PTR (quello tramite il quale vengono definiti i reverse DNS sui singoli indirizzi ip). La Authority section elenca i server DNS autorevoli per l'indirizzo in questione: si nota in proposito che l'autorità di tali nameserver è data per tutto il blocco 151.99.137.* (al solito rovesciando ciò che precede "in-addr.arpa"). Trovare i server DNS autorevoli per un blocco di IP (in altre parole, quei server da cui dipendono i reverse DNS su quel blocco di IP) è, in certi casi, l'unica informazione che aiuta a capire con chi prendersela per qualcosa che è stato fatto da un certo indirizzo ip. È il caso di quando dalle query su ARIN o RIPE non si ricavassero informazioni sufficienti. Sarebbe in linea di principio normale che i server trovati per un certo indirizzo fossero della stessa organizzazione intestataria del relativo blocco ip, ma ciò può benissimo non accadere. A fronte di divergenze non c'è una regola generale su come comportarsi, tuttavia il possessore dei name server ha certamente un notevole grado di autorità sull'indirizzo in questione e, eventualmente, potrebbe anche avere una relazione d'affari con l'intestatario del blocco ip.

Va infine tenuto presente che un dig può venire rivolto a qualsiasi name server (sarà suo compito rivolgersi ricursivamente al nameserver autorevole per la risorsa sotto indagine). Se però il risultato ottenuto non apparisse convincente o si volesse riscontro, esiste normalmente la possibilità di dirigere la query direttamente su un name server specifico. Si avrà cura, in questi casi, di sceglierne uno che si suppone autorevole per quel dominio o indirizzo ip. Questo artificio può, in teoria, sgombrare il campo di vecchi dati in cache, tuttavia solo in qualche caso risulta utile.


Indice    << Precedente    Successiva >>

Ultimo aggiornamento: 02 giugno 2003

Leonardo Collinelli

e-mail