[Articolo] Il DNS: come funziona la risoluzione dei nomi

Oggi vediamo cosa succede quando sulla barra del browser scriviamo il nome di un sito, come ad esempio http://www.google.it, e quale arcano procedimento ci permette di collegarci realmente al sito desiderato.

Difficoltà articolo (0->10): 4

Oggi vediamo cosa succede quando sulla barra del browser scriviamo il nome di un sito, come ad esempio http://www.google.it, e quale arcano procedimento ci permette di collegarci realmente al sito desiderato.

google.it
Apertura di http://www.google.it da browser.

Alla base di tutto il processo si trova il protocollo DNS, il cui acronimo è Domain Name System, che è il sistema che si occupa di tradurre il nome completo di una risorsa di rete (URL) nel relativo indirizzo IP, in modo univoco. Dunque, questo protocollo ricopre un ruolo fondamentale per Internet e più in generale per una buona parte dei servizi di rete.

Ricordiamo che ogni dispositivo o risorsa collegata ad una rete (laptop, smartphone, sito web, server, …) deve possedere un indirizzo numerico chiamato indirizzo IP, nella forma x.x.x.x e che identifica in modo univoco quel dispositivo, un po’ come i numeri telefonici sono associati in modo univoco ad un telefono (non possono esistere 2 cellulari con lo stesso numero!).

Prendiamo un esempio di navigazione su Internet: vogliamo aprire nel browser la pagina di Google (www.google.it), ma cosa succede realmente? Il nostro sistema operativo manderà una richiesta al server DNS: “Ehi, devo andare su http://www.google.it e non conosco il suo indirizzo IP, qual’è?”. Il server DNS ci risponderà: “L’indirizzo IP di http://www.google.it è 173.194.35.23, puoi usare questo!”. Dunque, il nostro sistema operativo userà questo indirizzo IP per contattare il sito (il server web che gestisce il sito) e richiedere la pagina desiderata.

dns-richiesta-google
Risoluzione http://www.google.it in indirizzo IP.

Molto famosi sono i server DNS di Google i quali hanno indirizzi che possono essere facilmente memorizzabili, e che sono liberamente utilizzabili da ciascuno di noi:

  • IP del DNS primario: 8.8.8.8
  • IP del DNS secondario 8.8.4.4

Nulla vieta di usare altri server DNS che non siano quelli di Google. Per le linee Internet casalinghe, tipicamente viene usato un server DNS del proprio fornitore di connettività, che ci viene assegnato automaticamente dal fornitore:

Config DNS ADSL
Parametri di rete forniti in automatico da un fornitore italiano di rete.

E’ chiaramente comprensibile che il DNS sia un sistema fondamentale per il corretto funzionamento di Internet, senza il quale ci risulterebbe molto più difficoltosa la navigazione e l’utilizzo di moltissimi sistemi. Pensate per esempio a dover ricordare anche solamente alcuni dei vostri siti preferiti tramite indirizzo IP in questo modo:

Tutto bello, ma ora se vogliamo trovare l’indirizzo IP associato ad un nome, come posso fare? Qual’è il procedimento inverso? Semplice, ci sono vari strumenti di sistema che possono aiutarci in questo, tra cui:

  • ping
  • nslookup
  • dig (su Linux)
ping www.facebook.it
ping su Windows.
nslookup www.facebook.it
nslookup su Windows.

Adesso che abbiamo visto cos’è e come funziona il DNS, andiamo un po’ più nel dettaglio per i curiosi ;-)…

Abbiamo detto finora che il server DNS esaudisce ogni nostra richiesta traducendo un nome in indirizzo IP, questo è vero, ma non del tutto. Quando facciamo una richiesta, il primo ad essere contattato non è il server DNS, ma un file specifico all’interno del proprio sistema operativo, qualunque sia il sistema, Windows, MacOS, o Linux. Il file in questione si chiama file hosts, su Windows si trova  di default all’interno della cartella di sistema “C:\Windows\System32\drivers\etc\” mentre su Linux in “/etc/“. Pertanto, quando vogliamo aprire una determinata pagina web, prima viene controllato questo file, per vedere se l’URL è contenuto al suo interno e:

  • se il file hosts contiene la corrispondenza URL -> IP, allora viene usato questo indirizzo IP per aprire la pagina desiderata.
  • se il file hosts non contiene l’URL, allora viene contattato il server DNS a cui viene chiesto di risolvere l’URL in indirizzo IP.

Vediamo com’è fatto il file hosts, e ricordiamo che possiamo divertirci inserendo al suo interno tutto ciò che vogliamo, se abbiamo necessità particolari.

Windows file hosts
File hosts su Windows.

Il file hosts ha una sua formattazione, come spiegato all’inizio del file una volta aperto, e viene dunque consultato prima di inoltrare la

Dobbiamo sapere inoltre che l’associazione di un nome con un indirizzo IP può non essere singola, ma un nome potrebbe avere associati più indirizzi IP. Come mai? Cosa succede allora? Questo avviene in genere per siti importanti, relativi ad enti o grandi realtà, quando dietro di essi ci sono non un pc o comunque una solo server, ma spesso molti sistemi/server differenti che hanno la funzionalità di:

  • bilanciatori di carico
  • ridondanza

Immaginate se dietro http://www.google.it ci fosse un solo server a rispondere alle richieste di milioni di persone che si collegano. Cosa succederebbe se dovesse avere un problema o un blocco? Saremmo tutti fermi non potendo più aprire la pagina di Google! Ad esempio al sito di Ducati corrispondono 2 indirizzi IP principali:

nslookup www.ducati.it
IP multipli associati ad un sito.

Con questo articolo abbiamo visto solo la punta dell’iceberg del protocollo DNS e del suo funzionamento, ma per approfondimenti ecco alcuni link:

roghan

Come risolvere i problemi di connessione – parte 1

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…). […]

Spesso capita che la rete non funzioni, e ci chiediamo quale e dove possa essere il problema. E’ il nostro sistema che non va? E’ il server che non risponde? E’ la trasmissione che non funziona? Insomma ci sono sempre tante domande e non sempre è immediato trovare la risposta, e finiamo per cambiare parametri e impostazioni nel tentativo di ripristinare la connessione! Gli utenti più inesperti poi finisco per installare svariati tipi di software che promettono di ripristinare la connessione e di sistemare tutto, come questo Connectivity fixer. Non ci sono programmi più inutili e magari dannosi (chi ha detto spyware?! Io no ;-)…).

Questo post rappresenta invece la prima parte di un altro post che avevo scritto qualche tempo fa, in cui spiegavo come fare troubleshooting della rete e verificare il collegamento ad Internet. In questo articolo invece esaminiamo il problema partendo dalla connessione alla rete locale, e senza far uso di risoluzioni DNS.

 

Prendiamo come esempio l’architettura di rete visibile in figura, e supponiamo di essere il sistema Bob con indirizzo IP 172.17.10.3 e di voler contattare la macchina Server con indirizzo 172.17.30.2. Nell’immagine non ho specificato le subnet per semplificare il tutto e renderlo fruibile anche a chi può avere meno conoscenze informatiche, comunque possiamo assumere che la subnet sia /24, uguale per ogni indirizzo.

diagramma_rete
Diagramma di rete

Come è visibile dal grafico si tratta di una piccola rete, tuttavia il problema può facilmente essere esteso ad una rete molto più grande come anche ad Internet (semplicemente non ci sarà un solo router tra sorgente e destinazione ma una serie di N dispositivi, come backbone, …). Vediamo i passi da fare per controllare il funzionamento della rete dal punto di vista di Bob:

  1. Test del loopback. Apriamo un terminale (prompt cmd in Windows, shell in Linux e MacOS) e facciamo ping verso 127.0.0.1.
    $ ping 127.0.0.1
    PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.773 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.125 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.083 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.080/0.265/0.773/0.293 ms

    Questo è l’indirizzo di loopback e se il risultato è positivo significa che lo stack TCP/IP è stato inizializzato correttamente. In caso invece di fallimento il servizio che gestisce lo stack TCP/IP deve essere ripristinato all’interno del sistema operativo. Per effettuare il ripristino dello stack in Windows è possibile consultare questo link, mentre per Linux quest’altro.

  2. Test della scheda di rete. Adesso facciamo ping verso l’indirizzo IP del sistema locale, nell’esempio 172.17.10.3.
    $ ping 172.17.10.3
    PING 172.17.10.3 (172.17.10.3) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.111 ms
    64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.079 ms
    64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.080 ms
    64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.078 ms
    --- 127.0.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3001ms
    rtt min/avg/max/mdev = 0.078/0.087/0.111/0.013 ms

    Se con il ping vengono ricevute le risposte significa che la NIC funziona correttamente così come i driver/moduli di sistema, ma ciò non indica che la rete è esente da problemi quali cavi rotti o collegamenti interrotti. Un esito invece negativo potrebbe essere indice di scheda di rete guasta o di driver/moduli non installati correttamente. Provate a riavviare il sistema e, su Windows, a reinstallare i driver, mentre su Linux ad aggiornare il kernel e riavviare moduli e servizi secondo le istruzioni a questo link.

  3. Test del gateway. Ora è in turno del gateway/router. Effettuate il ping verso il default gateway per testare la comunicazione nella rete locale, nell’esempio 172.17.10.1.
    $ ping 172.17.10.1
    PING 172.17.10.1 (172.17.10.1) 56(84) bytes of data.
    64 bytes from 192.168.139.2: icmp_req=1 ttl=128 time=0.255 ms
    64 bytes from 192.168.139.2: icmp_req=2 ttl=128 time=0.237 ms
    64 bytes from 192.168.139.2: icmp_req=3 ttl=128 time=0.241 ms
    64 bytes from 192.168.139.2: icmp_req=4 ttl=128 time=0.219 ms
    --- 192.168.139.2 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 0.219/0.238/0.255/0.012 ms

    Un esito negativo significa che c’è un problema o nella trasmissione dei dati (cavo rotto/scollegato), o nel default gateway che non è in grado di elaborare le richieste, oppure un blocco delle richieste da parte di un firewall o altro dispositivo interconnesso tra Bob e il default gateway (switch, hub, AP, …).

  4. Test del server remoto. Infine, se tutti i 3 punti precedenti hanno avuto esito positivo, testiamo la connessione verso il server remoto, nel nostro esempio  172.17.30.2.
    $ ping 172.17.30.2
    PING 172.17.30.2 (172.17.30.2) 56(84) bytes of data.
    64 bytes from 172.20.0.1: icmp_req=1 ttl=128 time=1.46 ms
    64 bytes from 172.20.0.1: icmp_req=2 ttl=128 time=0.913 ms
    64 bytes from 172.20.0.1: icmp_req=3 ttl=128 time=2.40 ms
    64 bytes from 172.20.0.1: icmp_req=4 ttl=128 time=0.714 ms
    --- 172.20.0.1 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3005ms
    rtt min/avg/max/mdev = 0.714/1.375/2.407/0.657 ms

    Se l’esito è negativo significa che il problema è da ricercarsi nella rete remota. Inoltre, nel caso in cui sia possibile raggiungere la rete remota con il ping, sarebbe ideale poter replicare i test partendo dal server remoto verso il sistema sorgente.

Nel caso di connessione a Internet (e non locale) anche se tutti e 4 i punti hanno avuto esito positivo la comunicazione potrebbe non funzionare. In questo caso il problema potrebbe essere il servizio DNS, e rimando alla seconda parte dell’articolo.

roghan

VMware HA e nodi isolati

Vedremo in questo post il comportamento di un cluster virtualizzato in cui è stata abilitata la funzionalità HA. Da ricordare che un cluster può essere configurato unicamente tramite un vCenter Server, che resta necessario per il corretto funzionamento di funzionalità quali vMotion e DRS, ma non per l’HA: se il vCenter Server si blocca o ha un guasto, l’HA è comunque garantita per tutti i nodi del cluster. […]

Vedremo in questo post il comportamento di un cluster virtualizzato con VMware in cui è stata abilitata la funzionalità HA. Da ricordare che un cluster può essere configurato unicamente tramite un vCenter Server, che resta necessario per il corretto funzionamento di funzionalità quali vMotion e DRS, ma non per l’HA: se il vCenter Server si blocca o ha un guasto, l’HA è comunque garantita per tutti i nodi del cluster.

ha_p2p
Interrogazione dei nodi in un cluster con HA

L’architettura di funzionamento su cui è basata l’HA è di tipo p2p, ossia ogni nodo effettua a intervalli regolari un ping verso ogni altro nodo del cluster e anche verso il gateway. I ping vengono effettuati dalla scheda di management di un nodo e verso la management di ogni altro nodo (Service Console nel caso di ESX e CLI di management per ESXi). Il funzionamento dell’HA è quindi strettamente legato al networking e alle schede di rete, e qualora la scheda di rete della management di un nodo si guasti il nodo stesso diventa isolato. Studiamo questo caso:

  1. ogni nodo controlla se ogni altro nodo è raggiungibile;
  2. se in un nodo si guasta la scheda di rete di management questo diventa isolato;
  3. di default, un nodo isolato spegne tutte le sua macchine virtuali.

Il comportamento di default potrebbe essere ragionevole nel caso in cui un nodo abbia schede di rete ridondate per la management, ma è in generale altamente consigliato cambiare l’impostazione default. Proviamo a immaginare cosa succederebbe se si guastasse uno switch fisico a cui sono collegati tutti i nodi e pure il gateway? Tutti i nodi risulterebbero isolati, con la conseguenza che ogni nodo spegnerebbe tutte le sue macchine virtuali! E’ una situazione assolutamente da evitare. Pertanto è necessario modificare l’impostazione host isolation response durante la configurazione del cluster, visibile alla schermata seguente:

ha_vcenter
Modificare impostazioni default

Riepilogando, è buona norma modificare il comportamento default di un cluster HA per quanto riguarda l’isolamento del nodo, ed inoltre è buona cosa ridondare la NIC di management.

roghan

%d blogger hanno fatto clic su Mi Piace per questo: