Dropped UDP DNS reply from 192.58.128.30 j.root-servers.net

[rinux]

Salve a tutti,
riscontro sui firewall con ispezione sul protocollo DNS problemi di funzionamento se un server interno linux interroga alcuni server esterni... per esempio se chiedo la risoluzione inversa di alcuni IP ottengo un bel timeout e sulla console dell'ASA passa il seguente messaggio:

Codice: Seleziona tutto

Dropped UDP DNS reply from outside:192.58.128.30/53 to inside:inside-host-linux/40783; label length 87 bytes exceeds protocol limit of 63 bytes

...mi tocca escludere dall'ispezione il protocollo DNS oppure esiste una soluzione al problema?

NB: per caso è un problema legato alla versione del fw ...dico questo perchè se lascio passare il traffico, tutto funziona correttamente! Immagino che un root server conosca bene lo standard e rispondi correttamente o no

73
Arturo

[zot]

Uh,uh...certo che sei stimolante (in senso trecnico ovviamente ).
Comunque l'inspect su asa e' una roba altamente configurabile,il piu' delle volte si lascia di default(che il piu' delle volte basta ed avanza)ma entrarci nei meandri e' un bel trip.
Domani recupero un libro che ho in macchina dove c'e' una parte su l'inspect abbastanza dettagliata e vedo se c'e' qualcosa che puo' essere utile.

[rinux]

Ciao...

certo che sei stimolante

Mmmmm... Io direi più che sono sfigato... Ho sempre qualche strana anomalia che viene fuori al momento della consegna...

Arrivo a prendere lo stesso pezzo di ferro, a buttarci la stessa configurazione per ritrovarmi con problemi nuovi...


73
Arturo

[zot]

Come detto la questione è interessante:
Di default l'inspect sul DNS non lascia passare pacchetti DNS superiori a 512 byte quindi dovrebbe far passare un pacchettto DNS da 87 bytes......
Metti sotto la class che t'interessa

Codice: Seleziona tutto

inspect dns maximum-lenghth 1024

che è anche la best practice consigliata da Cisco....il perchè poi quel pacchetto venga droppato nun so......se hai trovato un altro BUG c'hai una fortuna........

P.S. mi suona molto strano che il tuo ASA segnali un pacchetto DNS UDP da oltre 63 bytes come da droppare.....63 bytes sono troppo pochi per un pacchetto DNS ....mahh
a tal proposito ul log preso in giro...

Codice: Seleziona tutto

sample firewall log:
Oct  9 09:46:33 192.168.1.2 %PIX-4-410001: Dropped UDP DNS reply from  
outside:209.1.1.2/53 to inside:209.96.10.100/53661; packet length 523  
bytes exceeds configured limit of 512 bytes

due sono le cose,o hai inpostato un limite sull'inspect DNS troppo basso o.....segnalaci la versione FW che hai su va....

Per la cronaca,sembra che BIND sia solito inviare opacchetti DNS reply superiori ai 512 bytes

[rinux]

Metti sotto la class che t'interessa

Codice: Seleziona tutto

inspect dns maximum-lenghth 1024

che è anche la best practice consigliata da Cisco....

Già fatto, lo faccio normalmente altrimenti taglia troppi pacchetti

NB: e comunque anche a 1024 ogni tanto taglia qualche risposta

il perchè poi quel pacchetto venga droppato nun so......se hai trovato un altro BUG c'hai una fortuna....

Non mi credi Sono inseguito dalla....

due sono le cose,o hai inpostato un limite sull'inspect DNS troppo basso o.....segnalaci la versione FW che hai su va....

Per la cronaca,sembra che BIND sia solito inviare opacchetti DNS reply superiori ai 512 bytes

Yes, di mezzo c'è proprio BIND; comunque la risposta tagliata è quella di un server esterno... la versione dell'ASA è 8.0(4)

...credo che il pacchetto viene tagliato perchè l'ASA è convinto che un campo della risposta e troppo grande... catturerò una reply e la controllo con wireshark per vedere com'è fatta!!!


73
Arturo

[zot]

Mi sa che hai ragione

Codice: Seleziona tutto

label length...

e non

Codice: Seleziona tutto

packet length....

fammi sapere che son curioso....

[rinux]

fammi sapere che son curioso....

mmm... il problema è limitato... non posso garantire che sia cosí, ma con test a campione pare che il problema si presenti in un solo caso: eseguendo la reverse query dell'ip pubblico della linea a cui è connesso l'asa

Perchè e come si verifica il problema non è facile da stabilire; i dati catturati tramite la funzione di packet capture dell'asa potrebbero essere alterati... in pratica:

- parte la query con all'interno x.x.x.x.in-addr.arpa: type PTR, class IN
- arriva la reply con all'interno y.y.168.192.in-addr.arpa: type PTR, class IN

Tre cose:
- Wireshark segnala la reply come Malformed Packet: DNS
- l'asa è quello che stà dietro un nat di fastweb
- non sono riuscito a trovare un'altra query che faccia partire una richiesta verso quel root server


... comunque non capisco chi cambia il contenuto della reply; se l'asa prima di catturare il pacchetto o altri apparati del carrier e comunque il problema si presenta anche togliendo l'opzione enable NAT re-write function... ...DNS inspect riattivato, aspetto per vedere se passa qualche messaggio su altri IP!

NB: ho notato che comunque le reply sono particolarmente corpose anche a causa dell'IPv6... ed il malformed packet è associato al numero di Addittional RRs presenti nella reply... con 13 campi wireshark lo prende per buono, mentre con 19 campi segnala il pacchetto come malformed...

73
Arturo

[zot]

[
- non sono riuscito a trovare un'altra query che faccia partire una richiesta verso quel root server .....

forse non ho capito ma con nslookup ?

Codice: Seleziona tutto

zot@zotway:~$ nslookup 
> server j.root-servers.net
Default server: j.root-servers.net
Address: 192.58.128.30#53
Default server: j.root-servers.net
Address: 2001:503:c27::2:30#53
> a.root-servers.net
Server:		j.root-servers.net
Address:	192.58.128.30#53

Name:	a.root-servers.net
Address: 198.41.0.4
> 

[rinux]

forse non ho capito ma con nslookup ?

No , utilizzando server esterni è tutto ok,
il problema si presenta quando la query parte da BIND!
Ed ho fatto diversi tentativi a campione ma la cabala ha voluto che tutte le query fatte non portavano ad inoltrare richieste verso j.root-servers.net.

NB: ora sto aspettando di raccogliere qualche kilo di log per vedere se il problema è circoscritto alla risoluzione inversa del solo ip della hdsl o anche ad altri nomi/ip...

73
Arturo