Gli indirizzi di rete e il DNS




Gli indirizzi di rete

Qualsiasi computer sia inserito in una rete basata sul protocollo IP deve avere un indirizzo che consenta di distinguerlo dagli altri. Possiamo immaginare l'indirizzo come un numero o un insieme di bit, non ha importanza; ciò che importa è che sia univoco, ossia che in rete non esistano mai due computer che abbiano il medesimo indirizzo. Questo consente di individuare in maniera certa ciascun computer e, soprattutto, consente alla rete di farli parlare l'uno con l'altro, anche se fossero da parti opposte della terra.

Possiamo quindi aspettarci che gli indirizzi di rete siano numeri piuttosto grossi, occorrendo un diverso indirizzo per ogni risorsa della rete a livello mondiale. Infatti gli indirizzi IP sono costituiti da 32 bit, il che significa la possibilità di avere più di 4 miliardi e 290 milioni di indirizzi (sembrano tanti). Per ragioni di comodità, si è consolidato l'uso di indicare gli indirizzi IP con 4 numeri, ciascuno dei quali corrispondente ad un gruppo di 8 bit dell'indirizzo complessivo. Poiché con 8 bit si possono rappresentare i numeri da 0 a 255, ciascuno dei 4 numeri potrà per l'appunto andare da 0 a 255 (possiamo quindi dire che si tratta di esprimersi in una numerazione in base 256). La consuetudine è di scrivere i 4 numeri separati da punti, senza spazi. Per esempio, l'indirizzo così espresso su 32 bit:

11000000000000000000001001001111

corrisponde a 192.0.2.79

E' inusuale ma può capitare di incontrare una notazione degli indirizzi in base 10. Certi spammer sperano di nascondere il vero indirizzo del loro sito web pubblicizzandolo in tale forma. Prendendo come esempio l'indirizzo 192.0.2.79, si tratta di fare un calcolo di questo genere:
indirizzo_base10 = 79 + (256 * 2) + (256^2 * 0) + (256^3 * 192)
ottenendo come risultato 3221226063. Dunque vedendo un sito dato come http://3221226063/ si tratta solo di convertirlo, cosa che varie utility possono fare all'istante.

L'attuale spazio di indirizzamento a 32 bit sta cominciando a diventare sempre più stretto, per questo la RFC2460 definisce la versione 6 del protocollo IP, in cui gli indirizzi saranno a 128 bit. La notazione diventerà più complessa e meno maneggevole, ma abbiamo ancora tempo per prepararci.

D'ora in poi non penseremo più ai bit che stanno dietro ognuno di questi indirizzi, ma adopereremo esclusivamente la notazione a 4 numeri. Ci occorre anche avere chiaro che, di questi 4 numeri, sono maggiormente significativi quelli a sinistra. Ciò significa che gli indirizzi 192.0.2.79 e 192.0.2.80 sono consecutivi, mentre 192.0.2.79 e 193.0.2.79 non hanno assolutamente nulla a che vedere l'uno con l'altro.

Riguardo all'uso che la rete fa di questi indirizzi, ci basta sapere che, quando un computer deve spedire un pacchetto di bit ad un altro, deve indicare semplicemente l'indirizzo IP del destinatario. Spetterà alle funzioni di routing fornite dalla rete farsi carico di attraversare il mondo per portare il pacchetto a destinazione. Il pacchetto dovrà contenere l'indirizzo IP del mittente, in modo che il destinatario sappia a chi rispondere.

L'assegnazione degli indirizzi di rete

Particolarmente interessante per le nostre esigenze è dare uno sguardo al meccanismo con cui alle varie reti private che compongono la cosidetta Internet viene data facoltà di usare certi indirizzi. Esistono ovviamente opportune autorità preposte all'amministrazione dello spazio di indirizzi disponibili e, quindi, alla attribuzione degli indirizzi stessi a chi ne faccia richiesta. Tutto fa capo alla IANA (Internet Assigned Numbers Authority), che gestisce al massimo livello lo spazio indirizzabile, delegando le effettive assegnazioni a vari organismi per macroaree geografiche. In particolare le assegnazioni vengono gestite da:

Ciascuna di queste autorità gestisce proprie porzioni dello spazio indirizzabile (si trovano informazioni al proposito sul sito della IANA), assegnando indirizzi ai soggetti richiedenti che operano nelle rispettive zone di competenza. Come facilmente immaginabile, gli indirizzi non vengono attribuiti a caso ma per intervalli. A seconda della dimensione dell'intervallo di indirizzi assegnato, in base ad una terminologia vecchia ma tuttavia ancora usata si parla di classe A, B o C.

Come si vede, restano dei buchi. In particolare sembrano non usati gli indirizzi il cui primo numero sia 127 e quelli in cui sia compreso tra 224 e 255. Quelli compresi tra 224 e 255 sono riservati a classi speciali che non ci interessano, quelli che iniziano per 127 sono gli indirizzi cosidetti di loopback, ossia puntano tutti alla macchia stessa su cui vengono usati: è uno standard del protocollo IP (e indirizzi inizianti per 127 non possono mai comparire in Internet).

Potete effettuare una facile verifica sul vostro computer, per esempio eseguendo un ping a qualsiasi indirizzo iniziante con 127, anche mentre siete disconnessi dalla rete. Se usate un sistema Windows basta aprire una finestra DOS e digitare ping seguito dall'indirizzo. Vedrete che il computer si risponderà da solo senza problemi. Ancora più illuminante se, anzichè ping, effettuerete il comando tracert.

Ci sono anche altri intervalli di indirizzi che non vengono assegnati su Internet. Sono quelli riservati alle reti private interne, le cosidette Intranet. Per questo uso sono previsti gli indirizzi da 10.0.0.0 a 10.255.255.255, quelli da 172.16.0.0 a 172.31.255.255 e quelli da 192.168.0.0 a 192.168.255.255.

Per ulteriori dettagli sull'assegnazione di indirizzi per le reti private si veda la RFC1918.

Vediamo di riassumere tutto in uno specchietto:

Valori Uso
da 1.0.0.0 a 9.255.255.255 Blocchi di classe A
10.*.*.* Reti private interne
da 11.0.0.0 a 126.255.255.255 Blocchi di classe A
127.*.*.* Loopback
da 128.0.0.0 a 172.15.255.255 Blocchi di classe B
da 172.16.0.0 a 172.31.255.255 Reti private interne
da 172.32.0.0 a 191.255.255.255 Blocchi di classe B
da 192.0.0.0 a 192.0.255.255 Riservati
da 192.1.0.0 a 192.167.255.255 Blocchi di classe C
da 192.168.0.0 a 192.168.255.255 Reti private interne
da 192.169.0.0 a 223.255.255.255 Blocchi di classe C
da 224.0.0.0 a 255.255.255.255 Riservati per classi speciali

Come sono di solito indicati i blocchi di indirizzi

Le classi A, B e C appena viste corrispondono ai tre tipi di blocchi in cui veniva normalmente suddiviso, agli albori della creazione della rete, lo spazio ip ai fini dell'assegnazione. Ben presto è emersa la necessità di indicare e assegnare blocchi di svariate dimensioni, arbitrariamente posizionati entro lo spazio ip indirizzabile. La notazione che quindi oggi si incontra frequentemente e che è opportuno conoscere si basa, anziché sulle classi, sul numero di bit dell'indirizzo il cui valore è fisso e che quindi contraddistingue ciascun blocco. Per vedere alla luce di questa notazione le vecchie classi, basta tenere presente che ciascuno dei 4 numeri che compongono un indirizzo ip corrisponde a 8 bit. Quindi abbiamo per esempio che, in una rete di classe A, essendo fisso il primo dei 4 numeri dell'indirizzo ip, i bit fissi sono 8, così le reti di classe A vengono più spesso indicate come /8. Dunque quando si trova scritto 9.0.0.0/8, ciò sta ad indicare il blocco degli ip da 9.0.0.0 a 9.255.255.255. In maniera analoga le reti di classe B hanno 16 bit fissi e sono quindi chiamate /16, per finire con le reti di classe C che sono dette /24. Oggi si possono trovare indicati blocchi di tutte le dimensioni, per esempio il "/32" che indica un singolo indirizzo, o il "/25" che indica un blocco di 128 indirizzi o il "/20" che contiene 4096 indirizzi. Questa notazione, nota come CIDR (Classless Inter-Domain Routing), trova supporto oggi nelle apparecchiature di rete e mette quindi i provider in condizione di poter assegnare in ogni caso sottoblocchi della dimensione più opportuna per ciascun cliente.

Un caso pratico che può capitare

A questo punto, sapreste certamente rispondere alla gentile signora o signorina che tempo fa, sul newsgroup news.admin.net-abuse.email, ha postato questo messaggio:

I have no idea which of these received lines are forged (if any).
Tips?
[Traduzione: Non ho idea quali di questi received siano falsificati (se ce ne sono). Avete suggerimenti ?]
>Return-Path: <us@century.com>
>Delivered-To: nomecasella@easynet.co.uk
>Received: (qmail 18979 invoked from network); 21 Feb 1998 18:08:43 -0000
>Received: from unknown (HELO mail.earthcom.net) (206.26.134.12)
>  by kiwi.mail.easynet.net with SMTP; 21 Feb 1998 18:08:43 -0000
>Received: from century.com (sfdn8-148.sf.compuserve.com [206.175.227.148])
>    by mail.earthcom.net (8.8.5/8.8.5) with SMTP id OAA00363;
>    Mon, 16 Feb 1998 14:03:27 -0500 (EST)
>Received: from verycool.com (ver-us23c1.verycool.com [246.418.348.431])
>    by mail.earthcom.net (7.5.9/8.3.8/Mx-mnd) with ESMTP id TAA47321;
>    Sat, 21 Feb 1998 10:03:55 -0400 (EDT)
>Received: from century.com (cen-us83d4.century.com [239.339.541.485])
>    by verycool.com (8.8.9/9.4.8/mx-mnd) with SMTP id TBB16415;
>    for <>;Sat, 21 Feb 1998 10:03:55 -0400 (EDT)
>Message-Id: <48534235322.HAA158232@century.com>
>To: dllvxi@mjgxxpuamov@fgxamxhnxvh@qbhtcvyirwd@ehhjajnubjq@qljdk
>Date: Sat, 21 Feb 1998 10:03:55 -0400
>From: "Moneyyesterday@homebiz.com"<mbmrtq@jrgap.comiqtkof@rctxc.comnxuvdv@brsup.comjfmqyc@llakc.comiwpvgd@wscab.com>
>Reply-To: <user@8techs.com>
>Comments: Authenticated sender is <mbmrtq@jrgap.comiqtkof@rctxc.comnxuvdv@brsup.comjfmqyc@llakc.comiwpvgd@wscab.com>
>X-Sender: Yourdora (32 bit)
>X-UIDL: 473a128a123a193a683a13a133a103a1
>Subject: Rocket your business with cost effective Marketing ! - fqilgcgoikwtagdimpudxegho
>

Facile: gli ultimi due 'Received:' hanno degli indirizzi IP manifestamente non validi perché contenenti numeri maggiori di 255. Gli ultimi due 'Received:', inoltre, sembrano fatti con lo stampo, hanno esattamente lo stesso modello di nomenclatura per le risorse e, dulcis in fundo, hanno la stessa data ora minuti e secondi, cosa assolutamente poco verisimile.


Questa falsificazione così grossolana dà anche la misura della sfrontatezza cui certi spammer arrivano. Non parliamo poi delle assurde stringhe di caratteri messe nei campi direttamente settabili dal mittente, o del campo 'X-sender:' in cui hanno messo una storpiatura del nome di un famoso programma di posta elettronica. Qui occorre verificare quel 206.26.134.12 che compare sull'unico header 'Received:' assolutamente attendibile, quello inserito dal server di easynet.net. Constatato che, effettivamente, esso corrisponde al mail server di earthcom.net, diventa attendibile anche il 'Received:' successivo, che indica un nodo di Compuserve (anche qui va verificata la corrispondenza tra nome e IP). Il nodo di Compuserve non è un server, ma il computer di un utente. La catena quindi finisce qui, non importa quanti altri falsi 'Received:' siano stati inseriti. Normalmente, dovrebbe essere considerato con sospetto pure il fatto che il sever di earthcom abbia indicato nell'header una data 5 giorni precedente. In questo caso l'header deve necessariamente essere vero, come poc'anzi detto, ma è veramente raro che un mail server giri con la data di sistema sballata.


Vediamo ora come un altro frequentatore del newsgroup ha risposto al messaggio:

>>Received: (qmail 18979 invoked from network); 21 Feb 1998 18:08:43 -0000
>>Received: from unknown (HELO mail.earthcom.net) (206.26.134.12)
>>  by kiwi.mail.easynet.net with SMTP; 21 Feb 1998 18:08:43 -0000
>>Received: from century.com (sfdn8-148.sf.compuserve.com [206.175.227.148])
>>    by mail.earthcom.net (8.8.5/8.8.5) with SMTP id OAA00363;
>>    Mon, 16 Feb 1998 14:03:27 -0500 (EST)

It's easiest to go in reverse order, starting with your own Received: line,
and you can generally ignore all the (8.8.5/8.8.5) stuff and the dates.

Your server, kiwi.mail.easynet.net, got it from mail.earthcom.net.

Earthcom.net got it from Compuserve, though the HELO said century.com.

Compuserve --> earthcom.net --> You.

>>Received: from verycool.com (ver-us23c1.verycool.com [246.418.348.431])
>>    by mail.earthcom.net (7.5.9/8.3.8/Mx-mnd) with ESMTP id TAA47321;
>>    Sat, 21 Feb 1998 10:03:55 -0400 (EDT)
>>Received: from century.com (cen-us83d4.century.com [239.339.541.485])
>>    by verycool.com (8.8.9/9.4.8/mx-mnd) with SMTP id TBB16415;
>>    for <>; Sat, 21 Feb 1998 10:03:55 -0400 (EDT)

The above is gibberish, though the gibberish is getting better. They would
have you believe that Earthcom got it from verycool.com, and that
verycool.com got it from century.com. But, of course, those IPs are a riot.

It looks like they want to establish a chain like this:

century.com -> verycool.com -> earthcom.net -> you.

But relays don't quite work that way, even if these idiot spammers finally
learned the largest decimal number that fits in eight bits.

>>Reply-To: <user@8techs.com>

Sometimes, depending on the spam, a Reply-To: can be real. I didn't look,
though.
Quasi contemporaneamente, la signora o signorina che aveva posto la domanda aveva pure lei notato gli indirizzi IP non validi ed ha chiuso il thread con quest'ultimo (simpatico) messaggio:
>I have no idea which of these received lines are forged (if any).
>Tips?

Aargh, scrap that hastily posted message, of course I do.

<Hits herself over the head>

Should have looked a little more closely at those IP numbers before
posting, sorry!

Il Domain Name Service

Come tutti sanno, in rete i computer vengono indicati per comodità con dei nomi facili da ricordare (ad esempio www.yahoo.com) ma, come detto all'inizio di questa pagina, ciò che veramente conta e consente ai computer di parlarsi è l'indirizzo IP, numerico. Difficilmente gli utenti della rete si rassegnerebbero ad usare i numeri, ma ancora più difficilmente le funzioni di routing della rete potrebbero funzionare sui nomi. Occorre pertanto un sistema che consenta all'utente di indicare per nome il computer desiderato, convertendolo poi nel corrispondente indirizzo IP, utile per raggiungerlo effettivamente tramite la rete. Il sistema che si occupa di questa importantissima funzione si chiama Domain Name Service e viene indicato come DNS.

Possiamo immaginare il DNS come una immensa tabella di conversione (è meglio che abbandoniate l'idea di averne sul vostro tavolo una copia stampata). Essendo impensabile che una siffatta tabella risieda in un luogo solo e che decine di migliaia di amministratori di sistema la accedano in continuazione per aggiornarla, la soluzione adottata è quella del database distribuito. Vale a dire che, grazie ad una organizzazione gerarchica, l'intera rete è divisa in zone, ciascuna delle quali è servita da un server DNS che possiede i dati solo per le risorse appartenenti alla zona stessa. L'amministratore di sistema responsabile per le risorse di quella zona avrà quindi da aggiornare solamente il proprio server DNS, senza bisogno di dire a nessun altro che il tal nome ha cambiato indirizzo o cose del genere.

Non ci serve andare molto a fondo di come funzionino i server DNS, ma è bene avere chiare le linee essenziali, che si possono vedere con un semplice esempio (banalizzato al massimo).

Supponiamo che, dal mio computer, io voglia accedere all'host WWW.EXAMPLE.COM e che scriva tale nome nel mio browser. Il supporto di rete fornito col sistema operativo del mio pc contatterà il server DNS del mio provider (il mio pc è configurato con l'indirizzo di tale server, o comunque è in grado di raggiungerlo) e gli chiederà di dirgli qual è il corrispondente indirizzo IP. Il server DNS del mio provider è però autorevole solamente per la rete del mio provider, di cui non fa parte la risorsa richiesta. Allora il server si rivolge ad un altro server del massimo livello di gerarchia (ce ne sono alcuni dislocati in varie parti del mondo) passando ad esso la mia richiesta. Il server del massimo livello di gerarchia non ha neppure lui la risposta, però è in grado di dire quale sia l'indirizzo IP del server autorevole per il dominio .COM. Come vediamo, quindi, da qualunque nome di rete possiamo estrapolare la frazione più a destra (in questo caso .COM), che costituisce il dominio di massimo livello (top-level domain, anche detto tld) di quel nome di rete. Preso quindi il tld del nome di rete che interessa risolvere, esiste un server dns autorevole per quel tld. Tornando al nostro esempio, non sorprende che a questo punto il server del mio provider vada in pellegrinaggio da quello responsabile per il top-level domain .COM e gli passi la richiesta. In risposta otterrà l'indirizzo di un ulteriore server, responsabile per EXAMPLE.COM, al quale dovrà rivolgersi. Da quest'ultima interrogazione otterrà finalmente l'indirizzo del computer WWW.EXAMPLE.COM. Questo indirizzo verrà consegnato al mio browser che, finalmente, procederà ad attivare la sessione. In realtà non è che ci sia da fare tutte le volte questo giro completo, ma nel nostro caso non ci interessa.

In base al principio per cui chiedere è sempre lecito, è possibile interrogare il DNS anche per la domanda inversa. Ossia, ho un indirizzo IP e mi interessa sapere qual è il nome corrispondente. La risposta può essere o non essere disponibile, dipende se chi gestisce il DNS responsabile per quel blocco di indirizzi ha o non ha definito gli appositi record. Pertanto, non è raro che la richiesta di reverse DNS non dia alcun risultato: ciò non significa nulla. Importante è avere chiaro che, quand'anche si ottenesse risposta, questa va verificata mediante la query diretta sul nome ottenuto. L'amministratore competente per il DNS inverso potrebbe essere tutt'altra persona che quello che cura il DNS diretto, anzi, in genere sono in differenti organizzazioni e non è detto che tra loro si coordinino. Può anche succedere che, nel DNS inverso, siano stati inseriti dei record con nomi volutamente sbagliati. Solo la query diretta è attendibile per forza. Si sono avuti casi di reti dedicate ad ospitare spammer, in cui questa pratica del reverse DNS falsificato è stata usata.

Il quadro completo

E' importante avere chiare alcune operazioni cui chiunque dovrebbe provvedere se volesse allestire una propria rete. Supponiamo quindi che un americano qualsiasi voglia avere in rete alcuni propri computer, da chiamare per esempio www.xyz.com, pop.xyz.com eccetera.

Gli occorrono, tanto per cominciare, gli indirizzi di rete. Per ottenerli si può rivolgere alla autorità competente che per il Nordamerica è, come detto, l'ARIN. L'ARIN gli può assegnare un netblock di classe C. La alternativa più seguita è, però, che l'interessato scelga prima il fornitore di accesso tramite il quale connettersi alla rete e chieda direttamente a lui gli indirizzi necessari. Il fornitore di accesso, che sicuramente ha ottenuto dall'ARIN una buona dotazione di netblock, gli concede l'uso di alcuni indirizzi tra i propri. Conclusa questa fase di definizione degli indirizzi, può iniziare la configurazione della rete del richiedente ed il suo allacciamento. Gli indirizzi assegnati saranno inseriti in varie tabelle in modo che le funzioni di routing della rete sappiano dove instradare i pacchetti diretti a tali indirizzi.

Se al richiedente sta bene che si acceda ai suoi computer specificando indirizzi numerici, è già a posto così. In effetti molti messaggi di spam pubblicizzano siti web di cui è dato solo l'indirizzo numerico. Anche se sarebbe sbagliato generalizzare, è decisamente raro che organizzazioni serie si facciano conoscere per numero di IP. Guardate per esempio il pudore con cui questo spammer comunica il proprio:

Our domain name has still not been set up
thru internic, so please use our IP number.
http://208.28.xxx.yyy/

Dunque il nostro richiedente vuol fare le cose per bene e, per questo, cerca un server DNS. Può allestirne uno lui stesso oppure, come in genere è più pratico, può usare quello di qualchedun'altro (mettendosi ovviamente d'accordo per ottenere questo servizio). Nella maggior parte dei casi la scelta cade sul fornitore di accesso già individuato, ma potrebbe anche venire scelto quello di un terzo soggetto. Quale che sia la soluzione adottata, il nostro richiedente avrà scelto un server DNS (generalmente se ne scelgono due, un primario ed un secondario) e, con tale indicazione, effettuerà la richiesta del nome desiderato (nel nostro caso xyz) alla autorità competente. Quale sia la autorità competente dipende dalla gerarchia scelta. Per i domini non appartenenti a gerarchie nazionali (come nel nostro caso, trattandosi di un .COM) è stato per lungo tempo competente un solo soggetto, Network Solutions (ex InterNic). Nel corso del 1999 l'ICANN (l'autorità che regolamenta centralmente tutto ciò che riguarda i domini di rete) ha cominciato ad abilitare anche altri soggetti alla registrazione di domini com/net/org. Da allora esiste un registry generale (alla url http://www.crsnic.net/) che indica, per ciascun dominio com/net/org, qual è il fornitore presso cui è stato registrato.

Quindi il nostro richiedente sceglierà (per esempio in base a prezzo e reputazione) il "registrar", ossia il soggetto abilitato a fornire registrazioni di dominio. Questo gli assegnerà il dominio xyz.com e provvederà a far aggiornare i server DNS del massimo livello della gerarchia .COM, in modo che tutte le richieste per xyz.com ottengano, in risposta, l'indicazione del server che è stato specificato dall'assegnatario del nome di dominio in questione.

A questo punto, il titolare della nuova rete farà definire nel server DNS scelto i record necessari, che in particolare espliciteranno, per ciascun computer, la corrispondenza tra nome (es. www.xyz.com) e indirizzo. Un record apposito (MX) designerà il server per la posta in arrivo; grazie al record MX qualsiasi mail server, ovunque nel mondo, si trovasse a dover inoltrare email ad un indirizzo tipo nomecasella@xyz.com, potrebbe subito trovare qual è il mail server finale a cui tali email vanno consegnate.

Finalmente tutto è pronto e la nuova rete è così accessibile da tutto il mondo.

I database on-line (WHOIS)

Come detto poc'anzi, non è pensabile avere sul tavolo una stampa completa dei nomi validi di dominio (e del resto non servirebbe a nulla). Però tutti i record relativi alle assegnazioni di indirizzi di rete e di nomi di dominio sono pubblici e consultabili con qualunque connessione Internet. Per l'analisi dei messaggi di spam questi database on-line sono preziosissimi ed occorre abituarsi ad usarli con disinvoltura. E' possibile fare tutta la pratica che si vuole, prendendo i nomi di qualche risorsa di rete ben conosciuta (ad esempio un sito web internazionale, quello del proprio provider ecc..), trovandone l'indirizzo, vedendo in quale netblock rientra, a chi è assegnato il nome di dominio, chi gli fa servizio DNS e così via.

Vedremo più avanti che, per effettuare le interrogazioni ai database in oggetto, esistono appositi client che è possibile installare sotto i più comuni sistemi operativi. Tali client forniscono una interfaccia generalmente più comoda e integrata ma, per fare le cose semplici, consideriamo per ora di usare un qualsiasi browser web. A tale scopo occorre conoscere le URL a cui ottenere questi servizi. Se per esempio cerchiamo informazioni su indirizzi IP del Nord America e su domini dei più diffusi tld (.com .net o .org), terremo presenti queste url:

Se per esempio cerchiamo informazioni su un indirizzo numerico assegnato in Nord America, scopriremo a chi appartiene tramite il whois dell'ARIN:

Trying 206.31.165 at ARIN
MCI Telecommunications Corp - internetMCI Provisioning (NETBLK-MCI-NETBLK05) MCI-NETBLK05
         206.24.0.0 - 206.31.255.255
MIDWEST INFORMATION SYS. (NETBLK-MCI-206-31-164) MCI-206-31-164
       206.31.164.0 - 206.31.165.255

To single out one record, look it up with "!xxx", where xxx is the
handle, shown in parenthesis following the name, which comes first.

The ARIN Registration Services Host contains ONLY Internet
Network Information: Networks, ASN's, and related POC's.
Please use the whois server at rs.internic.net for DOMAIN related
Information and nic.ddn.mil for MILNET Information.

Si noti che la ricerca sul database è stata fatta, in questo caso, con i soli primi 3 numeri dell'indirizzo, cercando quindi una rete di classe C. È comunque possibile inserire un indirizzo completo e, anzi, ciò risulta consigliabile (soprattutto per le interrogazioni sul RIPE, in cui la frammentazione dei blocchi potrebbe indurre a equivoci). Il risultato fa vedere quale sia il netblock in questione (assegnato a MIDWEST) ed evidenzia che è stato ricavato da un netblock molto più ampio, in uso (al tempo in cui questa query venne effettuata) alla MCI. Per avere informazione più specifica si può effettuare un'altra query indicando, al posto dell'indirizzo, il nome indicato tra parentesi preceduto da un punto esclamativo.

Va tenuto presente che spesso i dati su ARIN non sono aggiornati, e che quindi è sempre consigliabile cercare un minimo di altri riscontri. Comunque sia, in molti casi è sbagliato pensare che l'organizzazione intestataria del blocco cui appartiene un certo indirizzo IP sia l'entità da chiamare in causa nei casi di spam dai suoi indirizzi: il quadro completo delle responsabilità non è sempre chiarissimo e semplice da scoprire, tuttavia spesso si ottiene una indicazione significativa cercando chi è responsabile per il reverse DNS sull'indirizzo IP in questione (usando il prodotto SamSpade, di cui si parla qui, si tratta di effettuare il DIG sull'indirizzo).

Se invece vogliamo informazioni su un nome di dominio andremo sul whois di dominio e digiteremo, nel campo di input, il nome del dominio nella forma xyz.com o wxy.net o simili: importante è che non digitiate nomi a livello gerarchico inferiore. Per esempio, digitando www.xyz.com non avreste risposta. Ecco un esempio di risposta ottenuta digitando aol.com:

America Online AOL-DOM
   12100 Sunrise Valley Drive
   Reston, VA 20191

   Domain Name: AOL.COM

   Administrative Contact:
      O'Donnell, David B  DBO3  *******@AOL.COM
      703/265-5666 (FAX) 703/265-4003
   Technical Contact, Zone Contact:
      America Online  AOL-NOC  *****@AOL.NET
      703-265-4670
   Billing Contact:
      Barrett, Joe  JB4302  *****@AOL.COM
      703-453-4160 (FAX) 703-453-4001

   Record last updated on 29-Apr-98.
   Record created on 22-Jun-95.
   Database last updated on 9-May-98 03:38:53 EDT.

   Domain servers in listed order:

   DNS-01.NS.AOL.COM		152.163.200.52
   DNS-02.NS.AOL.COM		152.163.200.116

E' importante sapere che, per problemi di spam, i contatti indicati qui non vanno usati. Normalmente, il contatto amministrativo è qualcuno piuttosto in alto, sovente un dirigente dell'azienda. Capita che qualche segnalazione venga inviata a loro, ma solo in casi di particolare gravità. In linea di massima non dovrete scrivergli mai. Può sembrare meno inappropriato il contatto tecnico, ma pure questo è in genere da scartare (può perfino essere un consulente esterno, che ha lavorato per loro in occasione della configurazione della rete e che torna solo ogni tanto); in sostanza non è da coinvolgere a meno che la rete in questione non stia provocando seri problemi tecnici. Billing contact è quello che c'entra meno di tutti, essendo solamente il destinatario a cui il registrar invia le proprie fatture per gli addebiti relativi alla registrazione del dominio.


Indice    << Precedente    Successiva >>

Ultimo aggiornamento: 05 marzo 2005

Leonardo Collinelli

e-mail