Ed.Scuole - GALLO - DNS

Marco Gallo (Consortium GARR)
DNS, Servizi GARR-NIC e GARR-LIR
Corsi Intensivi dedicati agli APM, Bari, 20/03/2015
Elenco degli Argomenti
§  Principi di base del DNS §  Il servizio GARR-­‐NIC §  Il servizio GARR-­‐LIR #2
Perché il DNS
#3
DNS: concetti base
§  Definizione tecnica: protocollo che perme@e di aggiornare e interrogare un database che sia… §  distribuito geograficamente §  dinamicamente consistente e coerente nei daD che amministra §  in grado di gesDre vari Dpi di records e daD §  Dal punto di vista operaDvo: §  è il protocollo uDlizzato ogni giorno da tuF coloro che tramite Internet accedono a determinate risorse o servizi in rete; §  se il DNS non funziona molD altri servizi su Internet sme@ono di funzionare #4
A cosa serve il DNS
§  Il DNS perme@e di associare un nome Human-­‐readable ad un host, più semplice da ricordare rispe@o ad un indirizzo IP. §  L'univocità nella determinazione dell’host a@raverso tale sistema è garanDta mediante l’adozione di una stru@ura gerarchica “a domini” per la quale ciascun host apparDene ad un dato dominio “registrato” ufficialmente in un database distribuito. §  Es: www.garr.it individua una macchina il cui nome è www appartenente al dominio garr che è a sua volta parte del dominio globale it #5
DNS: come funziona
§  Il principio è simile a quello dell’elenco telefonico §  Se avessimo un elenco di numeri senza nomi dovremmo provarli tuF per trovare quello giusto… #6
DNS: caratteristiche principali
Il DNS consente ad ogni organizzazione che ha accesso ad Internet di: §  amministrare la relazione tra nomi ed indirizzi del proprio dominio in maniera autonoma ed indipendente §  risolvere i nomi fuori del proprio dominio accedendo alle informazioni gesDte da altre organizzazioni #7
DNS: come è strutturato
§  Suddivisione gerarchica in domini §  Stru@ura ad albero rovesciato §  Località dell’informazione §  ogni nodo deDene un database con le informazioni del proprio dominio e interroga gli altri nodi quando deve trovare le informazioni non locali §  Basato sul modello client/server §  Le informazioni possono essere o@enute tramite interrogazioni ad una delle foglie dell’albero #8
Risoluzione diretta e inversa
§  Nel protocollo standard DNS vengono individuate e disDnte 2 Dpologie di risoluzioni: §  Risoluzione dire@a: §  Corrispondenza nome host – indirizzo IP §  Risoluzione inversa: §  Corrispondenza indirizzo IP – nome host #9
DNS: principali componenti
§  tre componenD principali: §  spazio dei nomi (namespace) e informazioni associate (Resource Record -­‐ RR) §  nameservers (nodi che mantengono una parte del database globale) §  resolvers (client per l’interrogazione del nameserver) §  Aumento delle prestazioni di risposta sul DNS a@raverso l’adozione di meccanismi di caching delle informazioni. §  database in memoria RAM #10
Name Servers
§  Un Name Server è un host appartenente ad un dominio che conDene tuF i record (corrispondenze nomi-­‐indirizzi e/o viceversa) di tale dominio §  Ovvero il name server di un dato dominio conDene il database locale relaDvo a quel dato dominio, che è un so@oinsieme del database globale §  Esistono vari Dpi di nameserver. §  autoritaDve, caching, master, slave, forwarders, ricorsivo, non ricorsivo… #11
Meccanismo di risoluzione nel
namespace root
§  Un nome a dominio viene analizzato da destra verso sinistra, chiedendo a ciascun nameserver di fornire informazioni soltanto sull'elemento che si trova a sinistra dell'ulDmo punto. §  TuF i nomi a dominio esistenD su Internet in realtà terminano con un “.” (punto): §  garr.it. §  La stringa vuota che segue il punto finale è chiamata dominio radice (DNS root zone); #12
Ruolo dei root nameserver
§  I root nameserver sono i server responsabili (autoritaDvi) delle informazioni relaDve al dominio "."; §  Possiedono l'elenco dei server responsabili per ognuno dei domini di primo livello riconosciuD, e lo forniscono in risposta a ciascuna richiesta. §  Contengono anche le informazioni per la risoluzione inversa (risoluzione indirizzo-­‐nome) §  La lista aggiornata dei root-­‐server è mantenuta da InterNIC §  3p://3p.rs.internic.net/domain/named.root §  3p://3p.nic.it/pub/DNS/named.root #13
I root nameserver
#14
I root nameserver
#15
21 Oct 2002: Root Server Denial of Service Attack
§  Natura dell’a0acco: §  A@acco di Dpo denial of service venne lanciato contro i 13 root nameservers §  Le dimensioni dell’a@acco furono dai 50 ai 100 Mbits/sec per root nameserver con un volume complessivo di a@acco di circa 900 Mbits/sec §  Impa0o dell’a0acco: §  Alcuni root nameserver vennero resi irraggiungibili da diverse parD dell’Internet Globale, molte query valide dire@e ai root nameserver non giunsero a desDnazione #16
Root nameserver replicati
§  La ISC (Internet Sojware ConsorDum ) ha ado@ato un sistema che perme@e di replicare i Root Name Server in modo da renderli più accessibili a località fisicamente lontane dai 13 Root Server globali. §  PresupposD: §  Configurare NS cloni da un master/primary server che contengano gli stessi daD (files); §  che uDlizzino lo stesso indirizzo IP (metodo Anycast). §  Le repliche dei root nameserver sono state installate in punD nevralgici di Internet §  Presso il NAMEX a Roma, la MIX a Milano ed altri Interner Exchange §  Presso MIX: repliche di I-­‐root, K-­‐root e J-­‐root di cui sia I che K rispondono anche in IPv6 §  Presso NAMEX: repliche di F.root, J.root di cui F risponde anche in IPv6 §  Vantaggi per gli ISP afferenD agli Internet Exchange: tempi di risposta più bassi per le richieste rivolte ai root NS. §  h@p://www.root-­‐servers.org/ #17
L’albero dei nomi
“.“
COM
EDU
BERKELEY
AI
PREP
MIT
US
STANFORD
LCS
XX
IT
GARR
NOC
VX
EU
LIR
FIAT
DIR
DXGARR
FI
UK
ARPA
LAZIO
IN-ADDR
COMUNE
REGIONE
PCGARR81
#18
Il Reverse Lookup
#19
Perché fare Reverse DNS
§  Corrispondenza tra indirizzi IP e nomi a dominio. §  uDlizzato da tools per troubleshooDng sulla rete come traceroute o ping. §  Necessario per alcune applicazioni, in primo luogo la posta ele@ronica. §  MolD mail-­‐server rifiutano posta la cui sorgente non ha un rDNS configurato. §  Il reverse di un indirizzo IPv4 è espresso, nel dominio “in-­‐
addr.arpa”, da una sequenza di bytes in ordine inverso, rappresentaD come numeri decimali separaD da un punto #20
L’albero per la risoluzione
inversa
“.“
ARPA
IN-ADDR
.....
128
146
.....
.....
193
195
.....
48
8
65
1
69
.....
.....
48.146.in-addr.arpa dominio
65.48.146.in-addr.arpa sottodominio
69.65.48.146.in-addr.arpa macchina
254
#21
Il meccanismo di Delega
#22
Il concetto di delega
§  La gesDone del DNS dei domini (figli) può essere delegata ad altre organizzazioni. §  Questo significa che chi definisce e crea un dominio non necessariamente ne deve dire@amente gesDre il DNS ma può delegare tale aFvità. §  Un’organizzazione di grande dimensioni è probabile che abbia un dominio isDtuzionale ed un numero elevato di so@odomini. GesDre i so@odomini può diventare oneroso, sopra@u@o se quesD sono distribuiD geograficamente. §  La decentralizzazione della responsabilità amministraDva è o@enuta a@raverso il meccanismo della delega #23
Le zone e i nameserver
la stru@ura gerarchica dello spazio dei nomi si rifle@e nella relazione tra i nameserver il meccanismo della delega di autorità si basa sui seguenD principi: §  ogni nameserver di un dominio, per essere conosciuto nel DNS, deve essere stato registrato dal nameserver del dominio di livello superiore. Questo crea la delega §  una volta delegata l'autorità su una zona, il nameserver “padre” perde ogni possibilità di modificare le informazioni dei resource records contenuD nella zona delegata §  i nameserver delegaD possono essere più d'uno (è consigliato averne almeno due, in alcuni casi è addiri@ura obbligatorio), ma uno solo è quello che possiede la vera autorità perché gesDsce i files contenenD le informazioni #24
Classificazione dei name
server : Nameserver primari e
secondari
§  Un nameserver si definisce primario (master) quando possiede i file delle informazioni (“file di zona”) e pertanto in ogni zona vi sarà un solo nameserver primario (accesso in le@ura e scri@ura alle info del database) §  Un nameserver si definisce secondario (slave) quando acquisisce, dal nameserver primario (quindi ha una copia in sola le@ura) , i daD relaDvi alla zona mediante una procedura automaDca denominata “zone-­‐transfer” §  i parametri che regolano il funzionamento della procedura sono contenuD in uno specifico record del nameserver primario (record Start Of Authority -­‐ SOA) §  E’ necessario valutare a@entamente il numero e la dislocazione dei nameserver secondari in modo da ridurre il più possibile il rischio che problemi di connessione possano impedire la risoluzione dei nomi di un dominio (configurazione fault tolerant) #25
Il processo di risoluzione dei nomi
#26
Nameserver e Resolver
§  Il processo di risoluzione dei nomi a dominio è basato sul modello client-­‐server: §  il nameserver (server) ha il compito di fornire “risposte autoritaDve” ad interrogazioni sui nomi definiD nell’ambito dei domini per cui è autoritaDvo (cioe’ dei quali deDene una copia del database in le@ura/
scri@ura); §  il resolver (client) è invece uDlizzato dalle applicazioni che hanno necessità di effe@uare una risoluzione di nomi a dominio. Esso è cosDtuito da un insieme di rouDne di libreria che sono in grado di colloquiare con i nameserver, interpretarne le risposte e resDtuire l’informazione al programma richiedente. #27
Indirizzamento delle queries
§  Che cosa accade se vi sono più NS autoritaDvi per uno stesso dominio? A quale di quesD il nostro NS indirizzerà la query di risoluzione? §  L’algoritmo di indirizzamento di una interrogazione è il seguente : §  Il NS raggruppa i server in base al loro RTT §  All’interno di un singolo gruppo (a parità di RTT) l’indirizzamento avviene con ciclo round robin #28
Risoluzione dei nomi
§  Se il nome desiderato non è nella zona (o nella cache) del NS interrogato, si innesca il processo di risoluzione dei nomi §  La richiesta di risoluzione ripercorre l’albero fino alla radice e lo ridiscende fino ad arrivare ad un NS autoritaDvo la cui zona conDene il nome in quesDone e quindi anche gli RR §  La risposta, opportunamente salvata in tuF i cache intermedi, viene infine passata dal resolver all’utente che aveva effe@uato la richiesta #29
Query "recursive" o "non-recursive"
§  Se un name server riceve una query per un dominio che non gesDsce dire@amente sono possibili due opzioni: 1.  Il name server può rispondere al client indicando un altro name server che sia in grado di rispondere in modo appropriato. 2.  Il name server può cercare di risolvere in modo completo la richiesta a@raverso una serie di richieste agli altri name servers, fino ad aver completato la risoluzione della richiesta. #30
Il processo di risoluzione dei nomi
query per www.iat.cnr.it
2
referral al NS per it.
Default
Nameserver
(cache vuota)
query for www.iat.cnr.it
3
referral al NS per cnr.it
root
nameserver
it.
“.“
IT
COM
nameserver
query for www.iat.cnr.it
4
referral al NS per iat.cnr.it
cnr.it
nameserver
CNR
UNIPI
query: www.iat.cnr.it
1
6
RESOLVER
applicazione
utente
5
iat.cnr.it
RR per www.iat.cnr.it
nameserver
IAT
BO
www
#31
Il DNS su IPv6
#32
DNS: obiettivo/esigenza
§  Dare dei nomi ai calcolatori §  Associare un nome Human-­‐readable ad un host, più semplice da ricordare di un indirizzo §  IP. … Se in IPv4 questo era (è) l’obieLvo §  In IPv6 diventa un’esigenza… 2001:0b00:0c18:0001:0290:27ff:fe17:fc1d §  Un indirizzo è formato da 8 campi di 16 bits ciascuno (128 in tu@o), ogni campo è separato da “:” ed espresso in notazione esadecimale #33
Le Notiva’ introdotte nel DNS con IPv6
§  L’uDlizzo di IPv6 non modifica i meccanismi di base del Domain Name System §  Per gesDre la risoluzione degli indirizzi IPv6 sono staD introdoF: §  un nuovo resource record per associare un indirizzo IPv6 ad un nome §  un (due) nuovo dominio per la risoluzione inversa degli indirizzi IPv6 #34
Risoluzione diretta e inversa
§  Anche con IPv6, nel protocollo standard DNS, vengono individuate e disDnte 2 Qpologie di risoluzioni: §  Risoluzione dire0a: §  Corrispondenza nome host – indirizzo IPv6 §  Risoluzione inversa: §  Corrispondenza indirizzo IPv6 – nome host #35
Domini di reverse-lookup: ip6.arpa o ip6.int?
§  L’RFC 1886 indica l’ip6.int come dominio da uDlizzare per la mappatura del reverse lookup in IPv6. §  L’RFC 3152 invece dice di usare l’ip6.arpa. §  Poiche’ l’archite@ura gerarchica del DNS già usava il “.arpa” per IPv4, l’ip6.arpa e’ stato preferito all’ip6.int (deprecato dall’IETF I Giugno 2006 – RFC 4159) come dominio per il reverse in IPv6 #36
Il reverse DNS lookup
§  Il reverse di un indirizzo IPv6 è espresso, nel dominio “ip6.arpa ”, da una sequenza di o@o cifre esadecimali scri@e in ordine inverso; numeri e le@ere sono separaD da un punto #37
Risoluzione diretta e inversa di un indirizzo IPv6
nell’albero dei nomi
Indirizzo IP◊ Nome
arpa
in-addr
193
0 ...
206
com
net
apnic
ip6
194
Nome ◊ Indirizzo IP
root
it
ripe
garr
whois
1.0.0.2
ns1
infn
lnf
... 255
0.6.7.0
141
142
193.206.141.38
f.f.f.f
ns1.garr.net
38
2001:760:ffff:ffff::aa
193.206.141.38 è 38.141.206.192.in-addr.arpa.
a.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.f.f
2001:760:ffff:ffff::aa
à
ns1.garr.net
a.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.f.f.f.f.f.f.0.6.7.0.1.0.0.2.ip6.arpa
#38
Il Servizio di Nework Information
Center del GARR
#39
Terminologia del Naming
Registro TLD Registrant Registrar Registrazione Authority ICANN EURid IANA #40
Un po’ di storia
§  Le funzioni di amministrazione dei registri di nomi a dominio (inclusa la distribuzione di domini di alto livello e indirizzi IP) erano effe@uate da Jon Postel, un ricercatore dell’isDtuto di scienze dell’informazione dell’Università del sud California, già coinvolto nella creazione di ARPANET. •  C o n l ’ e s p a n d e r s i d i I n t e r n e t , i l diparDmento di Difesa degli StaD UniD iniziò un processo per fondare una nuova organizzazione che svolgesse le mansioni che adesso spe@ano al diparDmento IANA dell’ICANN. #41
ICANN (Internet Corporation
for Assigned Names and Numbers)
§  Ente statunitense, isDtuito il 18 se@embre 1998 con incarico di: §  assegnare gli indirizzi IP §  gesDre il protocollo del sistema dei nomi a dominio di primo livello (Top-­‐Level Domain) generici (gTLD), dei country code (ccTLD) e dei root servers. §  Per approfondimenD, al seguente link è disponibile lo statuto di ICANN (versione italiana): h@ps://www.icann.org/resources/pages/
bylaws-­‐2012-­‐02-­‐25-­‐it #42
IANA (Internet Assigned Numbers
Authority)
§  Il ruolo a@ualmente svolto da ICANN era un tempo svolto da IANA con mandato governaDvo degli StaD UniD d'America. §  Ora IANA è un diparDmento di ICANN #43
I Top Level Domain (TLD)
§  Esistono due Dpi di TLD: §  I domini generali (gTLD): .com, .net, .org… §  I domini nazionali (ccTLD): .it, .uk, .de, .us §  Lista dei TLD: h@p://www.iana.org/domains/root/db #44
La gestione dei ccTLD
§  I ccTLD (country code Top Level Domains) Sono gesDD da organismi nazionali riconosciuD da ICANN §  Le Authority dei ccTLD non si occupano di registrare dire@amente domini per conto degli utenD finali. §  A tal fine ci sono i Registrars che hanno un contra@o con le Authority in base al quale possono gesDre registrazioni di nomi a dominio, in proprio o per conto dei propri utenD. §  Il Registrar gesDsce il rapporto fra l’Authority del ccTLD e l’assegnatario del dominio de@o Registrant §  Il Registrar esegue le procedure tecniche per la registrazione e manDene i daD dei propri Registrant nel database delle Authority dei ccTLD #45
Il Registro
§  Organismo responsabile dell’assegnazione dei nomi a dominio e della gesDone dei registri e del nameserver primario per il Top Level Domain “it” §  Le aFvità del Registro sono svolte dall'IsDtuto di InformaDca e TelemaDca del Consiglio Nazionale delle Ricerche (IIT-­‐CNR) con sede a Pisa. #46
EURid
§  EURid (European Registry of Internet Domain) è l'associazione no-­‐profit con sede in Belgio che è stata scelta dalla Commissione Europea per gesDre il nuovo ccTLD “.eu” §  EURid è nata da una collaborazione tra DNS BE, IIT CNR e NIC SE, gestori del ccTLD per il Belgio (.be), per l'Italia (.it) e per la Svezia (.se) #47
La gestione dei TLD
ICANN
IANA
Authorities dei TLD
Registro, EURid…
(.it, .eu, .org, .net …)
Registrars
Registrants
#48
Registrare un dominio con GARR-NIC
#49
Cosa fa il GARR-NIC?
§  Registra nuovi nomi a dominio agli utenD GARR §  ManuDene le informazioni dei domini già registraD. §  Fornisce supporto agli EnD GARR sul funzionamento del DNS e gesDsce un eventuale DNS secondario #50
Il Registrar per gli Enti GARR
•  Il GARR-­‐NIC registra nomi esclusivamente so@o i ccTLD “.it” e “.eu“ •  Il GARR-­‐NIC registra nomi solo per EnD, quindi per persone giuridiche, mai per persone fisiche •  La registrazione di un nuovo nome a dominio deve essere sempre fa@a in accordo con l'APA (Access Port Administrator) dell'Ente. #51
Chi puo’ registrare un dominio con
GARR-NIC
§  Tu@e le EnDtà che rappresentano la Comunità Accademica e della Ricerca ScienDfica italiana §  Le Università e isDtuzioni culturali e/o scienDfiche straniere con sede in Italia e per le quali esistono accordi con il Governo Italiano; §  Le scuole collegate alla Rete GARR #52
Costi di registrazione per un Ente GARR
§  I cosD di registrazione di un dominio rientrano in quelli sostenuD dall’Ente per la convenzione che ha con GARR. §  Il mantenimento del nome a dominio si rinnova tacitamente di anno in anno, fa@a salva disde@a da parte dell’Ente assegnatario del dominio #53
Regole di registrazione
§  I domini registraD a@raverso GARR devono essere uDlizzaD per scopi isDtuzionali e non in confli@o con le AUP: h@p://
www.garr.it/utenD/regole-­‐di-­‐accesso/acceptable-­‐use-­‐policy-­‐
aup §  L’APA deve far pervenire una richiesta di registrazione dominio a GARR-­‐NIC. §  Una volta registrato un nome a dominio di secondo livello, non occorre registrare anche i domini di livello successivo al secondo che possono essere gesDD autonomamente dal Registrant del dominio di secondo livello #54
Come si registra un nuovo dominio
con GARR
§  Per registrare un nome a dominio occorre: §  una richiesta di registrazione firmata dall’APA da inviare via email a [email protected] e in Cc a [email protected] in cui dovranno essere riportaD tuF i daD relaDvi al dominio, ovvero: §  DaD del Registrante (nome isDtuzionale dell’Ente, i riferimenD della sede, p. IVA) §  Responsabile amministraDvo admin-­‐c = APA §  Responsabile tecnico tech-­‐c = APM §  DNS primario e secondario Il modulo di richiesta di registrazione è scaricabile dal WEB del GARR-­‐NIC a questa URL: h@p://www.servizi.garr.it/index.php/it/voip/informazioni-­‐tecniche/documenD-­‐
pubblici/doc_download/82-­‐richiesta-­‐e-­‐mantenimento-­‐nome-­‐a-­‐dominio #55
Sistema sincrono di registrazione
§  Dal 08/02/2011 anche per i domini ".it" è possibile gesDre le procedure di registrazione e mantenimento in modalità sincrona. §  La registrazione di un dominio in modalità sincrona consente al GARR-­‐NIC di portare a termine, in tempo reale, sia le procedure di aggiornamento dei domini già registraD che di registrazione di nuovi nomi a dominio, senza dover richiedere all’Ente registrante l’invio di alcuna documentazione cartacea al Registro. #56
Domini IDN (Internationalized
Domain Names)
§  A parDre dall’11 Luglio 2012 è possibile registrare domini .IT contenenD cara@eri non ASCII. §  IDN è la sigla che idenDfica il sistema che perme@e di registrare nomi a dominio nelle 24 lingue dell'Unione Europea. §  Limitazioni per un nome a dominio nel ccTLD .it: §  lunghezza minima 3 cara@eri per i nomi a dominio dire@amente so@o il ccTLD .it e massima di 63 cara@eri per ciascuna parte di un nome a dominio per una lunghezza massima complessiva di 255 cara@eri; §  cara@eri ammessi: -­‐ ASCII: cifre (0-­‐9), le0ere (a-­‐z) e traLno (-­‐) -­‐ NON ASCII: à, â, ä, è, é, ê, ë, ì, î, ï, ò, ô, ö, ù, û, ü, æ, œ, ç, ÿ, β §  ciascuna componente di un nome a dominio non può iniziare o terminare con il traFno (-­‐); §  ciascuna componente di un nome a dominio non deve contenere nei primi qua@ro cara@eri la stringa "xn-­‐-­‐ " riservata alla codifica IDN di un nome a dominio #57
La procedura di registrazione
GARR-NIC riceve la
richiesta di registrazione
E’ firmata
dall’APA?
no
si
GARR-NIC notifica via e-mail
all’APM e in Cc all’APA che la
richiesta deve essere firmata
dall’APA nominato dall’Ente
GARR-NIC Invia modulo
elettronico di
registrazione e controlla
configurazione DNS
DNS corretto?
no
GARR-NIC notifica via email all’APM di
correggere la
configurazione del DNS
si
Si porta a termine
la procedura
#58
Configurazione del DNS
§  L’Ente deve configurare: §  Il proprio DNS primario §  Un eventuale DNS secondario §  Il GARR-­‐NIC può fornire il servizio di DNS secondario. §  Per queste operazioni l’ente ha il pieno supporto del GARR-­‐NIC. #59
Problematiche sul DNS più frequenti
§  Mancata configurazione del nameserver primario §  Corre@a configurazione del primario ma secondario non configurato §  Valori dei parametri del record SOA erraD §  Serial non aggiornato dopo la modifica della configurazione del nameserver §  Non viene permesso lo zone transfer ad ns1.garr.net se configurato come secondario §  Porta del DNS filtrata da un firewall #60
Verifica dei dati inseriti nel DB
del Registro ed EURid
§  I daD registraD presso il database del Registro e di EURid possono essere verificaD via whois. §  Da linea di comando: whois -­‐h whois.nic.it {nome a dominio} whois -­‐h whois.eu {nome a dominio} §  Oppure via web alle seguenD URL: h@p://www.nic.it/web-­‐whois/index.jsf h@p://www.eurid.eu/en/whois-­‐search #61
Operazioni di mantenimento
#62
Cambio Registrar/Registrant
§  Azioni da parte del (nuovo) Registrant §  Invio a GARR-­‐NIC di una richiesta di registrazione dominio (stesso modulo per registrazione) firmata dall’APA §  Indicare nel modulo di richiesta il Dpo di azione da eseguire e il codice auth-­‐info §  Configurazione dei nameserver autoritaDvi §  Azioni da parte del GARR-­‐NIC §  Invio richiesta di cambio Registrar del dominio tramite sistema sincrono §  Eventuale configurazione di un nameserver secondario #63
Aggiornamento admin e tech
§  Per aggiornare I daD del conta@o tecnico od amministraDvo di un dominio occorre inviare una mail a [email protected] fornendo tuF I daD dei nuovi contaF: Riferimento amministraQvo (admin) o tecnico (tech) del dominio: Nome: Cognome: Ente: Indirizzo e cap: e-­‐mail: telefono: fax: §  L’aggiornamento verrà eseguito dal GARR-­‐NIC entro lo stesso giorno di invio della richiesta. #64
Aggiornamento nameservers
§  Azioni da parte del Registrant §  Invio a GARR-­‐NIC di una richiesta via email a [email protected] di cambio nameserver fornendo nomi ed IP §  Configurazione dei nuovi nameserver autoritaDvi lasciando aFvi i vecchi nameserver finche’ non ha avuto termine il processo di propagazione delle informazioni nel DNS. §  Azioni da parte del GARR-­‐NIC §  Invio richiesta di cambio nameserver autoritaDvi del dominio tramite sistema sincrono §  Eventuale configurazione di un nameserver secondario #65
Il Problema del Cybersquatting
#66
Cosa è il Cybersquatting
§  AFvità illegale di chi si appropria di nomi di nomi a dominio corrispondenD a marchi commerciali altrui o a nomi di personaggi famosi o di EnD Pubblici o PrivaD al fine di realizzare un lucro sul trasferimento del dominio a chi ne abbia interesse od un danno a chi non lo possa uDlizzare. §  PraDca diffusissima negli StaD UniD, ha avuto un notevole sviluppo anche in Italia, specialmente in seguito all'entrata in vigore nel 1999 della regola che consente ai Dtolari di parDta IVA la registrazione di un numero illimitato di domini. §  In Italia, in assenza di una disciplina legislaDva ad hoc, la giurisprudenza prevalente ha fa@o ricorso alla normaDva relaDva al diri@o al nome. #67
Enti GARR vittime del Cybersquatting
§  Il problema si è concentrato sui domini .it. Gli EnD GARR sino ad ora più colpiD da CybersquaFng sono le Università Statali. §  Il Registro del ccTLD .it me@e a disposizione dei Registrant la procedura di opposizione. Essa “congela” l’assegnazione del dominio fino alla soluzione della controversia e consente a chi l’ha promossa di esercitare un diri@o di prelazione sull’eventuale nuova assegnazione. §  Altra procedura che si può tentare è quella della Verifica dei requisiQ soggeLvi: si tra@a di chiedere al potenziale cybersquaCer di provare la veridicità dei suoi daD registraD nel database del Registro. Se questa verifica non viene portata a termine si revoca il nome a dominio che potrà essere riassegnato in favore dell’Ente viFma #68
Il servizio di Local Internet Registry
del GARR
#69
Cosa è un Regional Internet
Registry (RIR)
§  E’ un'organizzazione che sovrintende all‘allocazione e alla registrazione delle risorse IP in una specifica area geografica. In parDcolare si occupa di gesDre l’assegnazione di spazio di indirizzamento IPv4, IPv6 ed ASn. §  IANA ha allocato spazio di indirizzamento pubblico ad ogni RIR sulla base delle necessità dell’area geografica che amministrano #70
#71 RIPE & RIPE NCC
§  RIPE (Réseaux IP Européens) è una comunità aperta a tuF coloro che sono interessaD alla coordinazione dello sviluppo delle ReD IP Geografiche §  ObieFvo di RIPE è la coordinazione amministraDva necessaria per l'operaDvità di una rete IP europea §  RIPE NCC (RIPE Network CoordinaDon Centre ) è un’organizzazione no profit che fornisce supporto tecnico ai Local Internet Registries (LIR) #72
Cosa è un LIR
§  Un Local Internet Registry (LIR) è un'organizzazione alla quale è stato assegnato un blocco di indirizzi IP da un RIR che a sua volta ne controlla l’uDlizzo. §  La maggior parte dei LIR sono fornitori di servizi Internet. §  Per essere LIR è richiesta l'appartenenza ad un RIR §  Cosa fa un LIR: §  Assegna le risorse IP (allocate dal RIR) ai propri utenD; §  GesDsce il rapporto tra utenD finali e il RIR; §  ManDene i daD relaDvi alle risorse IP assegnate alle proprie utenze all’interno del database del RIR #73
La “Gerarchia”
•  Le cinque RIR (RIPE NCC, APNIC, ARIN, LACNIC,AfriNIC) ricevono spazio di indirizzamento da IANA (Internet Assigned Numbers Authority) e a loro volta assegnano spazio IP alle LIR IANA
Internet Assigned
Numbers Authority
AFRINIC
RIPE NCC
African Network
Information Centre
RIPE Network
Coordination
Centre
LIRs
LIRs
APNIC
ARIN
LIRs
LIRs
LACNIC
Latin American and
ASIA Pacific Network American Registry for
Caribbean IP Address
Informaton Centre
Internet Numbers
Regional Registry
LIRs
#74
Assegnazione di spazio IP dal GARR-LIR
§  GARR-­‐LIR assegna nuovo spazio di indirizzamento: §  a tu@e le EnDtà che rappresentano la Comunità Accademica e della Ricerca ScienDfica italiana; §  alle Università e isDtuzioni culturali e/o scienDfiche straniere con sede in Italia e per le quali esistono accordi con il Governo Italiano; §  alle scuole collegate alla Rete GARR §  L’assegnazione viene fa@a sulla base delle reali necessità di indirizzamento da parte degli utenD. §  L’Ente richiedente dovrà fornire informazioni riguardo alla stru@ura della propria rete locale. §  UDlizzo dello spazio IP a@ualmente assegnato §  RequisiD dello spazio IP richiesto §  Sviluppi futuri della rete #75
Registrazione e consultazione dei
dati delle reti nel database Whois
§  Una volta assegnato lo spazio di indirizzamento il GARR-­‐LIR registra la risorsa IP nel database del RIR §  I daD registraD possono essere controllaD mediante whois §  Per ricevere i daD dall’whois di RIPE si interroga l’host whois.ripe.net # whois –h whois.ripe.net {indirizzo IP} §  I daD possono essere controllaD anche via web: hCps://apps.db.ripe.net/search/query.html #76
Indirizzamento IPv4 dedicato alle
Scuole
inetnum: 138.41.0.0 -­‐ 138.41.255.255 org: ORG-­‐GIRa1-­‐RIPE netname: CS-­‐NET descr: ConsorDum GARR country: IT admin-­‐c: FR7236-­‐RIPE tech-­‐c: GL965-­‐RIPE status: LEGACY remarks: This prefix is staDcally assigned remarks: To noDfy abuse mailto: [email protected] remarks: GARR -­‐ Italian academic and research network remarks: -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐ remarks: This prefix has been reserved to the public remarks: Schools in Italy connected to the GARR Network remarks: -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐ mnt-­‐irt: IRT-­‐GARR-­‐CERT mnt-­‐by: GARR-­‐LIR changed: ripe-­‐[email protected] 19990706 changed: er-­‐[email protected] 20031211 changed: [email protected] 20110126 changed: [email protected] 20131004 changed: [email protected] 20131004 changed: [email protected] 20131009 changed: [email protected] 20140117 changed: [email protected] 20150121 source: RIPE #77
Aggiornamento reverse-lookup
§  I daD sui nameserver autoritaDvi per il reverse lookup di una rete vengono riportaD nel domain object. -­‐ Esempio di domain object: domain: 206.193.in-­‐addr.arpa descr: Class C networks block for descr: GARR-­‐connected OrganisaDons admin-­‐c: EV182-­‐RIPE tech-­‐c: GL965-­‐RIPE zone-­‐c: GL965-­‐RIPE nserver: ns1.garr.net nserver: ns2.garr.net nserver: ns.ripe.net mnt-­‐by: GARR-­‐LIR changed: [email protected] 20050801 source: RIPE #78
L'indirizzamento IPv6 per gli Enti GARR
#79
Allocazione Spazio IPv6
§  I RIR hanno ado@ato una poliDca comune per l’allocazione di spazio di indirizzamento IPv6 ai LIR §  I RIR assegnano ai LIR una /32 da cui poi vengono estraF i prefissi da assegnare agli utenD finali. #80
Suddivisione dello spazio IPv6 routabile
Struttura dello spazio di indirizzamento IPv6 Global Unicast
§ 
La prima stringa esadecimale (2000) rappresenta l’intero spazio routabile (2000::/3 ovvero 2000 -­‐ 3FFF). Viene assegnato da IANA alle RIR [RFC 1881]. § 
Nella seconda vengono definite le varie “so@o-­‐classi” amministrate dai RIR §  h@p://www.iana.org/assignments/ipv6-­‐unicast-­‐address-­‐assignments/ § 
La terza stringa definisce la suddivisione dello spazio IPv6 (/32) allocato dai RIR ai vari LIR che a loro volta andranno ad assegnare agli utenD finali con prefissi di grandezza /48. § 
Nella quarta stringa vengono definiD gli idenDficaDvi delle varie subnet ricavabili dalle /48 assegnate agli utenD finali dai LIR. § 
Una /48 corrisponde a 65,536 (2^16) /64. Ogni /64 conDene 2^64 (18,446,744,073,709,551,616) indirizzi IPv6 #81
Allocazione IPv6 al GARR-LIR
§  La /32 assegnata al GARR-­‐LIR è una delle 512 subnet estra@e dalla 2001:600::/23 che cosDtuisce una delle classi IPv6 amministrate da RIPE inet6num: 2001:760::/32 netname: IT-­‐GARR-­‐20011004 descr: GARR Italian Academic and Research Network country: IT org: ORG-­‐GIRa1-­‐RIPE admin-­‐c: EV182-­‐RIPE tech-­‐c: GL965-­‐RIPE status: ALLOCATED-­‐BY-­‐RIR mnt-­‐by: RIPE-­‐NCC-­‐HM-­‐MNT mnt-­‐lower: GARR-­‐LIR mnt-­‐routes: GARR-­‐LIR source: RIPE §  Dalla 2001:760::/32 GARR-­‐LIR estrae le varie so@o-­‐classi /48 da assegnare agli EnD facenD parte della comunità GARR. #82
Registrazione sul DB RIPE
§  Ogni /48 assegnata agli EnD GARR dal GARR-­‐LIR viene registrata sul database di RIPE esa@amente come avviene per IPv4 inet6num: 2001:760:3402::/48 netname: Uni-­‐LE-­‐IPv6 descr: Università del Salento -­‐ Lecce country: IT admin-­‐c: FR7236-­‐RIPE tech-­‐c: GL965-­‐RIPE tech-­‐c: AC1292-­‐RIPE status: ASSIGNED remarks: This prefix is staDcally assigned remarks: To noDfy abuse mailto: [email protected] remarks: GARR -­‐ Italian academic and research network mnt-­‐irt: IRT-­‐GARR-­‐CERT mnt-­‐by: GARR-­‐LIR changed: [email protected] 20121106 changed: [email protected] 20150121 source: RIPE #83
Delega sotto l’ip6.arpa
§  GARR-­‐LIR, una volta o@enuta l’allocazione di spazio di indirizzamento IPv6, ha registrato del database RIPE un template per la delega dell’intera zona della /32 allocata in cui vengono indicaD i nameserver autoritaDvi. domain: 0.6.7.0.1.0.0.2.ip6.arpa descr: Reverse delegaDon for GARR sub-­‐tla admin-­‐c: EV182-­‐RIPE tech-­‐c: GL965-­‐RIPE zone-­‐c: GL965-­‐RIPE zone-­‐c: GP4562-­‐RIPE nserver: ns1.garr.net nserver: ns2.garr.net nserver: ns.ripe.net mnt-­‐by: GARR-­‐LIR source: RIPE #84
Aggiornamento dati reverse-lookup
§  Per le /48 assegnate agli utenD non è necessario registrare domain object nel database RIPE. §  Le deleghe verso i nameserver autoritaDvi delle utenze vengono definite nel file di zona dell’intera /32 gesDta da GARR-­‐LIR #85
Aggiornamento deleghe per il reverse-lookup
§  Le richieste di aggiornamento delle deleghe per il reverse devono essere inviate via email al GARR-­‐LIR (staff-­‐
[email protected]). §  Il GARR-­‐LIR controlla la corre@a configurazione del DNS. §  IL GARR-­‐LIR provvede a configurare la delega sul nameserver GARR autoritaDvo della 32 allocata da RIPE a GARR verso i nameserver autoritaDvi della /48. #86
Bookmarks e Riferimenti
#87
Contatti
E-­‐mail del GARR-­‐NIC: [email protected] E-­‐mail del GARR-­‐LIR: [email protected] Staff DNS: staff-­‐[email protected] Tel.: +39-­‐06.4962.2550 Fax: +39-­‐06.4962.2044 #88
BookMark
§ 
§ 
§ 
§ 
§ 
h@p://www.ripe.net : RIPE h@p://www.iana.org : IANA h@p://www.icann.org : ICANN h@p://www.nic.it : Registro h@p://www.eurid.eu: EURid #89