Copy Link
Add to Bookmark
Report
BFi numero 10 anno 4 file 18 di 18
==============================================================================
-----------[ BFi numero 10, anno 4 - 30/09/2001 - file 18 di 18 ]-------------
==============================================================================
-[ MiSCELLANE0US ]------------------------------------------------------------
---[ DNS JAM
-----[ tHE rECIdjVO
____ _ __ _____
| \ | \ | | / ____| ###################################
| \ | \ | | | |___ ______ ___ ____ ____
| | | | | \____ \ |_ _| / _ \ | _ \/ _ |
| | | |\ | /\____| | | | | |_| |_ | | | | | |
|_______/ |__| \___| \_______/ | | \_____/\_| |__| |__| |__|
/ |
################################# |___/ ############################
| |
| DNSjam - A little survey across the Domain Name System village |
| |
| by tHE rECIdjVO - recidjvo@pkcrew.org |
| Member of the Packet Knights |
| http://www.pkcrew.org/ |
| |
| - June, 2001 |
| |
#####################################################################
o 0. Introduzione
o 1. Cenni storici
o 2. Basi protocollo DNS
2.1. Gerarchia
2.2. Top Level Domains
2.3. Reverse Lookup
o 3. RRs (Resource Records)
o 4. Implementazioni del protocollo
4.1. gethostbyname()
4.2. getaddrinfo()
o 5. Struttura di un pacchetto DNS (utilizzando il protocollo UDP)
o 6. Software di analisi DNS (la pappa e` prontaaa)
6.1. host
6.2. dig
o 7. DNS e Whois
o 8. Future
8.1. Nuovi organismi e TLD
8.2. Futuro del protocollo
o 9. Resources
9.1. RFCs
9.2. URLs
9.3. HOWTOs
9.4. Books
9.5. About the Author
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 insieme* 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 non 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 non 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 sia 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... boh, insomma da quello che inventeranno dopo :)
Premetto che non tutto quello che dico 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 di permettere di identificare
un determinato computer attraverso un nome, e non un IP address; i vantaggi
che questo comporta 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'organizzazione, 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 del 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 che 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 di 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 tutte le altre organizzazioni (ad esempio le non-profit).
Una seconda categoria e` quella delle nazionali, identificate da un TLD 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:
/--------------\
| root |
\--------------/
|
/-----------------------------------------------------------------------\
| | | | | | | | | |
/-----\ /-----\ /-----\ /-----\ /-----\ /-----\ /------\ /-----\ /----\ /-----\
| com | | net | | org | | mil | | edu | | gov | | arpa | | int | | it | | ... |
\-----/ \-----/ \-----/ \-----/ \-----/ \-----/ \------/ \-----/ \----/ \-----/
| | |
\------------\ \-----------------\ |
| | |
/------------\ /--------\ /-----\
| pornvalley | | pkcrew | | ip6 |
\------------/ \--------/ \-----/
| |
/-----\ /-----------\
| www | | tiatunnel |
\-----/ \-----------/
Compreso questo il modello dei DNS diventa 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 programma, di solito attraverso una
chiamata a gethostbyname(3), richiede 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 struct 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 a 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 livello 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 e 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 restituire 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
tutto 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
base ai 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
stiamo 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 campo 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.visits.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... :)
Il 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: 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.
Esempio:
3ffe:1001:280::1 ==
== 3ffe:1001:0280:0000:0000:0000:0000:0001 ==
== 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.0.1.0.0.1.e.f.f.3.ip6.int.
Proviamo ora con il nostro amico host:
[recidjvo@pkcrew:~]$ host -t NS arpa. A.ROOT-SERVERS.NET.
Using domain server:
Name: A.ROOT-SERVERS.NET
Address: 198.41.0.4
Aliases:
arpa name server A.ROOT-SERVERS.NET
arpa name server H.ROOT-SERVERS.NET
arpa name server C.ROOT-SERVERS.NET
arpa name server G.ROOT-SERVERS.NET
arpa name server F.ROOT-SERVERS.NET
arpa name server B.ROOT-SERVERS.NET
arpa name server I.ROOT-SERVERS.NET
arpa name server E.ROOT-SERVERS.NET
arpa name server D.ROOT-SERVERS.NET
[recidjvo@pkcrew:~]$ host -t NS in-addr.arpa. A.ROOT-SERVERS.NET.
Using domain server:
Name: A.ROOT-SERVERS.NET
Address: 198.41.0.4
Aliases:
in-addr.arpa name server A.ROOT-SERVERS.NET
in-addr.arpa name server H.ROOT-SERVERS.NET
in-addr.arpa name server B.ROOT-SERVERS.NET
in-addr.arpa name server C.ROOT-SERVERS.NET
in-addr.arpa name server D.ROOT-SERVERS.NET
in-addr.arpa name server E.ROOT-SERVERS.NET
in-addr.arpa name server I.ROOT-SERVERS.NET
in-addr.arpa name server F.ROOT-SERVERS.NET
in-addr.arpa name server G.ROOT-SERVERS.NET
[recidjvo@pkcrew:~]$ host -t NS 64.in-addr.arpa. A.ROOT-SERVERS.NET.
Using domain server:
Name: A.ROOT-SERVERS.NET
Address: 198.41.0.4
Aliases:
[recidjvo@pkcrew:~]$ host -t NS 75.64.in-addr.arpa. A.ROOT-SERVERS.NET.
Using domain server:
Name: A.ROOT-SERVERS.NET
Address: 198.41.0.4
Aliases:
[recidjvo@pkcrew:~]$ host -t NS 34.75.64.in-addr.arpa. A.ROOT-SERVERS.NET.
Using domain server:
Name: A.ROOT-SERVERS.NET
Address: 198.41.0.4
Aliases:
34.75.64.in-addr.arpa name server NS.EXODUS.NET
34.75.64.in-addr.arpa name server NS2.EXODUS.NET
[recidjvo@pkcrew:~]$ host -t PTR 136.34.75.64.in-addr.arpa. NS.EXODUS.NET.
Using domain server:
Name: NS.EXODUS.NET
Address: 206.79.230.10
Aliases:
136.34.75.64.in-addr.arpa domain name pointer redirect.dnsix.com
Perche` non abbiamo avuto risposta per alcune delle query fatte? Anche se a
prima vista puo` sembrare un errore, e` giusto cosi`.
Infatti la classe 64, pur essendo una classe A, ha la zona di reverse
impostata direttamente sui primi tre byte, quindi evita passaggi successivi
attraverso altri nameserver.
E poi al contrario:
[...] (salto la procedura per trovare il NS autoritativo)
[recidjvo@pkcrew:~]$ host -t A redirect.dnsix.com. NS1.MYDOMAIN.COM.
Using domain server:
Name: NS1.MYDOMAIN.COM
Address: 216.34.13.236
Aliases:
redirect.dnsix.com has address 64.75.34.136
Ovviamente tutti questi esempi che abbiamo visto sono a scopo didattico, non
vi sognate mai di fare tutte le query (a meno che non vi interessi sapere
informazioni del tipo societa` incorporate o simili): basta fare la query al
nameserver predefinito e poi ci pensa lui a fare il resto, portando
direttamente a casa il risultato finale. Pero`, come dice sempre Ciro:
"[biiip], lo so che c'e` un modo piu` facile automatico di farlo ma a me va di
fare cosi`", quindi fanculo se vi sembra che abbiamo perso solo tempo, e
scusate ancora la parolaccia =)
3. RRs (Resource Records)
Vediamo ora i principali tipi di risorse che si possono ottenere da un server
DNS.
Come abbiamo visto, anche se apparentemente l'unico campo che potrebbe
interessare sarebbe quello A (address), molti altri sono importantissimi (NS,
PTR): vediamone un tot, indicando di fianco il relativo codice (i type delle
query saranno ripresi nella sezione dell'implementazione di un pacchetto DNS):
0x01: A IPv4 Address Questa risorsa contiene l'ip
corrispondente a un FQDN.
0x02: NS NameServer Nameserver autoritativo per la
determinata zona.
0x05: CNAME Canonical Name Un nickname per un altro host.
0x06: SOA Start Of Authority Dati relativi alla gestione della zona.
0x0c: PTR Pointer FQDN per il reverse lookup.
0x0d: HINFO Host Info Informazioni sulla macchina.
0x0f: MX Mail Exchanger Nome del server gestore della posta.
0x10: TXT Text Info Descrizione della zona.
0x1c: AAAA IPv6 Address Risorsa duale a A per indirizzi IPv6.
0xfc: AXFR Zone Transfer Richiesta di trasferimeto zona.
0xff: ANY All records Richiesta per tutti i RR disponibili.
Per capire come vanno impostate le risorse, potete rifarvi all'ottimo manuale
del bind e all'HOWTO, comunque sono molto semplici: il SOA definisce cose
come il responsabile (email) della zona, i tempi di caching delle risposte e
il serial dell'ultima modifica.
Il campo CNAME invece serve per poter deinire degli alias di un host; in
questo modo, ci comportiamo similmente a una risorsa A, pero` al posto
dell'IPv4 ci mettiamo un altro hostname, il quale a sua volta dovra` prima o
poi risolversi in un campo A. Questo serve ad esempio nel caso il nostro
webserver abbia 1984 virtualhost che puntano sul suo ip: nel momento in cui ci
vediamo costretti a cambiare ip al webserver, dovremmo aggiornare 1984 campi A
probabilmente in 1984 file di configurazione diversa... Non un bel lavoro! In
questo modo invece se noi definiamo i vhost con un CNAME su webserver, ci
bastera` modificare l'IPv4 di quest'ultimo e automaticamente anche tutti gli
altri verranno aggiornati =)
L'unica limitazione e` che alcuni campi (come quelli NS o MX), non possono
essere associati a un host definito da un CNAME, ma da un campo A.
Giusto per tenerci in allenamento, vediamo come funziona il nostro software di
invio mail quando cerchiamo di spedire una mail a bfi@s0ftpj.org .
Per prima cosa cerchiamo chi e` il server di posta per il dominio s0ftpj.org,
dopodiche` tenteremo di collegarci alla sua porta SMTP (25/tcp) e inviare una
mail all'utente.
[...] (saltiamo ancora la ricerca del namserver autoritativo per s0ftpj.org)
[recidjvo@pkcrew.org:~]$ host -t MX s0ftpj.org NS1.ANDREAMONTI.NET.
Using domain server:
Name: NS1.ANDREAMONTI.NET
Address: 151.39.115.130
Aliases:
s0ftpj.org mail is handled (pri=100) by mail.olografix.org
Il numero 100 che otteniamo e` la priorita` del mail exchanger, nel caso
esistessero piu` server viene provato per primo quello con priorita` piu`
bassa e via crescendo.
L'opzione -v del comando host visualizza anche le informazioni relative
all'host ritornato come risultato della query MX, ovvero un RR di tipo A su
mail.olografix.org.
Come vedete quindi, il server di posta non deve essere per forza con il
dominio associato alle caselle che contiene, basta che sia definito come MX
nel file di configurazione del dominio.
Ci sono molti altri RR possibili, anche se non sono quasi mai usati. Diciamo
che, come spiegato all'inizio, il sistema DNS non e` altro che un immenso
database gerarchico distribuito, quindi possiamo usarlo per scambiare
tantissimi tipi di informazione.
Ma la domanda che ci sorge e`: vogliamo davvero usare tipi di risorse come le
YellowPages per indicare quali sono le wellknown-service ports su una
macchina? Le possibilita` di utilizzo sono tantissime, potete rifarvi agli
rfc per conoscerle, ma quelle che potete trovare in giro sono quelle
illustrate fino ad ora, ma davvero troveremo mai in giro un RR del tipo
TELNET.TCP-port.Number.YP.? Spero di no, altrimenti vuol dire che ci sono
davvero sistemisti che hanno meno idee di me su come passare il tempo in
ufficio, eheheh =)
4. Implementazioni del protocollo
Il protocollo DNS puo` venire implementato in due livelli: il primo, che e`
quello piu` classico e che normalmente dobbiamo usare quando progettiamo del
software di rete, e` l'utilizzo delle API per risolvere i nomi e poter cosi`
creare connessioni tramite socket conoscendo non l'ip address, ma il FQDN
degli endpoint.
Principalemente le query DNS viaggiano su UDP, ma c'e` anche la possibilita`
di avere delle risposte tramite query che utilizzano TCP, anche se i
datagrammi sono preferiti nelle occasioni comuni.
Principalemente ci sono due interfacce alla risoluzione dei nomi offerte per
gli sviluppatori c, vediamole brevemente:
4.1. gethostbyname()
gethostbyname(3): contiene principalmente gethostbyname(), gethostbyname2(),
gethostbyaddr(), sethostent(), endhostent().
La prima funzione serve per risolvere gli host verso i loro IPv4 address, la
gethostbyname2() permette di specificare anche la famiglia del risultato (ad
esempio AF_INET6 per gli indirizzi IPv6), la gethostbyaddr() viene utilizzata
per fare il reverse lookup, mentre la sethostent() e endhostent() servono per
gestire le connessioni nel momento in cui si decida di forzare il protocollo
TCP per l'interrogazione dei nameserver.
Vediamo ora un esempio classico di procedura che, dato un host, restituisce il
suo ip address, ma prima diamo un'occhiata al tipo di struttura ritornata da
quasi tutte le funzioni precedenti, ovvero la struct hostent (dal file
):
/* Description of data base entry for a single host. */
struct hostent
{
char *h_name; /* Official name of host. */
char **h_aliases; /* Alias list. */
int h_addrtype; /* Host address type. */
int h_length; /* Length of address. */
char **h_addr_list; /* List of addresses from name server. */
#define h_addr h_addr_list[0] /* Address, for backward compatibility. */
};
I campi che piu` ci stanno a cuore sono gli ultimi due, che tanto come vedete
sono molto simili, in quanto l'ultimo e` solamente un define sul primo
elemento della lista precedente.
Quindi il nostro IPv4, se esistente, lo troveremo li`, ovviamente gia` in
forma utilizzabile da una struttura in_addr e non nella forma dotted decimal
:)
Ecco qui il codice di una semplice procedura di risoluzione dei nomi, con la
relativa chiamata per riempire il campo s_addr (la funzione e` una versione
leggermente modificata di quella che uso di solito nei mie stupidi programmi,
si potrebbe modificare per ottenere molte piu` informazioni e gestire in modo
trasparente alla chiamata la risoluzione IPv6 o il riconoscimento di ip
numerici che non necessitano di nessuna risoluzione, ma credo che sia meglio
dividere gli ambiti per evitare confusioni).
int resolv4(char *hostname, struct sockaddr_in *saddr)
{
struct hostent *host_data;
// Query nameserver for hostname
if((host_data = gethostbyname(hostname)) == NULL) {
herror("resolv4");
return(-1);
}
// Fill the s_addr field
memcpy(&saddr->sin_addr.s_addr, host_data->h_addr_list[0], host_data->h_length);
return(0);
}
In questo esempio abbiamo inserito anche la funzione herror(), che serve ad
avere informazioni riguardo all'eventuale errore che si e` verificato;
potremmo ad esempio ottenere:
resolv4: Host name lookup failure
nel caso non fosse possibile ricavare l'ip.
Una lista completa di questi comandi si trova nella manpage del comando
gethostbyname(3).
Siccome questa non vuole essere in nessun modo una guida sull'utilizzo delle
API per i socket BSD, tralascero` l'invocazione, dato che mi sembra del tutto
ovvia, o l'utilizzo della inet_addr(3) nel caso si passasse un ip in dotted
decimal. Ricordate giusto che l'unico include aggiuntivo per queste funzioni
di libreria e` .
4.2. getaddrinfo()
L'utilizzo della getaddrinfo(3) serve per richiedere delle risoluzioni
indipendentemente dal protocollo utilizzato, ritornando molte piu`
informazioni della tradizionale gethostbyname(3), e oscurando in parte
l'utilizzo della gethostbyname2(3) per la risoluzione di protocolli
alternativi alla famiglia AF_INET.
Personalmente ho usato con successo la getaddrinfo(3) per la risoluzione degli
hostname appartenenti alla famiglia AF_INET6 (IPv6), quindi proporro` un
esempio di risoluzione su tale traccia, lasciando al lettore curioso e
intraprendente il compito di leggersi manpage e sorgenti per capire meglio
come funziona il tutto (seee, non so se trovero` mai qualcuno con cosi` tanta
buona volonta`, e soprattutto tempo da perdere =).
Prima di poter chiamare la funzione bisogna inizializzare delle variabili da
passare come parametri per una buona riuscita della risoluzione: entra quindi
in gioco la struct addrinfo: vediamola.
/* Structure to contain information about address of a service provider. */
struct addrinfo
{
int ai_flags; /* Input flags. */
int ai_family; /* Protocol family for socket. */
int ai_socktype; /* Socket type. */
int ai_protocol; /* Protocol for socket. */
int ai_addrlen; /* Length of socket address. */
struct sockaddr *ai_addr; /* Socket address for socket. */
char *ai_canonname; /* Canonical name for service location. */
struct addrinfo *ai_next; /* Pointer to next in list. */
};
Questo e` invece e` il prototipo della funzione getaddrinfo(3):
int getaddrinfo(const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res);
nodename e` il nostro host da risolvere (da notare che in questo caso puo`
essere anche un dotted decimal ip, ci pensa la funzione stessa a rendersene
conto), servname lo inizializziamo a NULL, e poi riempiamo le due strutture
addrinfo: la prima (hints) contiene una *maschera* rispetto alla quale
verranno richieste le RR corrispondenti (possiamo forzare che l'ip sia IPv6 e
non IPv4 ad esempio), mentre res e` una lista di risorse che ci vengono
restituite dalla funzione.
Vediamo ora un esempio, cosi' si capisce meglio; la seguente funzione riempie
una struttura in6_addr con il risultato della risoluzione di un host verso il
suo IPv6.
int resolv6(char *hostname, struct sockaddr_in6 *saddr6)
{
struct addrinfo *iaddr = NULL, imatch;
char *paddr;
int ret;
// Specify IPv6 request
bzero(&imatch, sizeof(imatch));
imatch.ai_family = AF_INET6;
// Get info
if((ret = getaddrinfo(hostname, NULL, &imatch, &iaddr)) == 0) {
paddr = (char *)malloc(iaddr->ai_addrlen);
memcpy(paddr, iaddr->ai_addr, iaddr->ai_addrlen);
freeaddrinfo(iaddr);
// Fill the sin6_addr field
memcpy(&saddr6->sin6_addr, &((struct sockaddr_in6 *)paddr)->sin6_addr, (size_t)sizeof(struct in6_addr));
free(paddr);
return(0);
}
fprintf(stderr, "resolv6: %s\n", gai_strerror(ret));
return(-1);
}
Le uniche funzioni che non ho spiegato sono la freeaddrinfo(3), che non fa
altro che liberare le risorse delle strutture allocate dalla getaddrinfo(3),
e la gai_strerror(3) che aiuta la comprensione degli eventuali errori che si
verificano durante la procedura.
5. Struttura di un pacchetto DNS (utilizzando il protocollo UDP)
Le interfacce API forniscono un buon livello di flessibilita` per quello che
riguarda la programmazione comune, ma come e` strutturato un pacchetto DNS
nel suo profondo? Visto che oramai ci siamo vediamo un po' in dettaglio i
campi che compongono la sua struttura e come sia possibile attraverso
l'utilizzo dei socket di tipo SOCK_RAW creare query e answer DNS compatibili
con lo standard prescritto.
A questo punto, nonostante abbia perso un paio di mesi a studiarlo e a cercare
di scrivere un programma che funzionasse (e che se faccio a tempo e non esce
proprio una pirlata, scusate tanto la parolaccia, troverete prima o poi in
giro), mi armo dello Stevens (per chi non lo conoscesse, e` il famoso TCP/IP
Illustrated che trovate in fondo nelle references) e iniziamo... uhm, ehm,
err... si` asynchro lo so che e` tuo e sono mesi che dovrei restituirtelo, ma
e` cosi` bello che non voglio separarmene =) Dai, pazienta ancora poco che non
so come ma ho convinto il braccine corte del mio capo a finanziarmi l'acquisto
di un po' di materiale cartaceo... speriamo che non cambi idea, eheheh... ^_^;
a proposito, non e` che avresti anche il volume 2 da prestarmi? :D
La struttura del pacchetto DNS e` ovviamente composta dai due header standard
(quello IP e quello UDP, ma e` anche fornito di un suo header particolare, che
possiamo trovare nel file di include e si chiama, tanto per
essere originali e univoci, HEADER. Eccolo qui come si presenta nella sua
struttura standard (BYTE_ORDER == BIG_ENDIAN):
typedef struct {
unsigned id :16; /* query identification number */
/* fields in third byte */
unsigned qr: 1; /* response flag */
unsigned opcode: 4; /* purpose of message */
unsigned aa: 1; /* authoritative answer */
unsigned tc: 1; /* truncated message */
unsigned rd: 1; /* recursion desired */
/* fields in fourth byte */
unsigned ra: 1; /* recursion available */
unsigned unused :1; /* unused bits (MBZ as of 4.9.3a3) */
unsigned ad: 1; /* authentic data from named */
unsigned cd: 1; /* checking disabled by resolver */
unsigned rcode :4; /* response code */
/* remaining bytes */
unsigned qdcount :16; /* number of question entries */
unsigned ancount :16; /* number of answer entries */
unsigned nscount :16; /* number of authority entries */
unsigned arcount :16; /* number of resource entries */
} HEADER;
(Per chi non fosse molto pratico di c, i membri della struct possono avere
dimensioni predefinite con precisione di bit, specificate dopo i ':', quindi
unsigned id :16 significa che il campo id e` un intero senza segno di
dimensioni 16 bit -> 2 byte).
Come si nota subito la struct si puo` dividere in sei sottozone di 16 bit
ciascuna, per un totale di 12 byte; la prima e` l'id, ovvero un numero
casuale che identifica il codice della transazione per impedire promiscuita`
con altre richieste fatte contemporaneamente (e soprattutto per difendersi da
un blind spoofing, che nel caso del protocollo UDP e` facilitato in mancanza
del seq tipico del protocollo TCP).
La seconda coppia di byte e` quella delle flags: la analizzeremo meglio in
seguito.
Le altre quattro sono destinate a contenere il numero di domande contenute in
una query, le risposte ritornate nel caso il datagramma sia una risposta,
quante di queste sono autoritative (ovvero il server e` perlomeno convinto di
gestirle lui), e il numero di risorse aggiuntive presenti.
Graficamente l'header del DNS risulta circa cosi`:
0 15 16 31
|------------------------------|------------------------------|
| ID | flags |
|------------------------------|------------------------------|
| numero delle richieste | numero delle risposte |
|------------------------------|------------------------------|
| numero delle autoritative | numero delle addizzionali |
|------------------------------|------------------------------|
Vediamo ora i due byte delle flags come sono suddivisi:
0 15
|----|----------------|----|----|----|----|------------|----------------|
| QR | opcode | AA | TC | RD | RA | zero | rcode |
|----|----------------|----|----|----|----|------------|----------------|
1 4 1 1 1 1 3 4
QR: impostato a 0 per le query, a 1 per le risposte
opcode: generalmente 0 (standard query) o 1 (inversa)
AA: se impostato a 1 dichiara l'autoritativita` della risposta
TC: risposta troncata (superiore ai 512 byte UDP)
RD: richiesta di una query ricorsiva (se posto a 0 e` iterativa)
RA: se a 1 il server supporta le query ricorsive
zero: bit impostati a 0 (non sono utilizzati)
rcode: return code (0 significa nessun errore)
Appena dopo l'header del pacchetto DNS troviamo le risorse vere e proprie, che
nel caso di una query conterranno i dati per i quali si richiede l'intervento
del nameserver, o, nel caso di risposta, ci troveremo i valori ricercati dal
client.
Ecco come si presenta la richesta di una query.
In testa alla RR troviamo il nome della risorsa richiesta, codificata nel
seguente modo: ogni livello del dominio richiesto e` preceduto dal numero dei
byte rappresentativi della sua lunghezza, e sono aboliti i punti; il tutto e`
terminato da uno 0. Nel caso la query sia molto lunga, e` possibile ricorrere
a uno schema di compressione, che pero` non verra` analizzato in questo
documento.
Vediamo un esempio che e` meglio, eh? =) Ecco come verrebbe trasformato
bradipo.cds.lan.pkcrew.org:
b r a d i p o . c d s . l a n . p k c r e w .o r g
7 b r a d i p o 3 c d s 3 l a n 6 p k c r e w 3 o r g 0
Ovviamente i numeri non sono intesi come carattere ASCII corrispondente, ma
come valore effettivo.
Appena dopo troviamo altri dati riguardanti la richiesta: 2 byte di query type
(i valori riportati nel capitolo 3), e altri 2 byte di query class (IN, CHAOS,
ecc...).
Si complica invece un po' la storia quando si parla di risposte. Ecco come
appaiono: all'inizio riportano la query a cui stanno rispondendo, dopo 2 byte
di TTL (quanto tempo rimarra` in cache la risposta), 1 byte indicante la
lunghezza della risposta, e infine la risposta vera e propria (ad esempio
quattro byte per una richiesta di risoluzione IPv4).
Questo e` quanto.
6. Software di analisi DNS (la pappa e` prontaaa)
Per chi non avesse voglia di scriversi il suo client di interrogazione dei
nameserver (eheheh vorrei ben vedere...), introduciamo ora veramente in modo
superficiale (leggetevi le pagine man, fate prima =) due dei piu` comuni
strumenti, utilissimi in molti casi: host(1) e dig(1).
Ci sono anche altri tool, come ad esempio dnsquery(1) e nslookup(8) (il primo
e` stato il mio *primo* tool di analisi DNS, bei ricordi :~~~ - il secondo a
mio avviso e` brutto, ma brutto brutto!!! =)
6.1. host
Questo e` un ottimo strumento, e l'ho preferito di gran lunga ad altri (come
ad esempio nslookup, che si trova anche sotto WinNT4 e 5): attualmente lo uso
per soddisfare tutti i miei bisogni (non pensate male, intendo i bisogni
riguardanti il protocollo :P).
Vediamo ora la sintassi con i principali parametri:
host [-t ] [-c ] domain [nameserver]
Il parametro -t, che abbiamo visto anche prima, serve per definire il tipo di
RR che desideriamo (A, NS, ecc...), mentre il -c e` veramente poco usato
(l'unica volta che l'ho usato e` stato giusto ora per provarlo :), perche` le
classi di richiesta sono sempre di tipo IN, e l'unico vero bisogno di un
utente comune al di fuori di questa classe e` sapere la versione del server,
per la quale normalmente uso dig(1).
Una feature carina di host(1) e` che se gli viene passato come indirizzo un
ip esegue automaticamente il reverse lookup, senza perdere tempo a reversare
i byte e aggiungerci in fondo il dominio, in-addr.arpa. o ip6.int. che sia.
Il dominio e` quello che dobbiamo risolvere, eventualmente chiuso dal ., per
evitare che si faccia path searching.
Infatti se non viene specificato un nameserver al quale fare la richiesta,
host analizza il file /etc/resolv.conf, leggendo li` i nomi dei DNS server, o
servendosi del file /etc/hosts nel caso ci sia un'entry corrispondente; nel
file /etc/resolv.conf puo` essere specificata anche una riga search, seguita
da uno o piu` domini, che viene utilizzata per *combinare* il dominio passato
come parametro a host, aggiungendoci in fondo i domini specificati dal file e
provando a risolverli.
Questo e` fatto perche`, ad esempio in una grossa lan dove le macchine si
chiamano recidjvo.salalettura.lan.pkcrew.org.,
cyrax.saladroga.lan.pkcrew.org., specificando lan.pkcrew.org. sara`
sufficiente usare recidjvo.salalettura o cyrax.saladroga (notare l'omissione
del punto finale) per ricevere la risposta voluta.
Un altro parametro molto comodo e` il -v, che permette un output molto piu`
esauriente e fornisce gli ip degli indirizzi contenuti nelle risposte.
Piu` tardi quando parleremo di zone transfer analizzeremo i parametri -a
(equivalente a -t ANY, e -l).
6.2. dig
dig(1), a essere sincero, lo uso solo in due occasioni, ovvero scoprire le
versioni dei server DNS (ad esempio per controllare di aver modificato il
reply), e per trovare gli indirizzi dei root-servers.
Come strumento di interrogazione e` sicuramente un po' piu` approfondito di
host(1), pero` a meno che non ci vogliamo proprio impuntare, non vale la pena
di usarlo; il funzionamento e` molto simile, e di default visualizza ad
esempio informazioni sugli header della risposta (ottenibile comunque anche
con la flag -d di host(1)).
Direi che visto il fatto che non sto a fare una manpage per questi comandi,
scrivero` solo le due sintassi:
dig (per la lista dei root-servers)
dig version.bind chaos txt @nameserver (per ottenere la versione)
Giusto per far capire, le righe sopra sono equivalenti a:
host -t NS . -v -d
host -t TXT -c CHAOS version.bind localhost -v -d
Entrambi i pacchetti li trovate nel bind distribuito dalla ISC all'url
http://www.isc.org/.
7. DNS e Whois
Bene bene bene :)
Questa in teoria dovrebbe essere la parte piu` divertente, anche perche` in
fin dei conti chi se ne sbatte di saper forgiare un pacchetto DNS? (purtroppo
devo rispondere "IO!", ma questo per colpa della mia insanita` mentale...),
ovvero quella che riguarda la ricerca di informazioni su un determinato nodo
della nostra mamma rete: ad esempio vogliamo sapere chi e` lo $*@`#?=* che ha
osato farci un portscan, oppure vogliamo sapere chi c'e` dietro a un
determinato sito che appreziamo tanto (ehhh, chissa` come mai, ma una mezza
idea su quale sia ce l'ho :).
Bene. Armiamoci di buona volonta` e iniziamo a fare le nostre belle
ricerchine.
Per fare cio` ci torna molto utile il protocollo DNS, anche perche` spesso
questi *nodi* sono identificati da un ip, opure un hostname, da un dominio di
posta... Insomma da qualcosa che sia riconducibile al nostro bel database
distribuito.
Un altro protocollo che in questi casi ci e` davvero molto utile e` quello
Whois, che si avvicina molto al mondo del DNS: esso contiene tutte le
informazioni riguardanti la registrazione dei domini e dei server DNS, quindi
questi due strumenti uniti possono rivelarsi un buon inizio per avere le idee
un po' piu` chiare su cosa stiamo cercando.
Il server Whois, a differenza del server DNS, contiene anche informazioni su
persone e luoghi, numeri di telefono e email, quindi permette un'analisi
approfondita del nostro target.
Facciamo un esempio pratico di Whois: cambiamo un po', anche perche` oramai
l'admin di pornvalley.com ci odiera` a morte per tutto quello che abbiamo
detto su di lui :)
Uhm, pero` per mantenere viva l'attenzione spostiamoci su... whitehouse.com
(.com mi raccomando, .gov e` quello della Casa Bianca e quelli sono cattiiivi
=).
Allora, primo passo: chiediamo al nostro server Whois di fiducia informazioni
per il dominio whitehouse.com, che, essendo registrato, dovra` fornirci le
informazioni che ci servono.
[recidjvo@pkcrew:~]$ whois whitehouse.com -h rs.internic.net
Whois Server Version 1.3
Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: WHITEHOUSE.COM
Registrar: REGISTER.COM, INC.
Whois Server: whois.register.com
Referral URL: www.register.com
Name Server: NS.NJ.EXODUS.NET
Name Server: NS2.EXODUS.NET
Name Server: W101.WHITEHOUSE.COM
Name Server: W102.WHITEHOUSE.COM
Updated Date: 16-feb-2001
>>> Last update of whois database: Tue, 1 May 2001 11:46:32 EDT <<<
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.
Non molte informazioni, eh? :( Vabbe`, pero` in questo modo gia` conosciamo i
nameserver, e per di piu` abbiamo il nome del server Whois presso il quale e`
stato registrato il dominio. Proviamo a interrogare questo:
[recidjvo@pkcrew:~]$ whois whitehouse.com -h whois.register.com
[...]
Organization:
Dan Parisi
Dan Parisi
295 Greenwich Street (Suite 184)
New York, NY 10007
US
Phone: (973) 503 1785
Email: dparisi@garden.net
Registrar Name....: Register.com
Registrar Whois...: whois.register.com
Registrar Homepage: http://www.register.com
Domain Name: WHITEHOUSE.COM
Created on..............: Wed, May 21, 1997
Expires on..............: Sat, May 22, 2004
Record last updated on..: Fri, Feb 23, 2001
Administrative Contact:
Dan Parisi
Dan Parisi
295 Greenwich Street (Suite 184)
New York, NY 10007
US
Phone: (973) 503 1785
Email: dparisi@garden.net
Technical Contact:
Dan Parisi
Dan Parisi
295 Greenwich Street (Suite 184)
New York, NY 10007
US
Phone: (973) 503 1785
Email: dparisi@garden.net
Zone Contact:
Dan Parisi
Dan Parisi
295 Greenwich Street (Suite 184)
New York, NY 10007
US
Phone: (973) 503 1785
Email: dparisi@garden.net
Domain servers in listed order:
W101.WHITEHOUSE.COM 209.67.27.247
W102.WHITEHOUSE.COM 209.67.27.248
NS2.EXODUS.NET 207.82.198.150
NS.NJ.EXODUS.NET 206.79.7.50
Bene, gia` meglio =)
Ora abbiamo i dati personali delle persone responsabili, un'inizio di idea di
che locazione geografica dobbiamo dare al progetto e altri due domini da
aggiungere alla lista: exodus.net e garden.net.
Vediamo il server DNS che cosa ci dice...
[recidjvo@pkcrew:~]$ host -a whitehouse.com. W101.whitehouse.com.
Using domain server:
Name: W101.whitehouse.com
Address: 209.67.27.247
Aliases:
rcode = 0 (Success), ancount=13
The following answer is not authoritative:
The following answer is not verified as authentic by the server:
whitehouse.com 71136 IN NS ns.nj.exodus.net
whitehouse.com 71136 IN NS ns2.nj.exodus.net
whitehouse.com 71136 IN NS w101.whitehouse.com
whitehouse.com 71136 IN NS w102.whitehouse.com
whitehouse.com 71136 IN NS web3.whitehouse.com
whitehouse.com 71136 IN NS web4.whitehouse.com
whitehouse.com 71136 IN NS prd4.wynn.com
whitehouse.com 71136 IN NS wa3yre.wynn.com
whitehouse.com 71136 IN NS ns.exodus.net
whitehouse.com 77935 IN SOA w101.whitehouse.com root.w101.whitehouse.com(
1999012728 ;serial (version)
10800 ;refresh period
3600 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)
whitehouse.com 74737 IN MX 10 mail.whitehouse.com
whitehouse.com 71136 IN NS ns2.exodus.net
whitehouse.com 65204 IN A 209.67.27.247
For authoritative answers, see:
whitehouse.com 71136 IN NS ns.nj.exodus.net
whitehouse.com 71136 IN NS ns2.nj.exodus.net
whitehouse.com 71136 IN NS w101.whitehouse.com
whitehouse.com 71136 IN NS w102.whitehouse.com
whitehouse.com 71136 IN NS web3.whitehouse.com
whitehouse.com 71136 IN NS web4.whitehouse.com
whitehouse.com 71136 IN NS prd4.wynn.com
whitehouse.com 71136 IN NS wa3yre.wynn.com
whitehouse.com 71136 IN NS ns.exodus.net
whitehouse.com 71136 IN NS ns2.exodus.net
Additional information:
ns.nj.exodus.net 32642 IN A 206.79.7.50
ns2.nj.exodus.net 32642 IN A 209.1.10.234
Bene, direi che non c'e` molto di piu` di quello che gia` sapevamo...
La prossima mossa e`, sempre usando il protocollo Whois, cercare di ottenere
maggiori informazioni sul responsabile (Dan Parisi).
[recidjvo@pkcrew.org:~]$ whois -h whois.networksolutions.com dparisi@garden.net
[...]
Parisi, Dan (DP996) dparisi@GARDEN.NET
Dan Parisi
Post Office Box 1009
Secaucus, NJ 07094
973-503-1785
Record last updated on 24-May-1999.
Database last updated on 1-May-2001 21:20:00 EDT.
[...]
Ho usato whois.networksolutions.com come server Whois perche` per quanto
riguarda la ricerca dei contatti non sempre sono ammesse query ricorsive, e
qui si trova molta piu` roba che in altri server :)
Ogni DNS server deve avere una registrazione (HOST Handle) per poter essere
utilizzato: vediamola =)
[recidjvo@pkcrew:~]$ whois W101.WHITEHOUSE.COM
[...]
Server Name: W101.WHITEHOUSE.COM
IP Address: 209.67.27.247
Registrar: REGISTER.COM, INC.
Whois Server: whois.register.com
Referral URL: www.register.com
[...]
E cosi` per gli altri server.
Ma se per caso ci fosse un PTR per questi server che non corrisponde con
l'host segnato nella registrazione? Controlliamo!!! =)
[recidjvo@pkcrew:~]$ host 209.67.27.247
247.27.67.209.IN-ADDR.ARPA domain name pointer www.whitehouse.com
Wow, il server DNS corrisponde al server web! =)
Ripetiamo tutto questo procedimento per tutti gli altri appunti che abbiamo
nella nostra tabellina, e riempiamo fogli e fogli di informazioni =)
Di certo ora abbiamo molte piu` informazioni, ma ci bastano? NOOO!!! (chi
dice "SIII" e` solo che non vede l'ora di vedersi le donnine nude, eh,
vecchio porcellone? =)
Visto che il nostro traceroute oltre a tracciare, se non gli si specifica
l'opzione -n cerca anche di risolvere gli ip in hostname, vediamo da che
linee passa il nostro percorso.
[recidjvo@pkcrew:~]$ traceroute whitehouse.com
[... skip dei primi HOP, la mia rete =) ...]
6 * Serial3-1-0.GW3.MLN4.ALTER.NET (146.188.38.137) 150.516 ms 192.999 ms
7 323.at-2-0-0.XR1.MLN4.Alter.Net (146.188.4.226) 215.669 ms 170.289 ms 183.82 ms
8 95.at-3-0-0.TR1.PAR2.Alter.Net (146.188.5.17) 226.501 ms 217.036 ms 207.106 ms
9 SO-6-0-0.TR1.LND9.Alter.Net (146.188.8.166) 191.53 ms * 250.536 ms
10 so-6-0-0.IR1.NYC12.Alter.Net (146.188.15.50) 292.398 ms 281.089 ms 287.598 ms
11 so-0-0-0.IR1.NYC9.ALTER.NET (152.63.23.57) 255.314 ms 312.739 ms 322.168 ms
12 119.at-5-0-0.TR1.NYC9.ALTER.NET (152.63.1.114) 317.851 ms 313.32 ms 351.918 ms
13 * 187.ATM5-0.XR1.NYC4.ALTER.NET (152.63.21.121) 315.974 ms 372.969 ms
14 189.ATM6-0.GW3.NYC4.ALTER.NET (152.63.24.141) 333.965 ms 320.045 ms 337.12 ms
15 exodus-nyc4-oc12-gw.customer.alter.net (157.130.60.98) 334.771 ms 300.338 ms 303.457 ms
16 dcr03-g4-0.jrcy01.exodus.net (216.32.223.99) 291.824 ms * 332.755 ms
17 rsm01-vlan990.jrcy01.exodus.net (216.32.222.170) 344.35 ms 281.031 ms 301.97 ms
18 www.whitehouse.com (209.67.27.247) 302.995 ms 316.483 ms 326.041 ms
Direi che questo tracciato si commenta da se =)
Ancora qualcosina dai... prima della grande sorpresa finale =)
Vediamo chi gestisce la zona di reverse:
[recidjvo@pkcrew:~]$ host -t NS 27.67.209.in-addr.arpa.
27.67.209.in-addr.arpa name server ns.exodus.net
27.67.209.in-addr.arpa name server ns2.exodus.net
[recidjvo@pkcrew:~]$ host -t NS 67.209.in-addr.arpa.
67.209.in-addr.arpa name server NS.EXODUS.NET
67.209.in-addr.arpa name server NS2.EXODUS.NET
Ok, rimane solo un'ultima cosa da fare, che e` anche abbastanza divertente se
ci riesce :)
Quando prima parlavamo delle varie query che si possono fare, ho accennato
brevemente alla AXFR, ovvero alla richiesta che di solito fa un nameserver
posto in slave per scaricare *completamente* la zona dal nameserver
principale.
Il problema di questo trasferimento e` che se non specificato altrimenti, il
namserver e` impostato per accettare a autorizzare trasferimenti di zona da
*chiunque* glielo chieda =) Quindi rischiamo di avere la mappa completa del
dominio che ci interessa (ripeto, anche se potrebbe essere un'incompetenza
dell'admin - cosa che di solito e` ^__^ - non e` illegale - o almeno spero,
bhuabuabbhuabhu :)
Per fare cio` chiamiamo il comando host(1) con i parametri -a -l e vediamo se
qualcuno dei nameserver autoritativi ci danno retta =)
Se lo facciamo su pornvalley.com (siii, mitica ritorna =), otteniamo il
seguente risultato:
[recidjvo@pkcrew:~]$ host -a -l pornvalley.com
rcode = 0 (Success), ancount=4
Found 1 addresses for NS2.MYDOMAIN.com
Found 1 addresses for NS3.MYDOMAIN.com
Found 1 addresses for NS4.MYDOMAIN.com
Found 1 addresses for NS1.MYDOMAIN.com
Trying 64.75.34.132
(Nada, qui l'admin si e` ricordato =)
Vediamo invece su whitehouse.com...
[recidjvo@pkcrew:~]$ host -v -a -l whitehouse.com
rcode = 0 (Success), ancount=10
Found 1 addresses for web3.whitehouse.com
Found 1 addresses for web4.whitehouse.com
Found 1 addresses for prd4.wynn.com
Found 1 addresses for wa3yre.wynn.com
Found 1 addresses for ns.exodus.net
Found 1 addresses for ns2.exodus.net
Found 1 addresses for ns.nj.exodus.net
Found 1 addresses for
ns2.nj.exodus.net
Trying 209.67.3.103
Connection failed, trying next server: No route to host
Trying 209.67.3.104
whitehouse.com 86400 IN SOA w101.whitehouse.com root.w101.whitehouse.com(
1999012728 ;serial (version)
10800 ;refresh period
3600 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)
whitehouse.com 86400 IN NS ns.exodus.net
whitehouse.com 86400 IN NS ns2.exodus.net
whitehouse.com 86400 IN NS ns.nj.exodus.net
whitehouse.com 86400 IN NS ns2.nj.exodus.net
whitehouse.com 86400 IN NS w101.whitehouse.com
whitehouse.com 86400 IN NS w102.whitehouse.com
whitehouse.com 86400 IN NS web3.whitehouse.com
whitehouse.com 86400 IN NS web4.whitehouse.com
whitehouse.com 86400 IN NS prd4.wynn.com
whitehouse.com 86400 IN NS wa3yre.wynn.com
whitehouse.com 86400 IN MX 10 mail.whitehouse.com
whitehouse.com 86400 IN A 209.67.27.247
chatzone.whitehouse.com 86400 IN CNAME chat.whitehouse.com
sexchannel.whitehouse.com 86400 IN A 216.182.48.76
cash.whitehouse.com 86400 IN A 209.67.3.123
webmail.whitehouse.com 86400 IN A 209.67.27.245
webmail.whitehouse.com 86400 IN MX 10 webmail.whitehouse.com
netmail.whitehouse.com 86400 IN CNAME mail.whitehouse.com
members3.whitehouse.com 86400 IN A 209.67.3.116
realserv.whitehouse.com 86400 IN CNAME sexchannel.whitehouse.com
mail.whitehouse.com 86400 IN MX 10 mail.whitehouse.com
mail.whitehouse.com 86400 IN A 209.67.27.246
localhost.whitehouse.com 86400 IN A 127.0.0.1
signup.whitehouse.com 86400 IN MX 10 mail.whitehouse.com
signup.whitehouse.com 86400 IN A 209.67.3.120
www.whitehouse.com 86400 IN A 209.67.27.247
w101.whitehouse.com 86400 IN A 209.67.3.101
web1.whitehouse.com 86400 IN A 209.67.3.101
store.whitehouse.com 86400 IN A 216.182.48.81
chat.whitehouse.com 86400 IN MX 10 mail.whitehouse.com
chat.whitehouse.com 86400 IN A 209.67.27.249
w102.whitehouse.com 86400 IN MX 10 mail.whitehouse.com
w102.whitehouse.com 86400 IN A 209.67.3.102
web3.whitehouse.com 86400 IN A 209.67.3.103
members.whitehouse.com 86400 IN MX 10 mail.whitehouse.com
members.whitehouse.com 86400 IN A 209.67.3.122
members.whitehouse.com 86400 IN A 209.67.3.121
web4.whitehouse.com 86400 IN A 209.67.3.104
signup1.whitehouse.com 86400 IN MX 10 mail.whitehouse.com
signup1.whitehouse.com 86400 IN A 209.67.3.123
ftp.whitehouse.com 86400 IN CNAME w101.whitehouse.com
whitehouse.com 86400 IN SOA w101.whitehouse.com root.w101.whitehouse.com(
1999012728 ;serial (version)
10800 ;refresh period
3600 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)
BINGOOOOOOOOO!!!!!!!!! =)
Stupidi stupidi STUPIDI admin :D
E da qui la fantasia prende piede, se applicate ricorsivamente la procedura a
tutte le info che avete diligentemente annotato nel vostro blocco, ottenete
davvero tante di quelle informazioni sulla struttura della rete da conoscerla
forse meglio dell'admin stesso, e tutto questo solo con host(1) e whois(1) =))
Ora capite come si possa trovare da passare il tempo quando la serata e`
piovosa, quando il capo ti costringe a stare in ufficio anche se non ne hai
punto voglia e fuori c'e` pure il sole, ma al parco dalla fanciulla che tanto
lo sguardo fuggi in preda al rossore non ci puoi andare, ne` tantomeno girare
in bicicletta spensierato ragionando sul senso della vita e sulla bellezza
che ci circonda, tu, unico, raro essere incompreso da chi vorresti ti potesse
amare, tu, pazzo sentimentalista che la gente addita come un tipo strano a
dir poco, tu, che scrivi per poter trasmettere al mondo cio` che reputi
importante e non vale la pena di tenerlo per te, tu che scrivi... oh, tu che
scrivi! OHHH!!! Si`, tu che scrivi, MA CHE CACCHIO STAI SCRIVENDO?!?!?! =)
Non sono impazzito, e` solo che voglio far vedere che in mezzo a tutte ste
schifezze che scrivo si risolleva a volte il mio animo di poeta :P
- MA VAFF...!!! :) (mannaggia se sto male =)
8. Future
Come sicuramente non mi stanchero` mai di dire, il mondo di internet e` in
continua evoluzione e quindi ogni giorno bisogna aspettarsi qualcosa di nuovo
che fa capolino all'orizzonte.
Tutta la comunita` spinge per migliorare sempre di piu` la situazione,
introdurre sistemi piu` sicuri e dare piu` possibilita` alla gente.
Vediamo ora brevemente aspetti che ancora non sono di uso comune, ma che
presto lo diventeranno, integrandosi in questo modo di gestione della immense
risorse della rete che sta prendendo sempre piu` piede a livello di utenza
mondiale.
8.1. Nuovi organismi e TLD
Di recente son stati proposti e approvati dei nuovi TLD che la ICANN ha
accettato e che diventeranno standard tra poco.
Personalemente l'introduzione di nuovi domini di primo livello non mi aggrada
molto, perche` purtroppo ci sara` la corsa dei soliti sciacalli per registrare
i nomi fino ad oggi considerati irraggiungibili.
Tornando sul piano tecnico, ecco i sette nuovi TLD con relativa short:
.aero - Compagnie di trasporto aereo
.biz - Societa` di commercio
.coop - Cooperative
.info - Uso arbitrario
.museum - Musei
.name - Per usi personali
.pro - Professionisti (ragionieri, avvocati, ...)
Molti altri domini erano stati sottoposti per l'approvazione, ma sono stati
bocciati.
La speranza comune e` che la gente dimostri un po' di civilta` con la
comparsa dei nuovi domini, ma non so perche` non sono molto fiducioso =)
Per informazioni piu` dettagliate potete riferirvi alle pagine della ICANN
all'url www.icann.org/tlds .
8.2. Futuro del protocollo
Non mi stanchero` mai di ripeterlo, Internet non e` certo finito qui e ogni
giorno qualcuno aggiunge qualcosa.
Per quanto ci riguarda, il protocollo DNS, pur apparendo stabile e
consolidato, e` in continua evoluzione, specialmente per quanto riguarda la
sicurezza: ad esempio l'introduzione delle TSIG per autenticare una
determinata risposta, utilizzando algoritmi di crittazione che stanno
rivestendo la parte del leone in questo periodo :)
Anche l'utilizzo che se ne puo` fare, come dimostrato dalle datate rfc
sull'utilizzo dei campi TXT o sulle YellowPages ci fa capire che studiando a
fondo la struttura di cio` che utiliziamo tutti i giorni e` possibile
inventare sempre qualcosa di diverso, insomma, un po' di fantasia =)
Le recenti modifiche introdotte dall'ICANN, le lamentele per la gestione dei
domini .name da parte di societa` non consolidate, da una parte sembrano
lecite, dall'altro ci permettono di vedere come non ci sia il monopolio
chiuso, ma che si puo` sempre sperare in una collaborazione finalizzata al
bene comune.
Quindi, vada come vada, l'importante e` sviluppare qualcosa di utile e, voglia
il Cielo, sperare che chi mantiene l'enorme potere dei domini sappia
amministrarlo bene.
9. Resources
Queste sono solo *alcune* delle cose che ci sono in giro riguardanti i DNS,
sono tutte piu` o meno interessanti, mi raccomando leggetele, cosi` magari
capite qualcosa di piu` =)
9.1. RFCs
0819 Domain naming convention for Internet user applications. Z. Su,
J. Postel. Aug-01-1982. (Format: TXT=35314 bytes) (Status: UNKNOWN)
0881 Domain names plan and schedule. J. Postel. Nov-01-1983. (Format:
TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN)
0897 Domain name system implementation schedule. J. Postel.
Feb-01-1984. (Format: TXT=15683 bytes) (Updates RFC0881) (Updated by
RFC0921) (Status: UNKNOWN)
0920 Domain requirements. J. Postel, J.K. Reynolds. Oct-01-1984.
(Format: TXT=27823 bytes) (Status: UNKNOWN)
0921 Domain name system implementation schedule - revised. J. Postel.
Oct-01-1984. (Format: TXT=23318 bytes) (Updates RFC0897) (Status:
UNKNOWN)
0952 DoD Internet host table specification. K. Harrenstien, M.K.
Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=12388 bytes)
(Obsoletes RFC0810) (Status: UNKNOWN)
0974 Mail routing and the domain system. C. Partridge. Jan-01-1986.
(Format: TXT=18581 bytes) (Also STD0014) (Status: STANDARD)
1032 Domain administrators guide. M.K. Stahl. Nov-01-1987. (Format:
TXT=29454 bytes) (Status: UNKNOWN)
1033 Domain administrators operations guide. M. Lottor. Nov-01-1987.
(Format: TXT=37263 bytes) (Status: UNKNOWN)
1034 Domain names - concepts and facilities. P.V. Mockapetris.
Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882,
RFC0883) (Obsoleted by RFC1065, RFC2308) (Updated by RFC1101,
RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308,
RFC2535) (Also STD0013) (Status: STANDARD)
1035 Domain names - implementation and specification. P.V.
Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes
RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348,
RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136,
RFC2137, RFC2308, RFC2535) (Also STD0013) (Status: STANDARD)
1101 DNS encoding of network names and other types. P.V. Mockapetris.
Apr-01-1989. (Format: TXT=28677 bytes) (Updates RFC1034, RFC1035)
(Status: UNKNOWN)
1122 Requirements for Internet hosts - communication layers. R.T.
Braden. Oct-01-1989. (Format: TXT=295992 bytes) (Also STD0003)
(Status: STANDARD)
1123 Requirements for Internet hosts - application and support. R.T.
Braden. Oct-01-1989. (Format: TXT=245503 bytes) (Updates RFC0822)
(Updated by RFC2181) (Also STD0003) (Status: STANDARD)
1178 Choosing a name for your computer. D. Libes. Aug-01-1990.
(Format: TXT=18472 bytes) (Also FYI0005) (Status: INFORMATIONAL)
1183 New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann,
P.V. Mockapetris. Oct-01-1990. (Format: TXT=23788 bytes) (Updates
RFC1034, RFC1035) (Status: EXPERIMENTAL)
1464 Using the Domain Name System To Store Arbitrary String
Attributes. R. Rosenbaum. May 1993. (Format: TXT=7953 bytes) (Status:
EXPERIMENTAL)
1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format:
TXT=100556 bytes) (Obsoletes RFC1386) (Status: INFORMATIONAL)
1535 A Security Problem and Proposed Correction With Widely Deployed
DNS Software. E. Gavron. October 1993. (Format: TXT=9722 bytes)
(Status: INFORMATIONAL)
1536 Common DNS Implementation Errors and Suggested Fixes. A. Kumar,
J. Postel, C. Neuman, P. Danzig, S. Miller. October 1993. (Format:
TXT=25476 bytes) (Status: INFORMATIONAL)
1591 Domain Name System Structure and Delegation. J. Postel. March
1994. (Format: TXT=16481 bytes) (Status: INFORMATIONAL)
1611 DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994.
(Format: TXT=58700 bytes) (Status: PROPOSED STANDARD)
1612 DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994.
(Format: TXT=61382 bytes) (Status: PROPOSED STANDARD)
1706 DNS NSAP Resource Records. B. Manning, R. Colella. October 1994.
(Format: TXT=19721 bytes) (Obsoletes RFC1637) (Status: INFORMATIONAL)
1713 Tools for DNS debugging. A. Romao. November 1994. (Format:
TXT=33500 bytes) (Also FYI0027) (Status: INFORMATIONAL)
1794 DNS Support for Load Balancing. T. Brisco. April 1995. (Format:
TXT=15494 bytes) (Status: INFORMATIONAL)
1876 A Means for Expressing Location Information in the Domain Name
System. C. Davis, P. Vixie, T. Goodwin, I. Dickinson. January 1996.
(Format: TXT=29631 bytes) (Updates RFC1034, RFC1035) (Status:
EXPERIMENTAL)
1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema.
December 1995. (Format: TXT=6424 bytes) (Status: PROPOSED STANDARD)
1912 Common DNS Operational and Configuration Errors. D. Barr.
February 1996. (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status:
INFORMATIONAL)
1918 Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear. February 1996.
(Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005)
(Status: BEST CURRENT PRACTICE)
1956 Registration in the MIL Domain. D. Engebretson & R. Plzak. June
1996. (Format: TXT=2923 bytes) (Status: INFORMATIONAL)
1982 Serial Number Arithmetic. R. Elz & R. Bush. August 1996. (Format:
TXT=14440 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED
STANDARD)
1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format:
TXT=16810 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)
1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY).
P. Vixie. August 1996. (Format: TXT=15247 bytes) (Updates RFC1035)
(Status: PROPOSED STANDARD)
2010 Operational Criteria for Root Name Servers. B. Manning, P. Vixie.
October 1996. (Format: TXT=14870 bytes) (Status: INFORMATIONAL)
2052 A DNS RR for specifying the location of services (DNS SRV). A.
Gulbrandsen, P. Vixie. October 1996. (Format: TXT=19257 bytes)
(Status: EXPERIMENTAL)
2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M.
Bellare, R. Canetti. February 1997. (Format: TXT=22297 bytes)
(Status: INFORMATIONAL)
2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie,
Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format: TXT=56354
bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)
2137 Secure Domain Name System Dynamic Update. D. Eastlake. April
1997. (Format: TXT=24824 bytes) (Updates RFC1035) (Status: PROPOSED
STANDARD)
2146 U.S. Government Internet Domain Names. Federal Networking
Council. May 1997. (Format: TXT=26564 bytes) (Obsoletes RFC1816)
(Status: INFORMATIONAL)
2163 Using the Internet DNS to Distribute MIXER Conformant Global
Address Mapping (MCGAM). C. Allocchio. January 1998. (Format:
TXT=58789 bytes) (Obsoletes RFC1664) (Status: PROPOSED STANDARD)
2168 Resolution of Uniform Resource Identifiers using the Domain Name
System. R. Danie1, M. Mealling. June 1997. (Format: TXT=46528 bytes)
(Status: EXPERIMENTAL)
2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July
1997. (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123)
(Updated by RFC2535) (Status: PROPOSED STANDARD)
2182 Selection and Operation of Secondary DNS Servers. R. Elz, R.
Bush, S. Bradner, M. Patton. July 1997. (Format: TXT=27456 bytes)
(Also BCP0016) (Status: BEST CURRENT PRACTICE)
2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright.
October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST
CURRENT PRACTICE)
2230 Key Exchange Delegation Record for the DNS. R. Atkinson. October
1997. (Format: TXT=25563 bytes) (Status: INFORMATIONAL)
2247 Using Domains in LDAP/X.500 Distinguished Names. S. Kille, M.
Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998. (Format:
TXT=12411 bytes) (Status: PROPOSED STANDARD)
2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March
1998. (Format: TXT=41428 bytes) (Obsoletes RFC1034) (Updates RFC1034,
RFC1035) (Status: PROPOSED STANDARD)
2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P.
Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020) (Status:
BEST CURRENT PRACTICE)
2345 Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G.
Oglesby. May 1998. (Format: TXT=29707 bytes) (Status: EXPERIMENTAL)
2352 A Convention For Using Legal Names as Domain Names. O. Vaughan.
May 1998. (Format: TXT=16354 bytes) (Obsoletes RFC2240) (Status:
INFORMATIONAL)
2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July
1998. (Format: TXT=52526 bytes) (Obsoletes RFC1884) (Status: PROPOSED
STANDARD)
2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M.
O'Dell, S. Deering. July 1998. (Format: TXT=25068 bytes) (Obsoletes
RFC2073) (Status: PROPOSED STANDARD)
2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July
1998. (Format: TXT=14356 bytes) (Status: INFORMATIONAL)
2377 Naming Plan for Internet Directory-Enabled Applications. A.
Grimstad, R. Huber, S. Sataluri, M. Wahl. September 1998. (Format:
TXT=38274 bytes) (Status: INFORMATIONAL)
2517 Building Directories from DNS: Experiences from WWWSeeker. R.
Moats, R. Huber. February 1999. (Format: TXT=14001 bytes) (Status:
INFORMATIONAL)
2535 Domain Name System Security Extensions. D. Eastlake. March 1999.
(Format: TXT=110958 bytes) (Updates RFC2181, RFC1035, RFC1034)
(Status: PROPOSED STANDARD)
2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. Eastlake.
March 1999. (Format: TXT=11121 bytes) (Status: PROPOSED STANDARD)
2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). D.
Eastlake. March 1999. (Format: TXT=10810 bytes) (Status: PROPOSED
STANDARD)
2538 Storing Certificates in the Domain Name System (DNS). D.
Eastlake, O. Gudmundsson. March 1999. (Format: TXT=19857 bytes)
(Status: PROPOSED STANDARD)
2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS).
D. Eastlake. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED
STANDARD)
2540 Detached Domain Name System (DNS) Information. D. Eastlake. March
1999. (Format: TXT=12546 bytes) (Status: EXPERIMENTAL)
2541 DNS Security Operational Considerations. D. Eastlake. March 1999.
(Format: TXT=14498 bytes) (Status: INFORMATIONAL)
2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S.
Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes)
(Obsoletes RFC2133) (Status: INFORMATIONAL)
2606 Reserved Top Level DNS Names. D. Eastlake, A. Panitz. June 1999.
(Format: TXT=8008 bytes) (Also RFC2606) (Status: BEST CURRENT
PRACTICE)
2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999.
(Format: TXT=15257 bytes) (Status: PROPOSED STANDARD)
2672 Non-Terminal DNS Name Redirection. M. Crawford. August 1999.
(Format: TXT=18321 bytes) (Status: PROPOSED STANDARD)
2673 Binary Labels in the Domain Name System. M. Crawford. August
1999. (Format: TXT=12379 bytes) (Status: PROPOSED STANDARD)
9.2. URLs
Documenti:
- http://www.pkcrew.org/docs/DNSjam.txt - This doc :)
- http://www.isc.org/products/BIND - ISC bind and docs
- http://www.faqs.org/rfcs - Per trovare tutti gli rfc che volete =)
Enti:
- http://www.icann.org - Internet Corporation of Assigned Names and Numbers
- http://www.iana.org - Internet Assigned Numbers Authority
- http://www.internic.net - InterNIC website
- http://www.networksolutions.com - NetSol archives
- http://www.ripe.net - Mantainer europeo
- http://www.nic.it - NIC italiano
9.3. HOWTOs && man
- Linux-HOWTOs/DNS-HOWTO by Nicolai Langfeldt janl@math.uio.noa
- named(8), named.conf(5), host(1), dig(1)
- gethostbyname(3), getaddrinfo(3)
9.4. Books
TCP/IP Illustrated, Chapter 1 - The protocols
by W. Richard Stevens (tnx to asynchro :)
9.5. About the Author
Beh, intanto grazie per aver letto tutto :)
Spero di avervi chiarito un po' le idee per quanto riguarda i dns e affini, o
almeno spero di avervi stuzzicato un po' la sete di conoscenza e la
curiosita`.
Per qualsiasi segnalazione, richiesta, commento, insulto o proposta di
matrimonio, sono reperibile qua e la` su IRC, e all'indirizzo
.
bye bye =)
t.R.
==============================================================================
--------------------------------[ EOF 18/18 ]---------------------------------
==============================================================================
