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. La consuetudine è di scrivere i 4 numeri separati da punti, senza spazi. Per esempio:

10111100000000010001110001001111

corrisponde a 188.1.28.79

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

Già che stiamo parlando di url strane, vediamo cosa significherebbe trovare una url del tipo http://356276@202818865/abcd/def.htm
La parte prima della chiocciola (il 356276) è l'informazione di autenticazione, mentre l'host viene indicato dalla parte che segue la chiocciola (il 202818865, che corrisponde a 12.22.197.49). Succede spesso che gli spammer indichino i loro siti con queste notazioni: i browser li risolvono senza problemi e, nella speranza degli spammer, la formulazione insolita confonde molte loro vittime, rendendo difficile individuare dove effettivamente risieda il sito. Un ulteriore trucco talvolta usato dagli spammer per intorbidare le acque è di inserire, in queste url, anche degli encoding. Per esempio:
http://356276@202818865/abcd/def.htm
si potrebbe trovare indicato anche con questa notazione del tutto equivalente:
http://3%3562%376@20%3281%3886%35/%61%62c%64/def.htm
(ma adesso che lo sapete, non ci cascherete).

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 188.1.28.79 e 188.1.28.80 sono consecutivi, mentre 188.1.28.79 e 189.1.28.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 connesse a 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. Come facilmente immaginabile, gli indirizzi non vengono attribuiti a caso ma per intervalli. A seconda della dimensione dell'intervallo di indirizzi assegnato 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.

Potete verificarlo facilmente 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.

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.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

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. Anche un nome di dominio come verycool.com ha un sapore decisamente beffardo. 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.DEJANEWS.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) 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. A questo punto il server del mio provider va in pellegrinaggio da quello responsabile per il dominio .COM e gli passa la richiesta. In risposta otterrà l'indirizzo di un ulteriore server, responsabile per DEJANEWS.COM, al quale dovrà rivolgersi. Da quest'ultima interrogazione otterrà finalmente l'indirizzo del computer WWW.DEJANEWS.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, 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 del DNS potrebbe avere inserito 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, è attualmente 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) è competente Network Solutions (ex InterNic).

Quindi Network Solutions 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, in modo che, scrivendo a nomecasella@xyz.com, si possa convertire questa notazione in nomecasella@pop.xyz.com.

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. Considerato che la maggior parte dello spam arriva dal Nordamerica, teniamo presenti soprattutto:

Per le assegnazioni riguardanti altre parti del mondo le autorità saranno altre. Per esempio RIPE per gli indirizzi in Europa, l'APNIC per quelli in Asia, NIC per i nomi di dominio in Italia ecc... A necessità non avrete problemi a trovarli. Comunque, dalla mia esperienza vedo che la quasi totalità dei casi richiede di usare i due servizi indicati.

Se disponiamo di un indirizzo numerico, scopriremo a chi appartiene dal whois dell'ARIN. La pagina presenta un campo di input in cui si digita l'indirizzo, si preme il bottone apposito (o si dà invio se il bottone manca) e si ha la risposta dopo pochi istanti:

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 viene fatta 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 alla MCI. Per avere informazione più specifica si può ripetere la 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 Network Solutions 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 Network Solutions invia le proprie fatture per gli addebiti relativi alla registrazione del dominio.


Leonardo Collinelli

Indice Precedente Successiva

Ultimo aggiornamento: 06 agosto 1999