Newsgroup: it.comp.os.linux.sys
Titolo: DNS: risoluzione corretta in caso di risposta con record CNAME e A corrispondente

Salve, spero di non essere OT.
 
Ho creato in C++ un dns-resolver che funga da cache per la mia rete. 
Da oggi non risolve correttamente 
www.microsoft.com
.
 
La ragione ï¿œ che, traversando i vari server, riceve questa risposta:
dig 
www.microsoft.com
 @
213.199.180.53
 
[...]
;; ANSWER SECTION:
www.microsoft.com
.      900     IN      CNAME   
toggle.www.ms.akadns.net
.
 
toggle.www.ms.akadns.net
. 900   IN      A       207.46.31.61
toggle.www.ms.akadns.net
. 900   IN      A       65.55.39.12
 
Sostanzialmente il mio programma vede che 
www.microsoft.com
. 
corrisponde a 
toggle.www.ms.akadns.net
. Il server upstream fornisce 
giï¿œ in risposta la risoluzione di quest'ultimo ed il mio programma ï¿œ 
felice cosï¿œ. Il problema ï¿œ che in questo modo non finisco sul sito 
della microsoft ma su bling (misteri...).
 
Il comportamento descritto sopra ï¿œ corretto oppure devo modificare il 
mio programma affinchï¿œ, in questa circostanza,  ignori i record A e 
risolva comunque autonomamente 
toggle.www.ms.akadns.net
. cosï¿œ come 
fatto da altri programmi e dallo stesso DNS di google?
 
Grazie mille.

 da altri programmi e dallo stesso DNS di google?
 
A prescindere che secondo me hai letto poco le RFC, la palla di cristallo 
mi suggerisce che il problema non stia nel resolver o nella risposta DNS 
quanto nel fatto che nella richiesta HTTP non ci metti l'header Host.
 
Il che sposta il tuo studio, dopo un doveroso ripasso, dalle RFC 
riguardanti DNS, EDNS etcc a quelle riguardanti HTTP/1.0 e HTTP/1.1
 
Oppure usa c-ares come resolver e libcurl che fanno tutto loro senza 
reinventare la ruota.
 

 reinventare la ruota.
 
Poi mi spiegherai che razzo c'entra il protocollo HTTP, ma transeat.
 
Per quanto riguarda libcurl non me ne faccio nulla, il mio programma è 
un dns cache/resolver che serve la mia rete. L'ho fatto come pratica e 
per studio, non intendo certo proporlo come alternativa a named o unbound.
 
 
 
 
 

 malfunzionamento dei DNS Microsoft.
 
Update: il signor Microsoft ha rimesso a posto le cose, ora quel 
server non restituisce più quei record A spuri, si limita a restituire 
solo il CNAME:
 
dig 
www.microsoft.com
 @
213.199.180.53
 
 
;; ANSWER SECTION:
www.microsoft.com
.      3600    IN      CNAME   
toggle.www.ms.akadns.net
.
 
 
Però la domanda resta: un resolver che riceve da un server 
autoritativo una risposta come quella del primo messaggio deve 
ignorare i record A e procedere alla risoluzione del CNAME in 
autonomia o può fidarsi e prendere per buoni i pluricitati record A?
 

 prendere per buoni i pluricitati record A?
 
 
Di fatto, prendere per buoni i dati che non hai chiesto può portarti a
considerare buoni dei dati falsi.
 
Basta che il DNS autoritativo per il dominio che interroghi fornisca un
CNAME ad una risorsa di altro dominio, e ci attacchi dei dati forgiati
per tale risorsa...
 
 
poc.bofhland.org
.	3600	IN	CNAME	
www.google.com
.
www.google.com
.		600	IN	A	127.0.0.1
 
... e BUM.
 
 
Son dati che andrebbero sempre buttati, a meno che il nameserver che li
fornisce non sia autoritativo per entrambi i domini.
 
 
Almeno se la domanda è stata fatta direttamente all'autoritativo: se la
tua implementazione non è un recursor ma uno stub resolver, e la domanda
la stai ponendo al recursor, in tal caso il recursor ti fornirà a sua
volta (di norma) l'informazione aggiuntiva.
 
In tal caso, vale la pena di considerarla valida, dato che ti evita il
RTT necessario a rifare la stessa domanda allo stesso server e dato che,
interrogando quel recursor, stai comunque già affidando allo stesso la
veridicità di quei dati.
 
 
 
(il tutto, parlando di "normale DNS", senza aprire nemmeno il capitolo
DNSSEC).
 
 
 
 

 unbound.
 
named o unbound sono altri livello ed altri scopi.
Se hai del codice da sharare avrei idee interessanti per un oggetto del 
genere (sebbene sia allergico al simbolo + dopo il C).
 
 
 
 

 non completa) se si comporta da DNS ricorsivo.
 
 
Altro esempio.
 
- 
ns1.dominio1.it
 è autoritativo sia per 
dominio1.it
 che per 
dominio2.it
.
- 
www.domino1.it
 è CNAME di 
www.dominio2.it
 
 
Se tu fai un
 
# dig 
www.dominio1.it
 @
ns1.dominio1.it
 
 
allora la risposta conterrà nella answer section sia un record riferito a 
domino1 che a dominio2 (che è il caso che tu hai proposto).
 
Ciò che è successo e' lecitissimo e tu non sai ancora se quel DNS che ti 
ha fornito una risposta contenente dominio2 è autoritativo o meno.
 
Che fai ? 
1) trust: tieni la risposta e vai avanti
2) no trust: butti la risposta e fai un altro giro.
 
Quindi il comportamento è tecnicamente corretto. 
Anche la tua implementazione, se ti fidi delle risposte.
 
 

 della zona di cui è autoritativo.
 
Il problema è: tu lo sai se è autoritativo? E lui, lo sa?
 
skull@sauron:~$ dig a 
www.spin.it
 @
up.spin.it
 +noall +answ
 
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> a 
www.spin.it
 @
up.spin.it
 +noall
+answ
;; global options: +cmd
www.spin.it
.		300	IN	CNAME	
www.spin.it.safecdn.it
.
www.spin.it.safecdn.it
.	300	IN	CNAME	
anycast02.safecdn.it
.
anycast02.safecdn.it
.	300	IN	A	147.123.1.187
 
 
Qui sta, come vedi, tutto in answer section, poichè 
up.spin.it
 è
autoritativo anche per 
safecdn.it
.
 
Ma posso fidarmi che lo sia (autoritativo) per davvero?
 
Perchè tutto quel che "lui" sa, qui, è che ha in configurazione una zona
per 
safecdn.it
; che poi le deleghe per quella zona mantenute .it puntino
davvero a 
up.spin.it
 non lo sa lui e (fino a qui) nemmeno io...
 
Sicchè il fatto che lui si consideri autoritativo mi dovrebbe rimbalzare
assai...
 
 
/me e adesso la zuppa di miso
 

 assai...
 
Si si, infatti.
Avevo già postato un altro esempio proprio relativo a questa problematica.
 
 


Eh, visto, ma l'hai scritto mentre ero già in fase berserk-writer... :-P
 

 DNSSEC).
 
Ad implementare DNSSEC (ma anche EDNS) per ora non ci penso proprio  :)
 

 2) no trust: butti la risposta e fai un altro giro.
 
io scelgo la busta numero 3, mi fido e prendo per buona la risposta ai 
fini della specifica query perché so che sei autoritativo per dominio1 
e quindo so che se volevi rifilarmi un indirizzo IP sbagliato lo 
potevi fare comunque, ma non mi fido fino al punto di riutilizzare il 
record relativo a dominio2 per query diverse. Quindi va sì in cache, 
ma con questa limitazione.
 
Se poi, in un secondo momento, arriva al server una richiesta per 
dominio2, questa viene risolta senza tener conto del record precedente.
 
 

 Una query per 
www.google.com
 IN A non la prenderebbe in considerazione.
 
Dici?
E se la query al tuo resolver non veniva da uno stub ma da un altro
resolver? Come la spieghi, a lui, la differenza tra le due risposte che
gli fornisci, per evitare che metta in cache l'informazione errata?
 
 
Nota che io non sono particolarmente esperto in questi dettagli
implamentativi in un resolver, però se fai un po' di ricerca troverai
che questo specifico tipo di attacco era molto in voga fino a circa metà
degli anni 90, che si corse ai ripari in diversi modi, e che fu
argomento di una delle epiche sbroccate di DJB vs BIND+Vixie...  ^_^
 
 
Senza pretendere di dire come le cose dovrebbero o non dovrebbero essere
secondo me, ti rimanderei felicemente a tutta la letteratura dell'epoca,
perchè implementazioni diverse hanno adottato approcci diversi...
 
 

 perchè implementazioni diverse hanno adottato approcci diversi...
 
Hai qualche link da suggerire?
 
Grazie mille :)
 

 Hai qualche link da suggerire?
 
Ohibò, son passati 10 anni e non sono un implementatore di nameserver,
solo un utente (cui però capita di vedere sovente i trucchetti più
assurdi usati con il DNS); quindi chiedi tanto, a domandarmi i dettagli.
 
Però il punto qui discusso è trattato a partire da qui:
 
http://cr.yp.to/djbdns/notes.html
 
 
 
Poi nota: non sono un grande estimatore di DJB; tuttavia, sul topic in
questione e in generale sul fatto che i DNS dovrebbero andare con i
piedi di plutonio nel trustare informazioni che non abbiano richiesto,
anche a costo di fare un paio di ricorsioni in più c'aveva ragionissima,
e oggi è anche più attuale di quella volta lì...
 


 
Sì sì, mi hai convinto, agisco di conseguenza :)
 

Il 25/11/2013 14:46, lorenzodes ha scritto:
 
[...]
 
Scusate il necroposting. Potrebbe interessare a qualcuno se pubblicassi 
il codice del serverino in questione? Ovviamente senza impegni.
 


wrote:

Dopo un solo mese il cadavere respira ancora :-D
 
Mettilo magari su github, e' la volta che imparo a usarlo :-D
 
Leonardo
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 Leonardo
 
Poich� avevo gi� un account su bazaar ho optato per quello, spero non 
sia un problema.
 
Link: 
https://code.launchpad.net/~lorenzodes/+junk/ldesdns
 
 
Siate buoni (siamo in periodo Natalizio), abbiate piet� di me :)
 
 


 
Qualcuno l'ha provato? :)