j0llyb0x

© j0llyb0x.org 2011-2023

[parte I] DNS, questo sconosciuto..

Tue 17 June 2014

Non puoi dire di conoscere una cosa in informatica(in realtà non potresti dirlo mai) finché non ti ci sporchi le mani. 

Cominciamo con un Dry run.. teoria del DNS: - Il servizio dns è nato perché in passato i pochi siti raggiungibili via internet erano gestiti in un unico foglio di testo che associava gli IP ai nomi, più semplici da ricordare. Con il boom di internet si è reso necessario un approccio più flessibile ed è nato un sistema distribuito di database di carattere "tree" per la gestione dei nomi a dominio: il DNS.

bind

Il portocollo ha varie implementazioni ma la più usata è senza ombra di dubbio BIND(9) ed è anche la mia scelta (anche se vorrò smanacciare un po con il simpatico dnsmasq che però ha uno scopo e un'implementazione differente da BIND.

BIND è attualmente la versione 9 ed è in sviluppo dagli anni 80'. questo articolo parla di DNS e, quando si parla di configurazioni si fa riferimento a BIND versione 9.x su ambiente Debian (nella parte II).

Come ho già detto, DNS è un protocollo implementato a vari livelli, per il quale esistono vari compiti da assolvere.

Quando viene fatta una query, un NameServer si può comportare nei seguenti modi, che possono essere sovrapposti o separati nei compiti:

Nel primo caso, il server possiede dei record DNS (A, TXT, PTR, MX etc..) gestiti direttamente da lui (o a livello secondario come slave), che fornirà su richiesta previa query nella propria cache. come detto, se un server è autoritativo puro, se gli si chiedesse un IP non presente nelle sue tabelle, egli dovrebbe risponderebbe picche (si vedrà che questo non è sempre vero).

Per fare un esempio pratico, possiamo usare dig (suite dnsutils) è capire meglio cosa sia un server autoritativo per un dominio e come dovrebbe comportarsi:

[root@newsun][~] 04:57:30
dig ANY google.com @ns1.google.com

; DiG 9.8.4-rpz2+rl005.12-P1 ; ANY google.com @ns1.google.com
; global options: +cmd
; Got answer:
; - HEADER - opcode: QUERY, status: NOERROR, id: 49650
; flags: qr aa rd; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 0
; WARNING: recursion requested but not available

; QUESTION SECTION:
google.com. IN ANY

; ANSWER SECTION:
google.com. 300 IN A 74.125.21.113
google.com. 300 IN A 74.125.21.101
google.com. 300 IN A 74.125.21.138
google.com. 300 IN A 74.125.21.102
google.com. 300 IN A 74.125.21.139
google.com. 300 IN A 74.125.21.100
google.com. 300 IN AAAA 2607:f8b0:4002:c06::71
google.com. 600 IN MX 10 aspmx.l.google.com.
google.com. 86400 IN TYPE257 \\# 19 0005697373756573796D616E7465632E636F6D
google.com. 345600 IN NS ns4.google.com.
google.com. 345600 IN NS ns3.google.com.
google.com. 600 IN MX 30 alt2.aspmx.l.google.com.
google.com. 600 IN MX 40 alt3.aspmx.l.google.com.
google.com. 600 IN MX 50 alt4.aspmx.l.google.com.
google.com. 345600 IN NS ns2.google.com.
google.com. 345600 IN NS ns1.google.com.
google.com. 3600 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
google.com. 600 IN MX 20 alt1.aspmx.l.google.com.
google.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 2014021800 7200 1800 1209600 300

; Query time: 14 msec
; SERVER: 216.239.32.10#53(216.239.32.10)
; WHEN: Tue Jun 17 04:57:31 2014
; MSG SIZE rcvd: 497

Ecco un esempio di query Ad un NameServer autoritativo per la sua zona; la query è stata fatta all'indirizzo ip del DNS server primario di google, richiedendo qualsiasi record pertitnente al nome a dominio google.com.

La risposta del server mostra chiaramente che lui stesso (il server contattato tramite dig) è il detentore della zona dns per google.com come si vede nel flag AA (autoritative answer) e dal record SOA/NS per google.com che mostra ns1.google.com come Server DNS autoritativo per il dominio.

Se un server non è autoritativo per la zona, non vuol dire che non possieda in cache dei record DNS, può succedere infatti che tali record siano presenti e la cache è il primo luogo dove il server guarda (a parte la propria zona autoritativa) prima di compiere qualsiasi altra azione. In questo caso la risposta sarà presa dalla cache che in genere viene gestita in concomitanza di Nameservers Forwarder/Ricorsivi.

Per servire un contenuto dalla cache un NameServer deve prima aver ricevuto il record da qualcuno :) e questo è uno dei tre metodi di interazione che un DNS server può avere con altri Server nel caso gli sia fatta una query alla quale non sa rispondere direttamente. Se il Server è configurato per avere dei forwarders, egli "girerà la query" al DNS server preposto, in attesa della risposta da servire. In genere, se presente, quest'opzione è preferita alla ricorsione diretta. Dall'altro lato, un server Forwarder non è altro che un NameServer Ricorsivo (non vedo l'utilità che non lo sia) che fa da spoiler per un DNs interno in modo da separare fisicamente query interne e query esterne. Ancora un Forwarder può essere impiegato per diminuire l'area di esposizione di una rete interna settando per tutti gli altri NS un unico forwarder che farà le query non autoritative per loro.

è qui che entrano in gioco i server NS ricorsivi: Questi server permettono di fare query ricorsive per nomi/IP per i quali non sono autoritativi. Ad esempio, i DNS pubblici di Google, sono NS non autoritativi (nel caso ve lo foste chiesto come me, Google non hosta le sue zone sui server pubblici che ha regalato a noi :) ). Ovviamente questi server avranno anche una cache (a meno di averla disabilitata) ma il succo è che, per ogni record richiesto, a meno di cache, faranno il percorso dell'alberatura DNS fino a fare la query al corretto SOA/NS per quel particolare nome a dominio, restituendo il risultato richiesto. Un server DNS che fa da Forwarder sarà quasi sicuramente ricorsivo e la query in questione può essere osservata sempre utilizzando dig:

[root@newsun][/etc] 
05:59:13 # dig google.com +trace

; DiG 9.8.4-rpz2+rl005.12-P1 ; google.com +trace
; global options: +cmd
. 3600000 IN NS G.ROOT-SERVERS.NET.
. 3600000 IN NS B.ROOT-SERVERS.NET.
. 3600000 IN NS I.ROOT-SERVERS.NET.
. 3600000 IN NS E.ROOT-SERVERS.NET.
. 3600000 IN NS H.ROOT-SERVERS.NET.
. 3600000 IN NS C.ROOT-SERVERS.NET.
. 3600000 IN NS L.ROOT-SERVERS.NET.
. 3600000 IN NS D.ROOT-SERVERS.NET.
. 3600000 IN NS J.ROOT-SERVERS.NET.
. 3600000 IN NS K.ROOT-SERVERS.NET.
. 3600000 IN NS M.ROOT-SERVERS.NET.
. 3600000 IN NS F.ROOT-SERVERS.NET.
. 3600000 IN NS A.ROOT-SERVERS.NET.
; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 644 ms

com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
; Received 500 bytes from 192.36.148.17#53(192.36.148.17) in 693 ms

google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
; Received 164 bytes from 192.54.112.30#53(192.54.112.30) in 429 ms

google.com. 300 IN A 74.125.21.113
google.com. 300 IN A 74.125.21.100
google.com. 300 IN A 74.125.21.138
google.com. 300 IN A 74.125.21.102
google.com. 300 IN A 74.125.21.101
google.com. 300 IN A 74.125.21.139
; Received 124 bytes from 216.239.32.10#53(216.239.32.10) in 14 ms

In breve, il DNS server (o resolver interno) ha caricato la lista dei root server di internet; successivamente ha lanciato una query ad uno di loro (192.36.148.17 - non ricorsivo) ricevendo la lista dei NameServer autoritativi per lo spazio dei nomi più ampio (.com); ora viene lanciata un'altra query identica, ma come target avremo uno degli NS server autoritativi per la radice .com (192.54.112.30 - sempre non ricorsivo) che restituirà la lista degli NS autoritativi per il successivo spazio dei nomi (.google.); finalmente abbiamo trovato gli indirizzi che "devono" sapere che indirizzo ha google.com; la query viene ora fatta all'NS di google ( 216.239.32.10 - non ricorsivo :) ) che ci restituisce finalmente i record A (default) della nostra query (74.125.21.*) da notare che google usa DNS round robin per il bilanciamento del carico sui frontend, ma questa è un'altra storia :).

Alcuni NS (in teoria tutti quelli autoritativi per fattori di sicurezza) non possono essere utilizzati per trovare i record al di fuori delle proprie zone di gestione autoritative. Gli esempi più banali sono appunto i root server di Internet. Questi server mantengono un database autoritativo di tutti i NS che gestiscono lo spazio dei nomi di primo livello (.com,.org,.it etc) ed hanno già un bel da fare a soddisfare le richieste del mondo rispetto a questi indirizzi. Questi ed altri server con grande carico di lavoro si limitano a gestire query iterative per le quali sono direttamente responsabili.

Come si è visto nell'esempio precedente con dig, i root server non hanno fatto il lavoro per noi, restituendoci il risultato (come farebbe un forwarder o un NS ricorsivo) ma dandoci gli indirizzi del primo livello utile a lui demandato (in questo caso gli indirizzi di chi gestisce i domini sotto .com).

Questa è una panoramica parziale del mondo DNS e dei tipi di NameServers e sicuramente ci saranno delle imprecisioni che, spero, chi passerà di qua saprà puntualizzare.

A fondo metto alcune references che mi hanno aiutato a capire come funziona il tutto; lascio per la seconda parte le eventuali configurazioni e i problemi più o meno banali che ho incontrato nei miei esperimenti.

RFC1034 e RFC1035

slide sul DNS

differenti tipi di query DNS

Tags: