Problemi con NAT di DNS

[giox069]

Salve a tutti.
Da qualche giorno i miei server DNS microsoft (windows 2003 o windows 2008 con Active Directory) hanno problemi a risolvere proprio l'indirizzo "www.cisco.com". Questo problema succede solo presso i clienti dove ho installato cisco IOS come router/gateway/firewall (versioni fino all'anno 2008 circa, 871, 877, 1812).
Succede che al primo "ping www.cisco.com", l'hostname viene risolto correttamente e pingo l'host che viene proposto. Il secondo "ping www.cisco.com" invece non è in grado di risolvere l'hostname. Questo implica che comunque nella prima risoluzione c'era un RR di risposta con TTL zero e quindi non è stato inserito nella cache del DNS, bruttissimo comportamento di IOS.
Sono andato a fondo sniffando con wireshark e debuggando da cisco. Probabilmente succede questo:
- Alla prima richiesta di risoluzione, i DNS di M$ risolvono correttamente l'hostname, ma IOS si arrabbia e mi imposta il TTL a zero
- Alla seconda richiesta di risoluzione, i DNS di M$ non vogliono più saperne del TTL 0 (per motivi di security ??) fino a quando non trascorre un certo tempo.
Questo comportamento lo ho su almeno 5 reti diverse e non collegate tra di loro.

Ecco il "debug ip nat detail" del misfatto, del pacchetto di risposta che IOS non riuscendo a interpretare mi modifica azzerandone il TTL.

Codice: Seleziona tutto

002668: Jul  9 17:02:35.285 CEST: NAT: s=192.168.98.1->82.106.176.211, d=217.212.245.68 [30725]
002669: Jul  9 17:02:35.353 CEST: NAT: o: udp (217.212.245.68, 53) -> (82.106.176.211, 54431) [43804]
002670: Jul  9 17:02:35.353 CEST: NAT (UDP-DNS): Before Translation
002671: Jul  9 17:02:35.353 CEST: NAT: Translation of UDP DNS src 217.212.245.68, dst 82.106.176.211
002672: Jul  9 17:02:35.353 CEST: NAT: Dns type of Response
002673: Jul  9 17:02:35.353 CEST:    : dns len=90, id=48916, aa=1, tc=0, rd=0, ra=0
002674: Jul  9 17:02:35.353 CEST:    : opcode=0, rcode=0, qdcount=1
002675: Jul  9 17:02:35.353 CEST:    : ancount=1, nscount=0, arcount=0
002676: Jul  9 17:02:35.353 CEST:      query name is www.cisco.com.edgekey.net, qtype=1, class=1
002677: Jul  9 17:02:35.353 CEST: Answer section:
002678: Jul  9 17:02:35.353 CEST:    Name='www.cisco.com.edgekey.net'
002679: Jul  9 17:02:35.353 CEST:    RR type=5, class=1, ttl=21600, data length=47
002680: Jul  9 17:02:35.353 CEST: (Error in parsing cname data)
002681: Jul  9 17:02:35.353 CEST: NAT (UDP-DNS): After Translation
002682: Jul  9 17:02:35.357 CEST: NAT: Translation of UDP DNS src 217.212.245.68, dst 82.106.176.211
002683: Jul  9 17:02:35.357 CEST: NAT: Dns type of Response
002684: Jul  9 17:02:35.357 CEST:    : dns len=90, id=48916, aa=1, tc=0, rd=0, ra=0
002685: Jul  9 17:02:35.357 CEST:    : opcode=0, rcode=0, qdcount=1
002686: Jul  9 17:02:35.357 CEST:    : ancount=1, nscount=0, arcount=0
002687: Jul  9 17:02:35.357 CEST:      query name is www.cisco.com.edgekey.net, qtype=1, class=1
002688: Jul  9 17:02:35.357 CEST: Answer section:
002689: Jul  9 17:02:35.357 CEST:    Name='www.cisco.com.edgekey.net'
002690: Jul  9 17:02:35.357 CEST:    RR type=5, class=1, ttl=0, data length=47
002691: Jul  9 17:02:35.357 CEST: (Error in parsing cname data)

Questo log arriva da un 1812 con IOS 12.4(15)T9

Come vedete, IOS oltre a non capirci niente del pacchetto risolto (Error in parsing cname data), ha pure l'accortezza di impostarmi il TTL a zero.
Il TTL a zero fa in qualche modo arrabbiare il DNS Microsoft... e nessuno risolve più www.cisco.com.

Che posso fare ?

Grazie
Giovanni

[danny webber]

potresti spiegare meglio la topologia della rete?
Dove stanno i server dns ms?
Se questi sono interni alla rete perchè anche il router fa la risoluzione?
Giusto per capire meglio.

[giox069]

Ho una subnet privata, classe 192.168.X.Y/24 dove ci sono tutti i PC e i server DNS di Microsoft Active directory nella configurazione più standard che esiste: sono autoritativi solo per la mia zona DNS interna e per il resto usano le normali risoluzioni ricorsive e fanno caching delle risposte. I server DNS miei sono quindi dentro la mia subnet. I server DNS degli altri domini sono invece sparsi per il mondo. Non uso quelli del provider, ma faccio fare la risoluzione ricorsiva a quelli interni di microsoft installati sui miei server.

A questa subnet è collegato un CISCO1812 che fa da firewall (nat + ip inspect) verso Internet. Non fa da server DNS.

E' normale per IOS intercettare i pacchetti DNS e analizzarne il payload, sia nella fase di NAT, sia nella fase di inspect. Nella fase di NAT è tipico che IOS modifichi il contenuto di alcuni pacchetti di risposta che contengono record di tipo A (e qui non mi dilungo a spiegare quando lo fa), impostandone anche il TTL a zero.
Quello che mi sorprende è che imposti il TTL a zero anche quando non riesce a capirci niete (quando va in errore).
Quello che mi sorprende di più è... che lo fa proprio con www.cisco.com !!!

[danny webber]

wow... non semplicissimo come problema.
Ora la mia domanda, come fai ad essere sicuro che sia il cisco che ti metta il ttl a 0?

puoi mandare un debug di un altro sito che invece funziona?

quante possibilità hai di abbassare l'ip inspect e fare dei test con quello abbassato?

Ti chiedo questo, perchè la natura non si capisce benissimo.
Nel senso, se il problema è il ttl a 0... ed è il router che lo mette ci deve essere un motivo. E soprattutto ci deve essere un motivo sul perchè lo faccia solo al sito di cisco.

[giox069]

La certezza al 100% non ce l'ho, ma gestendo più reti simili (almeno 10) ti posso confermare che mi accade solo dove il firewall è cisco (1812 o 871 o 877). Inoltre se guardi bene il log presente nel mio primo post, vedi che è diviso in due parti: la prima "Before translation" (3a riga) ttl=21600 e la seconda "After translation" (14a riga) ttl=0.

Comunque penso di avere risolto: con

Codice: Seleziona tutto

no ip nat service dns-reset-ttl

si evita di azzerare il TTL, e la soluzione mi sembra abbastanza elegante. Provato velocemente sia in un 1812 che in un 871 e per ora sembra funzionare. Vedremo nei prossimi giorni cosa succederà.

Sembra che cisco sappia del problema, ma lascia di default l'azzeramento del TTL per compatibilità all'indietro (lo scrivono in un forum di ietf). Inoltre "ip nat service dns-reset-ttl"... non mi sembra sia documentata nel sito cisco

Grazie lo stesso
Giovanni