Newsgroup: it.comp.os.linux.sys
Titolo: Semplice chiarimento sui DNS e su dig

Ho un dominio "
foo.com
" attestato su un nameserver che non fa
recursion ma è autoritario solo per alcuni domini. (quindi nessuno, lo
usa come resolver)
un cliente, tramite pannello, imposta un cname di nome "prova" che
punta a "
www.google.com
."
se interrogo il nameserver con dig, ricevo un SERVFAIL, e se guardo i
log, sembra che dig cerchi di risolvere il cname usando lo stesso
server.
Se uso dig con +norec, tutto funziona.
E' normale questo comportamento? E' dig che cerca di risolvere i
record usando lo stesso nameserver? Se si, è normale ricevere dei
servfail richiedendo dei record che non puntano ad IP, configurati su
nameserver senza ricorsione attiva.
Domanda due:
il cliente configura la zona inserendo un host di nome
'
www.google.com
.' che punta a '127.0.0.1'
sulla carta non ci dovrebbero essere implicazioni, quel record non
sarà mai inviato come risposta, dico bene?
Mi piacerebbe avere conferma.

 sarà mai inviato come risposta, dico bene?
Dipende da che nameserver gestisce 'sta zona.
Bind sputerebbe nei log "ignoring out-of-zone data" e non caricherebbe
quelle entry.
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 quelle entry.
Nel mio caso, powerdns. Nei log non vedo nulla di anomalo, se non un
servfail
che poi ho scoperto essere inerente il punto precedente.
Ma nel caso il nameserver non ignorasse le entry 'out-of-zone' che
impatto
ci sarebbe? In teoria nessuno...

 ci sarebbe? In teoria nessuno...
Dipende da quali dati ci son in zona.
Se il dns li considerasse "veramente validi" potrebbe fornirli in
risposta a query che li "tirino in causa" e che finiscano da lui in
quanto authoritative per il dominio a cui la query � diretta.
Ad esempio, ipotizziamo che nella *tua* zona mydomain.tld ci sia:
$ORIGIN mydomain.tld
test			IN	CNAME	
www.google.com
.
www.google.com
.		IN	A	1.2.3.4
Chi interroghi il tuo DNS per il record test.mydomain.tld otterrebbe ad
esempio:
; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec test.mydomain.tld
;; global options: +cmd	
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16250
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6
;; QUESTION SECTION:
;test.mydomain.tld.             IN      A
;; ANSWER SECTION:
test.mydomain.tld.      86400   IN      CNAME   
www.google.com
.
www.google.com
.         86400   IN      A       1.2.3.4
Questo perch�, essendo il tuo authoritative in possesso del dato
"target" del CNAME, lo fornirebbe direttamente con l'obiettivo di
risparmiarti una query in pi�.
Causando tuttavia una poisoning della cache di chi lo interroga.
Ma dubito fortemente che powerdns si perda in 'ste cazzate.
Per altri DNS pi� sola non ci giurerei.


 Ma dubito fortemente che powerdns si perda in 'ste cazzate.
Si, si perde, il thread nasce proprio da qui.
(Faccio fatica a fare un esempio senza esporre dati reali, cosa
che ovviamente non posso fare. Ci provo)
Io ho una zona mydomain.tld gestita da un pirla mediante pannello di
controllo.
Il pirla ha configurato 
www.mioserver.it
. IN A 1.2.3.4
Tralasciamo il fatto che il pannello di controllo abbia consentito la
creazione di record fuori zona, un altro mio cliente mi ha detto di
non riuscire ad accedere a 
www.mioserver.it
.
questo secondo cliente ha un record cname siffatto:
host IN CNAME 
www.mioserver.it
.
e viene usato da un server web, che pesca i dati usando
host.dominiocliente.tld
In pratica, mi pare di aver visto che:
il server web (che utilizza nameserver differenti da quello
autoritario in questione) interroga
l'autoritario per verificare il puntamento di host.dominiocliente.tld
vede il cname ma non so per quale motivo, pdns spara fuori come
additional section anche
il valore di 
www.mioserver.it
 impostato erroneamente dal cliente
pirla.
Il poisoning sarebbe spiegato:
il pirla ha configurato un record fuori zona, pdns l'ha messo in
cache, un utente ignaro
a fatto la sua richiesta come al solito e pdns inizia a rispondere
pescando dalla cache
in comune con il record errato.
Questo significa che se nel server mettessi un record
"
www.microsoft.com
. IN A 127.0.0.1" e me lo interrogassi da solo
(mediante un cname come il tuo di prima), avvelenerei la cache in un
secondo, mettendo ko tutti gli altri.
Ma è una cazzata, sotto ogni punto di vista. Tralasciamo di nuovo il
bug del pannello che ha permesso l'inserimento del record fuori zona,
quale può essere il motivo per il quale un server dns debba servire
record fuori zona di default? Se mettessi "
www.microsoft.com
." nella
mia zona, andrebbe ignorata, almeno come settaggio predefinito.

 mia zona, andrebbe ignorata, almeno come settaggio predefinito.
Ed infatti PowerDNS ha il settaggio impostato a NO di default:
"out-of-zone-additional-processing:
Do out of zone additional processing. This means that if a malicious
user adds a '.com' zone to your server, it is not used for other
domains and will not contaminate answers. Do not enable this setting
if you run a public DNS service with untrusted users. Off by default."
Eppure ho ugualmente questo problema.

 pirla.
Ovvio (e nel caso di CNAME non è nemmeno "additional", fa proprio parte
della risposta).


 Apperò...
Ora devo capire come mai, nonostante la gestione dei dati fuori zona
sia disattivata (come giustamente lo è di default) io mi son ritrovato
con una cache contenente dati farlocchi.
Cosa potrebbe essere? se la gestione dei fuori zona non è attiva, un
record di nome "
www.google.it
." dovrebbe semplicemente essere ignorato
ed anche facendo
ciccio         IN CNAME 
www.google.it
.
www.google.it
. IN     A 127.0.0.1
non dovrebbe avere alcuna conseguenza.

 non dovrebbe avere alcuna conseguenza.
L'unica spiegazione è che la gestione dei dati fuori zona sia in realtà
attiva, perchè il default è diverso da quello che t'attendi o perchè
semplicemente non funziona correttamente.
O magari, ad esempio, è un flag che ha effetto solamente per determinate
tipologie di backend (file) in quanto agisce sul parser che carica la zona.
Con bind è così; ma bind supporta ufficialmente solo i file come
backend, quindi è *quasi* irrilevante (resta da vedere come si
comporterebbe in caso i dati fuori zona arrivino via AXFR; magari quando
ho tempo da buttare ci provo anche...)
Cmq, hai appena avuto la percezione diretta di come DNSSEC sia una
necessità tutt'altro che accademica. Nel tuo caso, poi, anche in assenza
di intenzioni malevole da parte dell'"attaccante"...


 di intenzioni malevole da parte dell'"attaccante"...
Sbagliando si impara....
Grazie a Dio il nameserver non è anche il resolver usato dai server
altrimenti a quest'ora mi sarei ritrovato con il culo fuori dalla
finestra
e $X server che non riuscivano più ad inviare posta verso gmail.
P.S: i nameserver in questione non sono gli stessi del mio precedente
thread,
questi son sempre stati tenuti separati dagli altri resolver e fan
solo da
autoritari per alcuni domini.