Brand new to PIX. Here's the story... pix 515e running 6.3(5) Box will freeze from time to time and won't pass/handle new dns requests. IP traffic is still ok if you use ip# only. Host names will not resolve. Clear local will fix the problem. I don't have any rules or statics for dns. Inside clients point to an internal solaris named box for resolution who will pass request to isp if he doesn't have answer. Another fix to the problem is if I change my pc's resolver from the solaris box to the isp's dns. I've been running a solaris based firewall for years in the same environment and never had such a problem.(if I put the solaris firewall back in place the problem goes away) One minute I think there is something wrong with the pix because a reboot or clear local will fix the problem and the next minute I wonder if there could be something wrong with my named server because, as I said, if I point to the isp's dns servers the problem goes away. No changes have been made to the internal named server. I can see from syslog that the dns udp teardowns that normally take 1 second all of a sudden take 2 minutes when the problem happens. I've looked throught the log around the time that happens and see nothing suspicious. Any ideas - I'm going insane thanks...jim
I thought of that but dismissed it thinking how could a simple dns request be more than 512 bytes - plus all dns stops - not just large requests. But it's worth a shot - I'll try messing with it and see what happens - i"m desperate. Thanks for the input....
CSCsc61300 CPU increases with high volume of DNS requests using same four-tuple.Here is list of all bugs recognised since the release of 6.3(5) and there associated 'patch' versions:Note there is no 102 220.127.116.11/
30-Aug-2005 05:59 - CSCsb53549 VAC+ may cause interface to stop passing all trafficCSCsb53760 Port redirection for DNS traffic does not work correctly. 18.104.22.168/ 07-Sep-2005 02:23 - CSCsb71315 URL Filtering with long URLs could cause memory corruptionCSCsb75773 Malformed HTTP GET request causes URL filtering module to cause a crash. 22.214.171.124/
11-Oct-2005 22:59 - CSCei63244 Traceback with lu_rx thread name in failover mode.CSCsb48916 Manual ipsec fail when esp-aes-256 specified with authCSCsb68431 names can turn off on startup, possible configuration lossCSCsb79761 Backspace sent in cut-through proxy authenticationCSCsb91253 SIP: PIX does not parse the expire value in Register 126.96.36.199/
09-Nov-2005 03:19 - CSCef19560 PIX - show uauth doesnt display users with space in usernameCSCsb79609 SIP: PIX does not update BYE embryonic's timestamp.CSCsb87382 SIP: Stanby PIX show the wrong value of xlate timeout for sip media.CSCsb91279 SIP: Standby PIX set unusual value of conn idle time.CSCsc23638 duplicate xlates on stateful standby due to static misconfigurationCSCsc25386 Higher metric OSPF external route is selectedCSCsc39368 PDM with Command Authorization requires the write command for Read-Only 188.8.131.52/ 01-Dec-2005 00:08 - CSCsc36311 OpenSSL lib can be forced to negotiate the SSL 2.0 protocolCSCsc44193 ftp fixup drops ftp server response packetsCSCsc49665 SIP : Large number of static PAT cause delaying of RTP packetsCSCsc53472 PIX not following SNMP packet size standard in RFC3417CSCsc53491 Pix does not support SNMP variable ipForwardingCSCsc60930 PIX 6.3 Hitless Upgrade supportCSCsc61300 CPU increases with high volume of DNS requests using same four-tuple. 184.108.40.206/
14-Jan-2006 00:09 - ? CSCdv54885 downloadable ACLs not deleted after cl uauth when telnet to PIXCSCsc14915 PIX 6.3 Spoofed TCP SYN packets can block legitimate TCP connectionsCSCsc66215 PIX reload with Thread Name: https_proxyCSCsc68744 PIX - Syslog PIX-6-110001: No route to IP generated incorrectlyCSCsc91098 SIP: PIX does not create media conns if first m= has port 0 in sdp. 220.127.116.11/ 23-Jan-2006 20:28 - CSCsc82346 tftp fixup does not allow error message from clientCSCsc92911 PIX 6.3 crashing at mgcp_show_sessionsCSCsc95334 PIX does not recognize RADIUS access-accept and access-reject packets.CSCsd08448 downloaded acl is not removed after a virtual telnet login 18.104.22.168/ 07-Feb-2006