Netscreen: Lots of extraneous "denied" packets in log

Feb 25, 2006 7 Replies
J

I'm seeing a considerable number of Denied packets in my log, all coming from outside my network with source port 53. They're all coming from root and top-level name servers (such as g.gtld-servers.net).



I've seen this on other firewalls I've used in the past and it's almost always been caused by my local name server sending a UDP packet out to a remote name server to resolve an address and not getting a response before the NAT translation timeout expires, or getting multiple replies.



Is there a way to set the NAT translation timeout for UDP on a 5GT? I'm running firmware 5.3. I've already tried "set flow allow-dns-reply", but this didn't help.



Thanks.


Vote
Twitter Facebook LinkedIn
S

A well-known problem with the same effect is that people and some implementations don't assume the answer to be sent with TCP instead of UDP (if the answer doesn#t fit into a single UDP packet).

Don't know, but a usual workaround it simply forward all DNS answers from an authorized set of DNS servers and deny any others.

Maybe you can add a rule to ignore / not log such particular events?

Vote
Twitter Facebook LinkedIn
V

Better use a forwarding DNS outside. You could work on the timeouts.

Yours, VB.

Vote
Twitter Facebook LinkedIn
S

set service dns timeout

Does it really take more than 1 minute to get answer back from DNS? (that's the default)

-Russ.

Vote
Twitter Facebook LinkedIn
M

Can you show a packet dump of such behaviour? Maybe you want to re-read RFC1035 and 1035 again.

1034 Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. (Format: TXT=129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035) (Also STD0013) (Status: STANDARD) 1035 Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035) (Also STD0013) (Status: STANDARD)

DNS servers do not spontaneously reply using TCP to a UDP request. If the UDP request results in a reply to large, the TC flag is set in the reply, and the querying station may elect to repeat the request using TCP. ONLY THEN will there be a TCP packet exchange. See section 4.2 of RFC1035.

Old guy

Vote
Twitter Facebook LinkedIn
S

Procedure to dump port 53 traffic for old guy et al to look at:

undebug all clear db unset ffilter

set ffilter dst-port 53 debug flow basic

get db st

-Russ.

Vote
Twitter Facebook LinkedIn
M

[compton ~]$ whatis undebug undebug: nothing appropriate [compton ~]$ help undebug No help topics match `undebug'. Try `help help'. [compton ~]$ which undebug [compton ~]$ locate undebug [compton ~]$
[compton ~]$ whatis clear clear (1) - clear the terminal screen clear [curs_clear] (3x) - clear all or part of a curses window [compton ~]$ which clear /usr/bin/clear [compton ~]$

Sorry Russ - your instructions don't work on a *nix box. All I need do is run a sniffer like tcpdump or ethereal

Old guy

Vote
Twitter Facebook LinkedIn
J

Not likely. I believe the 5GT, by default, only lets one reply back in. I suspect that the logged entries are due to multiple reply packets.

Time to fire up Ethereal and start looking at the name server traffic.

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required