DNSjam

A little survey across the Domain Name System village. (Testo parziale vedi link a fondo pagina).

0. Introduzione

Eccoci qui. Ennesimo lunedi mattina, ennesimo casino. Della serie *ma quasi quasi stavo bene prima di ieri sera*, per gli amanti delle feste della domenica notte, per quelli che credono che oramai tutto sia quasi sistemato e invece poi in poche ore cambia tutto, e non sai piu` cosa pensare ne cosa fare, vorresti solo sprofondare nella calma del tuo CED, per quelli che si ritrovano ogni dieci secondi a pensare a certe cose che speravano di aver cancellato dalla mente e archiviato nella sezione *bei momenti passati insiseme* del proprio Castello della Memoria, per quelli che sanno cosa vuol dire quando il vento sembra soffiare sempre contro di te, per coloro che capiscono che un messaggio sul cellulare dopo una serata del genere possa essere il colpo di grazia, beh, benvenuti. Dire come mi sento ora e` davvero difficile (e probabilmente nno ve ne freghera` neanche nulla =), pero` cosi` e`, se vi pare; a tutte quelle persone che probabilmente mai leggeranno questo testo, ma che forse potranno capire cosa mi sta succedendo, beh, vi voglio bene, lo so che nno e` molto ma e` cosi` e non ci posso fare nulla, oramai. E allora cosa si puo` fare quando ci si trova in una situazione del genere? SIIIIIIIII!!!!!!!!! =) Mettersi a leggere un inutilissimo documento sul protocollo DNS e su come possa distogliere la nostra mente, magari anche solo per pochi secondi, da questo triste scenario. Quindi da parte lo sconforto e la tristezza, sguardo fisso in alto, a scrutare le stelle, memori che nel mondo il dolore deve venire superato sempre... tenendo anche conto della nuova segretaria che e` arrivata oggi... uhm... alla fine forse il mondo non e` cosi` male come poteva sembrare =D Insomma in poche parole, su con la vita, noi siamo gli immortali, e prima o poi troveremo anche noi la felicita`...

1. Cenni storici

Beh tanto per iniziare un po' di storia, anche perche` come spero abbiate immaginato non e` che di colpo e` stato Internet gia` bello e funzionante, ma il tutto si e` sviluppato piano piano fino a che fondendo le varie esperienze si e` giunti all'attuale standard, che a noi sembra normalissimo e immutabile, ma anche lui sara` destinato a scomparire ed essere sostituito da... uhm... ehm... bo, insomma da quello che inventeranno dopo :) Premetto che non tutto quello che dico non l'ho sperimentato di persona, ma l'ho letto sulle quintalate di rfc e doc che mi sono scorso nei giorni scorsi (o che mi sono passato nei giorni passati, o che mi sono letto nei giorna-letti). Quindi se non vi va bene andate a rompere a Postel e compagnia bella che io c'ho gia` i miei problemi... Lo scopo principale del protocollo DNS e` quello i permettere di identificare un determinato computer attraverso un nome, e non un IP address; i vantaggi di questo sono molteplici, in quanto e` molto piu` facile ricordarsi un hostname (ad esempio www.pornvalley.com - e chi se lo scorda =), piuttosto che 64.75.34.136, non credete? Ehi, dico a voi! Oh, chiudete subito quel browser branco di maniaci e continuate a leggere ^__^ All'inizio, quando la scimmia aveva appena iniziato a raggrupparsi in piccole comunita` e a darsi un'oraganizzazione, sorse il problema di dare un nome alle macchine in modo da poter rendere facile il loro riconoscimento all'interno di una rete e permettere operazioni di interscambio ad alto livello, come ad esempio l'invio della posta. Tra le varie proposte ce ne furono alcune che ancora sussistono, piu` o meno in disuso, come l'UUCP; fino a che le reti erano piccole e l'utenza non toccava utenti che non si possono certo definire *tecnici* (come capita ora, dopo il grande boom di internet), si poteva usare anche solo un nome associato alla macchina, senza preoccuparsi di dominio: il semplice HOST era piu` che sufficiente per permettere gli scambi in modo trasparente. Reti mitiche come ARPANET o DDN si trovarono pero` in crisi quando il numero di macchine collegate tra di loro crebbe in maniera spropositata, e Internet si trasformo` dalla rete militare che era in uno dei piu` affollati mondi internazionali di scambio. Per rendersi conto di come sia cambiato il mondo, basti pensare che nel 1987 i domini .com registrati ammontavano a poche centinaia, mentre ora sono in numero talmente elevato da avere difficolta` a registrarne uno =) Il protocollo fu introdotto nel 1984 dalla nascita di Nostro Signore, e le reti gia` esistenti iniziarono i cambiamenti necessari per l'adattamento al nuovo standard, ovviamente passando per una lunga fase di transizione. L'evoluzione sembro` soddisfare abbastanza la comunita`, e negli anni successivi si continuo` lo sviluppo lungo questa direzione, introducendo nuovi standard e implementando piano piano il sistema di risoluzione dei nomi che stiamo usando ancora oggi. Per capire quanto sia in evoluzione questo mondo, basti pensare che un'importante modifica fu fatta nel '95 per introdurre il supporto per le risorse su IPv6, protocollo che sara` fondamentale anche se solo ora la gente sta incominciando a rendersene conto: grazie alla risoluzione dei FQDNs (Full Qualified Domain Names) gli utenti un po' meno esperti (giusto per citarne qualcuno: la segretaria tettona che usa la posta, il pornografo impunito che guarda www.pornvalley.com - FERMI!!! -, la mamma della mia vicina che deve assolutamente andare sul sito dei LunaPop... :) non si accorgeranno minimamente di quale fantastica rivoluzione sia avvenuta nel mondo digitale, e valle pure a spiegare che il merito va dato al browser IPv6 e ai nuovi router della Cisco, tanto lei vede il sito dei LunaPop, e` contenta, la figlia esce la sera e siamo tutti felici - *ting* [(C) Pollon - pollon@olimpo.net ] Dopo questa tortura vediamo un po' cosa ci ha portato da ARPANET e le reti militari al sito di Cesare (che sia la sua Vespa? =).

2. Basi protocollo DNS

Il protocollo e` sostanzialmente mooolto semplice, ovviamente dopo che si e` perso il sonno per mesi interi cercando di capirlo ^__^ Pero` con questo documento spero di chiarire le idee a molta gente, anche perche` a essere sincero credo di conoscerne le basi discretamente, e in giro una delle domande piu` frequenti che mi fanno riguarda questo argomento (cosi` ora gli mando via DCC l'articolo e non rompono piu` le bolle =) Abbiamo detto lo scopo del DNS e` quello di permettere la dualita` tra IP address e hostname. In realta` questo concetto, sebbene dia un'idea molto mirata della situazione, e` molto restrittivo e non si puo` certo esaurire cosi` l'argomento. Il sistema che e` stato messo in piedi e` un gigantesco database distribuito su migliaia di macchine tutte in giro per il mondo. Scopo principale e` la risoluzione dei nomi, ma nulla ci vieta di usare il protocollo DNS per scambiarci messaggi di amore attraverso una risorsa TXT (ho sentito di gente che mandava binari interi uuencodati con questo metodo): beh, visto che purtroppo una ragazza a cui mandare i messaggi di amore non la tengo (e se ce l'avessi credo che scapperebbe se provassi a fare una cosa cosi` malata :), vediamo come e` strutturato il mondo dei DNS.

2.1. Gerarchia

Uno di concetti fondamentali che caratterizza la rete attuale a differenza di altre piu` antiche e` quella di avere una forte gerarchizzazione dei nomi. Tradotto in un linguaggio che anche |CyRaX| possa capire, il potere e` tenuto centralizzato per quanto riguarda la gestione, ma non per quanto riguarda le risorse. Tradotto in un linguaggio che anche |CyRaX| fumato e ubriaco possa capire, io comando e delego te per comandare una determinata zona che mi appartiene, e se ti va puoi delegare qualcun'altro per amministrare un'altra porzione di sottozona e cosi` via fino a che serve, se vi piace vedetela come il signore del castello con i suoi vassalli, valvassori e valvassini (Oh, a Cirooo, se non hai capito ancora, vaffanculo, te lo spiego con un disegno un'altra volta ^__^, e scusate la parolaccia). L'organizzazione delle risorse prevede un livello base, chiamato anche root, che andrebbe identificato con uno 0 pero` per esigenze grafiche la si indica comunemente (anche i programmi usano questa convenzione) con un dot (.): questa e` la root zone, ovvero chi ha il potere supremo, in quanto tutto il resto e` una *derivazione* della root. Appena sotto la root ci stanno i TLD, di cui parleremo meglio dopo, i quali non possono essere registrati a'mm'zzo ma sono stabiliti dalle autorita` competenti (che poi sarebbero la ICANN - Internet Corporation of Assigned Names and Numbers, IANA - Internet Assigned Numbers Authority e l'InterNIC). Questo livello e` il primo, e sotto questi TLD si possono registrare altri domini (che saranno quindi di secondo livello), e di solito e' a questo strato che viene permessa una registrazione agli utenti *comuni*. Prendiamo ad esempio l'host www.pornvalley.com (tanto per cambiare =), e vediamo come si scompone: innanzitutto mettiamo in forma esplicita il fatto che ci sia la root alla base di tutto, ottenendo il FQDN *www.pornvalley.com.* (e` stato aggiunto il . finale). Vediamo ora i livelli:

root: . . (TLD) 1st level: com com. 2nd level: pornvalley pornvalley.com. 3rd level: www www.pornvalley.com.

Intanto e` bene sfatare i luoghi comuni, quindi diciamo subito che il fatto di avere www davanti al dominio non vuol dire per forza che ci sia un server web in ascolto, e nemmeno che www.pornvalley.com. e pornvalley.com. siano la stessa cosa: e` semplicemente una convenzione di comodo adottata da molti il fatto che il livello piu` alto indichi il tipo i servizio che si sta offrendo (www, ftp, mail) ma nessuno ci costringe a settare i server in questa maniera. Lo schema sopraindicato significa questo: se voglio sapere qualcosa di www.pornvalley.com (chissa perche` poi :P) devo chiedere al capo del mondo (la root) di dirmi qualcosa riguardo al gradino immediatamente successivo (com), dopodiche a questo chiedo in maniera analoga informazioni su pornvalley e infine a quest'ultimo chiedo di dirmi chi e` in realta` www. In questo modo sono sicuro di arrivare dove voglio senza possibilita` di malintesi.

2.2. Top Level Domains

I TLD esistenti sono veramente molti, ma possiamo raggrupparli in 4 grandi categorie. La prima e` quella dei TLD generic, che possono essere registrati da tutti e non implicano una grande fatica a essere sistemati: qui troviamo i .COM .NET e .ORG (giusto per dire, tutto quello che riguarda i DNS non e` case sensitive, quindi www.pornvalley.com e WWW.PoRnVaLlEy.COM sono equivalenti). Inizialmente le tre tipologie avevano un significato preciso, ma poi con la grande corsa alla registrazione del dominio sono diventati quasi tutti equivalenti; nelle idee originarie i .COM erano destinati alle societa` commerciali, i .NET a quelle che si occupavano di topic relativi alla rete e .ORG per tutti le altre organizzazioni (ad esempio le non-profit). Una seconda categoria e` quella delle nazionali, identificate da un TDL di due lettere corrispondente al loro Country Code (li trovate tutti nell'ISO-3166). Spesso i NIC nazionali creano zone che specificano maggiormente il campo di interesse di un determinato dominio (co.uk -> Commercial/United Kingdom), ma ovviamente non hanno nessun potere al di fuori del loro TLD assegnato dall'autorita`. La terza categoria e` composta da domini che non sono registrabili da utenti normali, ma solo da particolari enti americani: .MIL (US military), .GOV (US governative), .EDU (US Educational - universita` e college di quattro anni di durata).L'ultima categoria riguarda due domini speciali, ovvero ARPA e INT, usati in modo temporaneo per i passaggi da reti come ARPANET o per scopi al di fuori della risoluzione dei nomi. I due domini di secondo livello IN-ADDR.ARPA. e IP6.INT. sono di notevole importanza in quanto servono per la risoluzione al contrario degli ip (rispettivamente IPv4 e IPv6). Vediamo ora uno schemino facile facile su come sia organizzato l'albero DNS con un paio di esempi:

Compreso questo il modello dei DNS dienta veramente semplice: ogni volta che vi trovate davanti a un nome, non pensate al nome come ad un'entita` unica e indivisibile, ma piuttosto disegnatevi mentalmente l'albero che dalla root porta al vostro amato sito pieno di donnine nude =) (ooh, ho detto l'albero non le donnine :D) Quando io cerco di collegarmi a www.pornvalley.com, i passi che vengono compiuti sono i seguenti (non considero eventuali query ricorsive, ma giusto il percorso logico lungo l'albero); il programa, di solito attraverso una chiamata a gethostbyname(3), richede un ip address per l'host www.pornvalley.com, e quindi, leggendo il file /etc/resolv.conf viene inoltrata al server dns una query del tipo: "dammi l'ip del sitozzo" class: "internet", e, se esistente, otteniamo una stuct contenente i dati necessari per l'inizializzazione dei socket. Ma come fa il nameserver sulla mia macchina (che non e` stato delegato per gestire la risorsa www.pornvalley.com.) a sapere dove cercare l'ip? Ecco cosa avviene: 0x00: chiediamo uno dei root-servers (che il nostro server dns ha scritti in un file), di dirci la lista dei root-servers stessi aggiornata. 0x01: al root server diciamo: voglio i dns del TLD com. 0x02: dopodiche chiede a uno di questi di dirci un server DNS che e` autorizzato a dare informazioni sul dominio pornvalley.com. 0x03: infine interroghiamo quest'ultimo per sapere l'indirizzo IPv4 (type: A) del server. Ottenuta la risposta la utilizziamo per la connessione.

Vediamo in pratica come fare usando il tool host, che viene distribuito nel package bind rilasciato dalla ISC (Internet Software Consortium) e reperibile all'url http://www.isc.org/products/BIND/. La sintassi che useremo per ora e` molto semplice: l'opzione -t specifica il tipo di risorsa richiesta, seguita dal nome e dal server DNS che vogliamo interrogare.

(chiediamo al nostro server locale di darci i nameserver (NS) autoritativi per la root-zone) [recidjvo@pkcrew:~]$ host -t NS . 127.0.0.1 Using domain server 127.0.0.1: . name server F.ROOT-SERVERS.NET . name server B.ROOT-SERVERS.NET . name server J.ROOT-SERVERS.NET . name server K.ROOT-SERVERS.NET . name server L.ROOT-SERVERS.NET . name server M.ROOT-SERVERS.NET . name server I.ROOT-SERVERS.NET . name server E.ROOT-SERVERS.NET . name server D.ROOT-SERVERS.NET . name server A.ROOT-SERVERS.NET . name server H.ROOT-SERVERS.NET . name server C.ROOT-SERVERS.NET . name server G.ROOT-SERVERS.NET

(ora chiediamo il primo livello a uno di questi) [recidjvo@pkcrew:~]$ host -t NS com. A.ROOT-SERVERS.NET. Using domain server: Name: A.ROOT-SERVERS.NET Address: 198.41.0.4 Aliases:

com name server A.GTLD-SERVERS.NET com name server G.GTLD-SERVERS.NET com name server C.GTLD-SERVERS.NET com name server I.GTLD-SERVERS.NET com name server B.GTLD-SERVERS.NET com name server D.GTLD-SERVERS.NET com name server L.GTLD-SERVERS.NET com name server F.GTLD-SERVERS.NET com name server J.GTLD-SERVERS.NET com name server K.GTLD-SERVERS.NET com name server E.GTLD-SERVERS.NET com name server M.GTLD-SERVERS.NET

(passiamo ora al secondo livello) [recidjvo@pkcrew:~]$ host -t NS pornvalley.com. A.GTLD-SERVERS.NET. Using domain server: Name: A.GTLD-SERVERS.NET Address: 192.5.6.30 Aliases:

pornvalley.com name server NS1.MYDOMAIN.COM pornvalley.com name server NS2.MYDOMAIN.COM pornvalley.com name server NS3.MYDOMAIN.COM pornvalley.com name server NS4.MYDOMAIN.COM

(ora abbiamo il nameserver autoritativo, chiediamogli l'IPv4 corrispondente a www) [recidjvo@pkcrew:~]$ host -t A www.pornvalley.com. NS1.MYDOMAIN.COM. Using domain server: Name: NS1.MYDOMAIN.COM Address: 216.34.13.236 Aliases:

www.pornvalley.com has address 64.75.34.136 [recidjvo@pkcrew:~]$

Bene, ora sappiamo che l'ip corrispondente a www.pornvalley.com. e` 64.75.34.136. Il gioco da fare e` sempre lo stesso, scalare la gerarchia risalendo piano piano di livelli e chiedendo chi e` il responsabile del livello dopo; in questa maniera i root-server non hanno *tutte* le risorse, ma solo le informazioni su chi se ne occupa, in via ricorsiva si arriva a chi le risorse le gestisce e ce le offre.

2.3. Reverse Lookup

Bene, ora abbiamo capito come funziona un DNS server quando viene interrogato per restituira un ip dato un FQDN, ma cosa succede se voglio fare il contrario? Facciamo questo esempio: io ho un ip 64.75.34.136 (indovinate un po' che sara` mai? =) e vorrei proprio sapere quale e` il nome della macchina che lo ha configurato sulla sua scheda di rete. Ecco che entra in gioco il reverse lookup, ovvero assegnare un nome ad un ip (se ci avete fatto caso, fino ad ora e` successo esattamente il contrario). Per fare cio` dobbiamo istituire un nuovo tipo di RR (Resource Record) che contenga queste informazioni, e poi trovare un modo affinche si possa procedere alla ricerca attraverso il modello di albero gerarchico che abbiamo visto caratterizzare questo protocollo. La soluzione a questo quesito e` data dall'unione di un campo PTR e di due domini speciali, IN-ADDR.ARPA (IPv4) e IP6.INT (IPv6). Vediamo come. Se non si pensasse bene a tutto quello che abbiamo detto fino ad ora, si potrebbe dire semplicemente: vabbe, io chiedo un campo PTR per l'ip 64.75.34.136 e il nameserver me lo dice... ENNO`!!! Perche` in base a cosa il server puo` dircelo? L'unica possibilita` sarebbe che ci fosse un DNS server che contenga *tutti* i campi PTR del mondo, e direi che non e` il caso, anche perche` non vorrei essere nei panni dell'amministratore di questo fantasioso server che riceverebbe al giorno milioni di richieste di modifica =) E allora perche` non usare il concetto di database distribuito che gia` stiamo implementando per la risoluzione, chiamiamola *diretta*? Ci sorge un bel dubbio anche qui: come facciamo a sapere quale DNS server e` autoritativo per un determinato ip? Uhm, ehm, err... non si puo` certo fare finta che l'ip (per ora parliamo di IPv4) sia come un dominio, perche` in questo modo si verrebbero a creare delle zone contenenti solo l'ultimo byte, che e` il meno significativo, mentre sarebbe l'ideale raggruppare i PTR su ip sequenziali, quindi probabilemnte gestiti dallo stesso mantainer. Detto questo sembra piu` che naturale la soluzione di *reversare* l'ip byte a byte, aggiungendoci in fondo l'appartenenza al dominio IN-ADDR.ARPA. Cosi`, l'ip 64.75.34.136 puo` essere facilmente raggiunto attraverso il PTR al FQDN 136.34.75.64.in-addr.arpa., e cosi` sembra che abbiamo davvero messo tutti a posto. Vorrei spendere ancora un paio di parole per spiegare a chi non fosse ancora convinto di quanto sia importante invertire l'ordine dei byte dell'ip, che altrimenti avremmo un dns che ha delegati tutti i PTR relativi agli ip che finiscono con .1, un altro con quelli che finiscono con .2, mentre ha molto piu` senso che un nameserver abbia delegato una classe A (64.in-addr.arpa), che poi a sua volta deleghi una classe B a un altro nameserver piu` localizzato (75.64.in-addr.arpa), che poi volendo puo` delegare ancora classi C (34.75.64.in-addr.arpa). In questo modo si possono raggruppare gli ip in baseai loro byte piu` significativi, e questa e` una buona cosa. Una volta che abbiamo questa zona, essa si comporta esattamente come un normale albero sotto IN-ADDR.ARPA., quindi possiamo definire i campi PTR e associarci un FQDN. Vediamo un attimo in pratica come funziona: se voglio trovare che host e` associato ad un ip, posso usare semplicemente host , pero` visto che siamo cercando di imparare diamo un occhiata a come viene trasformata la query che viene passata al server DNS. Prendiamo l'ip 64.75.34.136, invertiamo l'ordine dei byte e aggiungiamoci in fondo il dominio speciale: otteniamo quindi 136.34.75.64.in-addr.arpa., che viene processato come se fosse una normale query, quindi chiedendo prima un NS autoritativo per la zona di root, poi per la arpa, poi per la in-addr, poi per 64, poi per 75, poi per 34 e infine una query di tipo PTR per 136. Il risultato e` un FQDN (sempre che sia impostato il capo di reverse di quell'ip - e purtroppo specialmente nelle societa` nuove mi e` capitato di parlare di zona di reverse e sentirmi dire: "Ah, si`, il nostro provider vi fornisce la possibilita` di usare i nostri server DNS per la navigazione, ora le comunico gli ip" "No guardi, io vorrei la delegazione per la zona di reverse degli ip che ho acquistato..." "Ah, si`, il nostro provider vi fornisce la possibilita` di usare i nostri server DNS per la navigazione, ora le comunico gli ip" "..." e poi scoprire che neanche gli ip utilizzati dalla societa` per ospitarci i loro servizi avevano la zona di reverse impostata). "Ma e` cosi` importante questo reverse lookup?", chiederete voi. "Beh non certo importante come la risoluzione diretta, pero` si puo` rivelare molto utile in alcune occasioni." "Quali?" "Ecchepp..." =) Ad esempio e` molto utile per scoprire informazioni riguardo a chi posiede un ip o su cosa ci possa essere su una macchina, come ad esempio potrebbero fare i siti di statistiche degli accessi web a dire che si ha avuto visite da .gov e .mil se non potessero reversare gli ip dei client che si collegano? Tanti server oltre a quelli web lo fanno per inserire il risultato nei log e rendere piu` leggibile ai sysadmin quel gran burdel di cifre: il wu-ftpd lo fa, il server telnet, i pop3 e smtp piu` comuni, e, ciliegina sulla torta, I SERVER IRC =))) Perche` lo so brutti balordi che la meta` di voi stara` cercando in queste follie mentali il modo per poter avere finalmente un bel vhost da sfoggiare con gli amici, perche`, ammettiamolo, uscire con passo.le.giornate.a.guardare.tua.sorella.nella.nuova.sezione.di.pornvalley.com e` di certo meglio che un semplice numerico o un triste dialup :( E allora, bimbi miei, ecco qui la guida completa al tamarro della chat, l'uomo con il vhost d'oro... eheheh =) Punto primo: rassegnatevi. Per poter avere un vhost che venga accettato dai server irc bisogna avere non pochi requisiti, che passo ad illustrare: il vostro ip, interrogato secondo il metodo dei PTR, deve riportare un certo FQDN, il quale a sua volta interrogato per una risorsa tipo A deve rispondere con lo *stesso* ip che avete usato per il collegamento. In poche parole dovete avere la delegazione sia della zona diretta dei vhost che volete usare sia della zona di reverse relativa al vostro ip, cosa che con le dialup non capita mai. Punto secondo: poteva sembrare una cosa da lameri invece puo` essere istruttiva. Questo esempio l`ho messo apposta anche perche` possiamo trarne delle conclusioni molto importanti: non e` per nulla vero che un ip e un host siano associati alla stessa maniera per quanto riguarda diretto e reverse, volendo io potrei mettere come PTR al mio ip guarda.che.se.mi.inkazzo.vengo.li (non mi ricordo chi era che l'aveva fatto, pero` e` troppo bello =), anche se io non ho mai comperato il dominio vengo.li. Semplicemente la query per il PTR riporta il contenuto che IO ho messo nel database, e a nessuno importa se io non ho comprato il dominio, ma solo che il mio nameserver sia autoritativo per la mia zona di reverse lookup. Allo stesso modo posso far puntare un qualsiasi host del mio dominio a una macchina che non amministro io, quindi teoricamente the.usa.president.always.visit.pornvalley.com potrebbe puntare allo stesso ip del webserver che ospita www.whitehouse.gov (ATTENTI!!! www.whitehuose.gov e` il sito della Casa Bianca, mentre www.whitehouse.com e` un sito porno ^__^ Ma a che punto siamo arrivati... :) l processo che compiono i server IRC serve quindi ad evitare che si possa mettere qualsiasi dominio solo avendo la zona di reverse e non quella diretta, infatti nel caso il doppio controllo fallisse verremmo ammessi solo con l'ip numerico. Per quanto riguarda la zona di reverse IPv6, il concetto piu` o meno e` lo stesso: al posto della IN-ADDR.ARPA. si usa la IP6.INT., la risorsa PTR e` la stessa, ma il modo di reversare l'ip non e` cosi` immediato: esso viene reversato anche lui byte a byte con un punto tra un campo e` il successivo, ma bisogna stare attenti quando l'IPv6 e` scritto in forma contratta, perche` vanno riempiti tutti gli zeri necessari.

Per leggere il testo completo: Fonte: http://www.inventati.info/pub/howto/dnsjam.txt

t.R.

-- tHE rECIdjVO - recidjvo@pkcrew.org Member of the Packet Knights http://www.pkcrew.org/ .

Questo lavoro è sotto la licenza Creative Commons License.

Aggiungi un Sito
Gjlg - Metamotore, Gjlg Metasearch