Ogni dispositivo su Internet è identificato da almeno un indirizzo IP. Solitamente ogni sistema è identificato anche da un hostname (una stringa di al più 255 caratteri).
Gli indirizzi IP possono essere molteplici, così come gli hostname.
samba.ing.unimo.it
Un hostname è una sequenza di label separate da spazio. Ogni label può avere al più 63 caratteri.
In origine erano consenti solo simboli alfanumerici. IDN - Internationalized Domain Name - ammette anche caratteri non strettamente ASCII/latini.
Non c'è alcun vincolo forte tra hostname e IP.
La struttura degli hostname è gerarchica. Al contrario di IP l'importanza di ogni label all'interno della gerarchia va da sinistra a destra.
Ad esempio: sun3.dii.ing.unimore.it
it- country codeunimore- dominio di primo livelloing- facoltà di ingegneria- ...
Quello sopra riportato è un hostname canonico o FQDN - Fully Qualified Domain Name.
FQDN = tutto l'hostname nel suo complesso (host relativo e dominio dell'host) Host relativo = informazione più specifica, a sinistra dell'hostname Dominio = parte a sinistra dell'host relativo
Prendendo come esempio: sun3.dii.ing.unimore.it
it- TLD - Top Level Domainunimore- SLD - Second Level Domain- ...
Tipicamente SLD identifica un'organizzazione, mentre il TLD identifica uno stato (countrycode).
Il livello dal terzo in poi potrebbero essere assenti e sono sotto il totale controllo dell'organizzatore. Non hanno tanta rilevanza. Non hanno quindi una nomenclatura ben definita.
- gTLD - Generic TLD - identificano uno scopo comune
- com
- edu
- org
- ccTLD - Contry Code TLD - identificano una nazione
- iTLD - Infrastructure TLD - usato per il funzionamento interno del sistema DNS
- .arpa
- uTLD - Unsponsored TLD - identifica comunità che seguono le regolamentazione ICANN
- .eu
- .info
- .biz
L'ICANN permette di registrare il proprio TLD alla modica cifra di 200k$ di inaugurazione + 30k$ di rinnovo. Eg: .goog, .youtube
Lista di tutti i TLD: https://data.iana.org/TLD/tlds-alpha-by-domain.txt
La gerarchia di nomi forma un albero radicato in .
Il dominio google.com equivale a google.com.
Il punto all'estrema destra diventa la radice dell'albero dei nomi DNS.
Perché? favoriscono l'usabilità delle reti associando a indirizzi IP hostname mnemonici
Motivazioni più tecniche sono:
- possibilità di hardcodare l'hostname in software senza doverli aggiornare/ricompilare ogni volta che l'indirizzo IP del servizio cambia.
- possibilità di associare ad uno stesso server più servizi, identificati dall'hostname richiesto.
Lookup: da nome a indirizzo Reverse-lookup: da indirizzo a nome
DNS è pensato anche per reverse lookup più o meno efficienti.
- Sono consentiti caratteri "a-z", oppure interi 0-9 oppure "-"
- Vietato il prefisso "xn--"
- Case insensitive
Registrare un dominio che assimiglia o contiene il brand di un'azienda per provare a rivenderlo o per perpetrare attacchi informatici.
L'adozione di regole come ACPA - Anticybersquatting Protection Act - mirano a regolare la scelta di nomi per evitare "attacchi" di cybersquatting.
Identifica simboli Unicode differenti all'occhio umano, ma con rappresentazioni binarie diverse.
Questa caratteristica di Unicode viene usata per fare "attacchi al dominio", da quando questa codifica è stata introdotta per la rappresentazione di hostname.
Implementato mediante un'architettura distribuita: diversi nameserver sono distribuiti su Internet. Le competenze sono gerarchicamente delegate.
Strategie per aumentare performance e scalabilità:
- caching
- distribuzione
- protocollo UDP per le query DNS
TCP era usato solo per aggiornamento di record tra nameserver. Ora, in realtà, è possibile usare DNS over TLS o HTTPS, che si appoggiano a TCP.
Il nome di ogni label/livello identifica che il server gestisce i domini al di sotto di esso:
- root nameserver (
.) -> radice dell'albero dei domini - TLD nameserver -> relativi ai domini top-level
- SLD nameserver
#Attenzione non confondere questi server con i local nameserver. Questi ultimi non hanno autorità, ma un ruolo prettamente tecnico.
La gestione materiale e concettuali sono differenti. Si pensi ad avere realmente un solo nameserver radice non replicato.
I root namserver B-M (esiste anche il root nameserver A) sono costituiti da 130 macchine in più di 50 paesi diversi. Si tratta di datacenter che gestiscono i TLD che iniziano con la lattera di competenza.
#Vedi RFC 2870
I nameserver TLD devono registrarsi presso i root nameserver. Durante il lookup il root nameserver indirizza al corretto TLD ns.
A sua volta nel TLD ns si trovano record su chi gestisce i SLD
Quindi: non è che ogni ns mantiene una lista di tutti i nomi e tutti gli hostname disponibili. La struttura è ramificata. Ogni nameserver è responsabile di un certo livello della gerarchia.
#Attenzione
Il termine zona identifica i sottodomini di cui il ns è responsabile.
Ad esempio: dii.ing.unimore.it -> unimore non è obbligata a gestire mediante una struttura ramificata i suoi sottodomini. Può segnalare che gestisce una lista di sottodomini. Si dice che unimore gestisce la zona ing. Zona e domini possono non coincidere.
Ci sono due tipi di ns che possono fornire dati autoritativi (architettura ridondante):
- master server (primary) - leggono i dati su una zona dal master file
- secondary server - si mantengono aggiornati con policy definite nel protocollo DNS (informazioni scambiate affidabilmente mediante il protocollo TCP)
Authoritative namserver: ns autoritativo relativamente ad una zona
In DNS i ns gestiscono i record delle risorse -RR. Una risorsa può essere hostname, indirizzo, ecc.
Esistono decine di tipi di resource record, anche se la maggior parte non viene comunemente usata:
- TXT
- A
- NS
- CNAME
- AAAA
- etc.
RR types:
- A - record di host address e indirizzo IP - mappa canonical hostname e indirizzi IP
- NS - memorizza il ns autoritativo per una determinata zona - mappa dominio e namserver
- SOA - Start Of Authority - si trovano informazioni miscellanee, di governance, poco tecniche
- MX - Mail eXchanger - memorizza l'indirizzo (o hostname) del server mail che gestisce la posta per un certo sottodominio
Eg: se risolvo un dominio dal browser web, uso il record A. Se dal client di posta, uso il record MX.
... RR Types:
- CNAME - Canonical Name - memorizza gli alias ad un hostname (aka hostname to hostaname). Eg: più hostname puntano allo stesso server (stesso IP); una soluzione subottima è l'inserimento di 3 record A. L'ideale è avere un A e tanti CNAME.
- AAAA - IPv6 A record - analogo dei record A per IPv6
- TXT - arbitrary TeXT - testo arbitrario in formato ASCII. Viene oggi usato per funzionalità di alcuni protocolli applicativi, sebbene non sia nato come campo funzionale. Conserva informazioni tecniche accessorie.
- PTR - Pointer to another node - mappano indirizzi IP in hostname (vedi dig)
- nome del dominio
- valore
- TTL - tempo di validità dell'informazione, comunicato dal ns
- classe
- tipo
#Nota a differenza di protocolli come ARP al logica di caching è gestita dal resource record.
Un valore TLL = 0 viene usato quando un ns vuole essere consultato ad ogni risoluzione. Può servire in un contesto dove le informazioni cambiano molto velocemente.
Nameserver = server che supporta protocollo DNS. Resolver = client che supporta protocollo DNS. Eg: dig è un resolver.
Ogni resolver deve essere a conoscenza di almeno un local nameserver.
Nei sistemi Linux: /etc/resolv.conf
128.113.1.5
128.113.1.3
Tipicamente ridondanza con server primario e secondario.
Esistono due tipi di query:
- ricorsive
- iterative
Application -gethostbyname()-> resolver [nslookup] -request-> local ns
| host | Internet |
Una query si dice ricorsiva quando il resolver chiede ad un local nameserver di risolvere a sua volta una query; il ns si trasforma quindi in resolver.
Il protocollo prevede che nel lookup venga inviato il FQDN e che ogni server risponda al meglio delle sue potenzialità. Ad esempio il root nameserver non potrà fare nulla di meglio che restituire il ns di un SLD.
Il resolver a monte riceverà una risposta già competa, che potrà essere eventualmente anche vuota. Il punto è: non deve eseguire ulteriori iterazioni del protocollo DNS (la risposta non è parziale).
Nelle query iterative il resolver si aspetta di ricevere una risposta parziale. Continuando ad iterare con il protocollo DNS si arriva ad una risposta finale.
Con dig l'opzione +norecurse risolve le query iterativamente.
#Sperimenta con dig -4 +norecurse +trace www.unimore.it. L'opzione +trace fa comportare dig come un local namserver.
Tirando le fila, un local nameserver è un server installato localmente per risolvere le query ricorsivamente.
Posso impostare il flag di query ricorsiva anche verso un root ns, ma ovviamente verrà scartata/non portta a compimento.
Un client per consultare nameserver DNS.
dig unimore.itLa risposta si trova nella sezione ANSWER SECTION
#Nota il punto finale che indica la presenza di una radice comune
;: ANSWER SECTION
www.unimore.it CNAME www-2-122.unimo.it
www-2-122.unimo.it A 155.185.2.122
;; AUTHORITY SECTION
gwa.unimo.it NS ns1.unimo.it
gwa.unimo.it NS ns2.unimo.it
gwa.unimo.it NS ns1.garr.it
;; ADDITIONAL SECTION
ns1.garr.net A 193.206.141.38
ns1.unimo.net A 155.185.2.2
ns2.unimo.net A 155.185.2.5
Senza opzioni viene sottintesa una query verso il record A.
Se invece lancio: dig MX unimore.it
unimore.it. 86400 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM.
unimore.it. 86400 IN MX 10 ALT3.ASPMX.L.GOOGLE.COM.
unimore.it. 86400 IN MX 1 ASPMX.L.GOOGLE.COM.
unimore.it. 86400 IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.
Indica che la posta è data in outsourcing a Google. Più hostname sono mappati sullo stesso dominio; la stessa logica posso vederla applicata anche ad altri record.
Serve per la distribuzione del carico a livello geografico. Più alternative diverse (ALT) servono proprio alla distribuzione del carico. Di default uso la prima informazione restituita: il ns potrebbe essere configurato per rispondere con un ordine differente per applicare regole di distribuzione del carico.
Potrei ricevere risposte diverse per il record A.
Reverse lookup:
dig -x 155.185.1.2Risposta: 5.1.185.155.in-addr.arpa. 86400 IN PTR ns2.unimo.it.
- TLD:
arpa - SLD:
in-addr. È il SLD usato appositamente per risolvere reverse lookup.
La risoluzione inversa non è gestita mediante un prtocollo speciale. dig trasla il comando riportato sopra con:
dig PTR 2.1.185.155.in-addr.arpa#Nota la reverse domain notation: serve per mantenere consistente la logica di importanza gerarchica degli indirizzi DNS. In questo modo ottengo una logica gerarchica compatibile con i nomi DNS. Ad esempio 185.155.in-addr.arpa gestisce tutti i sottoindirizzi di Unimore.