Networks

This maybe a long shot, but have you done any updates to the server? The reason why I bring this up, I have experience several machines over the past two weeks either with slow performance or blue-screen-o-death. I traced several failures to system updates. Also, if your server has auto-update enabled, I would go into the services option under Administrator tools and disable the autoupdate feature or just turn off the feature. The SVChost service can cause a lot of issues similar to what you are experiencing (with the slow performance and the inability to connect online. Even though the problems I?m mentioning in this reply now I experienced with workstations (it could happen on a server), the solution was to roll back the drivers and or disable the auto-update for window, these solutions worked 99% of the time either alone or together. Since you said it happened within the past week or so, that about the same time I experienced problems with some systems.

When it comes to the DOS Attack. Since when you switch it to the backup T1, everything works, that leaves me to believe that the problem maybe related to a DOS Attack.

Also, in your latest reply, it states that the PDC is configured 127.0.0.1, does that mean you have a static IP address for the PDC as 127.0.0.1? If so, this is a major issue because 127.0.0.1 is reserved for loopback and that can cause major issues. I would go through all Static IP assigned to your servers. I would make sure that all servers have static IP addresses. If the server in question has a dynamic setting that will also keep it from accessing outside the gateway if the gateway is not configured to allow that IP address to pass-through. If the server had dynamic settings for the IP, then it would work for a short while, then after a few days, it would fail, I would review the event log under DNS and System to see what errors are popping up. Please keep me informed of your progress. Also, for the server in question, check the DNS settings 1 and DNS settings 2.

Hello All,

I would try the following commands to determine if the problem is with internal dns name resolution or external dns resolution. Depending on the firewall used and the OS of the DNS server, there may be issues resolving domain names of certain sites.

nslookup www.gmail.com [ISP DNS server]
nslookup 66.249.83.19 [ISP DNS server]
nslookup 66.249.83.19 [internal DNS server]
nslookup www.gmail.com [internal DNS server]
nslookup -q=mx [your domain name]
nslookup host.yourdomainname.com
tracert www.gmail.com
tracert 66.249.83.19

If these domain name queries fail, then you might want to restart the DNS service on the domain controller and repeat test.

Please check out the article below for the specific fix.

good luck


DNS query responses do not travel through a firewall in Windows Server 2003

http://support.microsoft.com/kb/828263

SYMPTOMS
A Microsoft Windows Server 2003-based computer may not receive DNS query responses through a firewall.

Some queries, such as queries for A records, work as expected. Queries for MX records may fail. Domains with this issue include AOL.com, Qwest.net, and EarthLink.net.

The sender of an e-mail may receive a Non Delivery Reciept (NDR) with the error message that is similar to the following:
The following recipient(s) could not be reached: user@earthlink.net on (Date Time) There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. <(Domain.com) #5.5.0 smtp;550-EarthLink does not recognize your computer (xx.xx.xxx.xxx) as connecting from an EarthLink connection. If this is in error, please contact technical support.>
Back to the top

CAUSE
This issue may occur if a firewall blocks the transfer of UDP packets that are larger than 512 bytes.

With Extension Mechanisms for DNS (EDNS0) as defined in RFC 2671, "Extension Mechanisms for DNS (EDNS0)," DNS requestors can advertise UDP packet size and transfer packets larger than 512 bytes. By default, some firewalls have security features turned on that block UDP packets that are larger than 512 bytes. As a result, DNS queries may fail.

This problem also may occur on some Cisco PIX Firewall models with software that is earlier than PIX Firewall version 6.3(2). The Cisco PIX Firewall drops DNS packets that are sent to User Datagram Protocol (UDP) port 53 that are larger than the configured maximum length. By default, the maximum length for UDP packets is 512 bytes.
Back to the top

RESOLUTION
To resolve this issue, use any one of the following methods.
Back to the top

Method 1
Contact the firewall vendor to determine how to permit UDP packets that are larger than 512 bytes through the firewall.

For update instruction and for information about how to resolve this problem, visit the following Cisco Systems Web site:
http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list.html (http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_notes_list.html)


For information about how to contact a specific firewall vendor, click the appropriate article number in the following list to view the article in the Microsoft Knowledge Base:
65416 (http://support.microsoft.com/kb/65416/) Hardware and software vendor contact information, A-K

60781 (http://support.microsoft.com/kb/60781/) Hardware and software vendor contact information, L-P

60782 (http://support.microsoft.com/kb/60782/) Hardware and software vendor contact information, Q-Z


Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
Back to the top

Method 2
Turn off EDNS0 functionality on the Windows Server 2003 server. To do so, at the command prompt, type:
dnscmd Server Name/Config /EnableEDnsProbes 0
Back to the top

WORKAROUND
To work around this issue, turn off the EDNS0 feature in Windows Server 2003. To do this, follow these steps: 1. Install the Dnscmd.exe program from the Windows Server 2003 Support Tools. To install the Windows Support Tools, right-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD-ROM, and then click Install. Follow the steps in the Windows Support Tools Setup Wizard to complete the installation of the Windows Support Tools.
2. At a command prompt, type dnscmd /config /enableednsprobes 0 , and then press ENTER.
Note Type a 0 (zero) and not the letter "O" after "enableednsprobes" in this command.
Back to the top

MORE INFORMATION
The original DNS restriction for UDP packet size is defined in RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION." For more information about RFC 1035, visit the following Internet Engineering Task Force (IETF) Web site:
http://www.ietf.org/rfc/rfc1035.txt (http://www.ietf.org/rfc/rfc1035.txt)
For more information about RFC 2671 and EDNS0, visit the following Internet Engineering Task Force (IETF) Web site:
http://www.ietf.org/rfc/rfc2671.txt (http://www.ietf.org/rfc/rfc2671.txt)
For more information about EDNS0 support in Windows Server 2003, visit the following Microsoft Web site:
http://technet2.microsoft.com/windowsserver/en/library/d86401b2-8bc8-4364-83b4-edb71a7107041033.mspx (http://technet2.microsoft.com/windowsserver/en/library/d86401b2-8bc8-4364-83b4-edb71a7107041033.mspx)
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.
Back to the top


--------------------------------------------------------------------------------

APPLIES TO
? Microsoft Windows Server 2003, Standard Edition (32-bit x86)
? Microsoft Windows Server 2003, Web Edition
? Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
? Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
? Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
? Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems

Back to the top

Thanks for all the detailed help!

Unfortunately, I'm still encountering the same issues. I'm beginning to believe it may be an issue with the PIX (which is controlled by our parent company).

I've checked the routing tables, restarted the DNS server, and much more. I enabled the second network card and configured it on an additional IP address on the same gateway and no luck.

We have two separate gateways - our PIX is on our primary fiber network connection. We also have an active T1.

Whenever I use the T1 - Everything works fine (on both network cards). Whenever I switch to the PIX Gateway, I can ping the gateway and any internal sites, but no access to the outside.

The thing that bothers me about this is the running configuration looks fine on the PIX - no issues. Nothing has changed over the past few weeks.

Anyone had an instance of this happening even though PIX shows no logs or problems? Or could it be some strange MS configuration problem or attack?

Thanks again! It's just been frustrating.

Hey Buddy, sorry this has not worked out so well. If it's an DOS attack, check the incomming port. If you are recieveing a flood of data packets from outside your office, then it's quite possible a DOS attack. I experience that about 3 months ago. I changed the Static IP address and it worked great. Also before that, i reset the Firewall/router then that solved it on another account. But in your case, I would narrow it down to a problem with that Static Ip on the PIX or a firewall change/malfunction. If your parent company controls that channel, i would ask them to reset the system that routes data packets to and from your office. At this point you may be right. I do not think it's a MS configuration if it works on the backup T-1, unless it's been config to the DNS or gateways of that T-1 channel. Please let me know what happens. Thanks,

Method 2

Turn off EDNS0 functionality on the Windows Server 2003 server.

To do so, at the command prompt, type:

dnscmd Server Name /Config /EnableEDnsProbes 0
Back to the top