I have a single Windows 2008 domain server running DNS. On boot up DNS works fine, but over time it stops resolving names. Stopping and starting DNS resolves the issue, but it comes back within a few days. Any ideas?

any error/warning/information that can be helpful for your issue from event viewer ?Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Check Event's logs and please post the error

I have a single Windows 2008 domain server running DNS. On boot up DNS works fine, but over time it stops resolving names. Stopping and starting DNS resolves the issue, but it comes back within a few days. Any ideas? Yes, first of all, does that 2008 use forwarders ? See, in such a case, the issue may be related to forwarders not answering (for some reason... e.g. too many queries from your IP) Also, did you check your firewall configuration is correct ? If so, your DNS should be able to carry out DNS queries using both UDP (the default) and TCP (used sometimes); to check if the firewall is ok, you may try running the following (from a "cmd" prompt opened on your 2008 DNS server) nslookup > server 4.2.2.3 > set type=MX > live.com. > set vc > yahoo.com. > exit notice that the ">" char is the "nslookup prompt"; the first command (after starting nslookup) will set the resolver address to 4.2.2.3, the second one tells nslookup to retrieve MX records, the 3rd runs a query to retrieve the MX records for "live.com", the fourth (set vc) tells nslookup to use TCP instead of UDP to carry out queries, next we try retrieving the MX records for "yahoo.com" and then, we exit from the "nslookup" interactive mode If everything is working as expected, both queries (live.com and yahoo.com) should get back an answer; if that isn't the case, then you'll need to revise your firewall configuration ensuring that the firewall is allowing outbound traffic from your 2008 DNS server IP to external hosts on ports 53/UDP and 53/TCP; done that and after repeating the check to ensure things are working, you may check if your setup allows the use of EDNS0; to do so, please, follow the instructions you'll find here which will allow you to perform such a check and to fix whatever is needed to ensure your DNS will also be able to work with EDNS0 Once all the above will be ok and if your server will still have issue, try reading this and ensuring the server is properly configured for internet names resolution (skip the forwarders step and leave those empty)... then, please, report here about your progress thanks

Post the error logs and see the below link, it may help you. http://msmvps.com/blogs/acefekay/archive/2010/10/11/edns0-extension-mechanisms-for-dns.aspxBest regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin

Hello, if the already mentioned steps doesn't help please post an unedited ipconfig /all from the problem machine.Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

Hi Bob, Thanks for posting here. Your question is not clear so far, when you say “ but over time it stops resolving names “ did you mean server cannot resolve any DNS record whatever locally hosted or other external records form itself or other computers that point to use this server for name resolution? And which DNS service you restated ? “DNS server” service or “DNS client” service ? Please check the version of DNS.exe file and also verify the log and post back like other users suggested. Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

You may go to the server. go to the roles and select DNS. check the event logs on the DNS server. With out having a proper logs cannot assume what would be the issue. As posted before DNS stop resolving external names or internal server names. If it is external could be a issue with forwards you configured on the DNS server.Make sure you configure your ISP public IP address as the forwaded DNS server IP address.If you found this post helpful, please "Vote as Helpful". If it answered your question, remember to "Mark as Answer". MCSE,MSCITP-EA

The nslookup test worked fine, so my firewall does not seem to be a problem. However it seems that my setup is not using EDNS0 which I will now look at. For those who have asked, I have not configured forwarders and the Event Logs show a number of 5501 errors (64 in the past 24 hours) Thanks for your help.

For those who have asked, I have not configured forwarders and the Event Logs show a number of 5501 errors (64 in the past 24 hours) Reading this KB article you'll find that the event ID 5501 is caused by the following (quoting the KB article text) Event 5501 indicates that after sending a recursive query on behalf of a client, DNS received a response with a fragmented flag set indicating that the answer did not fit in one packet and that there is more data to follow. In versions of Windows NT 4.0 earlier than Service Pack 4 (SP4), DNS incorrectly discards the packet. Windows 2000 behaves correctly in this case. now, the above means that to correctly retrieve all the data the DNS should either retry the query using TCP or use EDNS0 which allows UDP "oversided" packets; since you wrote that your setup doesn't seem to allow you to use EDNS0, I'd suggest you to check your DNS (and firewall/router) settings to allow EDNS0 to correctly work; as for my previous message, use this method to check your EDNS0 support and ensure it's working HTH

From what I have read it seems that Windows Server 2008 R2 should have enabled EDNS0 working by default; if not how do I enable it? I have seen posts that sugest I turn off EDNSProbes but setting them on or off makes no difference to the test you suggested.

From what I have read it seems that Windows Server 2008 R2 should have enabled EDNS0 working by default; if not how do I enable it? I have seen posts that sugest I turn off EDNSProbes but setting them on or off makes no difference to the test you suggested. Yes, the Windows 2008 DNS server has the EDNS0 enabled by default (same goes for windows 2003); the problem lies in the fact that some firewalls/routers or "security devices" don't allow using the oversided UDP packets which are needed for EDNS0 to work, so, while the DNS may support such a mechanims, those devices sitting on its path "to the internet" may be truncating or dropping such packets so causing issues In a past, the usual suggestion was to use "forwarders" or to disable EDNS0 (EDNSProbes as you wrote) but, as of today, that isn't a solution; first of all, using forwarders may (and does) cause security/functionality/availability issues, second, it's not a solution since you'll just be moving your issue "somewhere else" and NOT solving it, third, if someone along your traffic path is dropping oversized UDP traffic, it will still do so, so you won't solve your problems [edit] Not just that; to correctly use DNS zone signing (DNSSEC) you will need to have an EDNS0 enabled resolver, and, using forwarders or other workarounds won't solve this issue and may, potentially, expose your network to risks (and then, by the way, there's more against using forwarders which aren't under your direct control or, worse, are public resolvers like the google, level3, opendns and other ones) So, my suggestion is to check if your DNS resolvers and your network infrastucture (routers, firewalls...) supports EDNS0 and, if not, to find out where such traffic is dropped and fix the issue See, offloading a problem elsewhere (e.g. using forwarders) doesn't mean resolving it, it just mean applying some kind of workaround (band-aid if you prefer) but you'll then need to be aware of the fact tha the problem will, sooner or later, resurface... so, better really addressing it from the beginning HTH

I understand what you are saying here and I agree work rounds are not the answer. However I am slightly confused about where the cause of the problem is. I thought that the first nslookup test I ran using 4.2.2.6 as the dns resolver proved that the path out from by server (dns resolver) was fine including my firewall and that the failure of the nslookup test using my server as the dns resolver proved that the problem lay with my server and not with any other network equipment. Is this a correct assumption?

I understand what you are saying here and I agree work rounds are not the answer. However I am slightly confused about where the cause of the problem is. I thought that the first nslookup test I ran using 4.2.2.6 as the dns resolver proved that the path out from by server (dns resolver) was fine including my firewall and that the failure of the nslookup test using my server as the dns resolver proved that the problem lay with my server and not with any other network equipment. Is this a correct assumption? Bob... if I understood you correctly, you're saying that you ran the "tests" I suggested and found that you only have issues when you use your own resolvers If that's the case, then you should check your own resolvers to find out what's stopping them from using EDNS0 "oversized" packets; once you'll find that you'll also solve your other issue (imHO btw) What else... yes; if possible, post the results of your "EDNS0 tests" (nslookup...) by the way, if you feel like so, mask your own IPs; not a problem

Have re-run the EDNS0 tests, results below. This time the tests with my server as the resolver sometimes gave good results and sometimes bad. Suggests to me that the problem is outside my environment and depends on the path taken to the target! Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 4.2.2.6 Server: UnKnown Address: 4.2.2.6 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "4.68.25.4 sent EDNS buffer size 4096" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "4.68.25.4 DNS reply size limit is at least 3843" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:44:06 UTC" C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 4.2.2.6 Server: UnKnown Address: 4.2.2.6 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:44:06 UTC" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "4.68.25.4 sent EDNS buffer size 4096" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "4.68.25.4 DNS reply size limit is at least 3843" C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: 10.0.1.1 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n DNS reply size limit is at least 3843" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n sent EDNS buffer size 4000" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:46:37 UTC" C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: 10.0.1.1 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x476.rs.dns-oarc.net rst.x476.rs.dns-oarc.net canonical name = rst.x485.x476.rs.dns-oarc.net rst.x485.x476.rs.dns-oarc.net canonical name = rst.x490.x485.x476.rs.dns-oarc. net rst.x490.x485.x476.rs.dns-oarc.net text = "n.n.n.n DNS reply size limit is at least 490" rst.x490.x485.x476.rs.dns-oarc.net text = "n.n.n.n lacks EDNS, defaults to 512" rst.x490.x485.x476.rs.dns-oarc.net text = "Tested at 2011-10-01 11:48:09 UTC" C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 Server: UnKnown Address: 10.0.1.1 DNS request timed out. timeout was 2 seconds. *** Request to UnKnown timed-out C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 Server: UnKnown Address: 10.0.1.1 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n sent EDNS buffer size 4000" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:49:54 UTC" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n DNS reply size limit is at least 3843" C:\Users\Administrator> Bob

Have re-run the EDNS0 tests, results below. This time the tests with my server as the resolver sometimes gave good results and sometimes bad. Suggests to me that the problem is outside my environment and depends on the path taken to the target! Hi there, welcome back :) ! Let's see your test results Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 4.2.2.6 Server: UnKnown Address: 4.2.2.6 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "4.68.25.4 sent EDNS buffer size 4096" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "4.68.25.4 DNS reply size limit is at least 3843" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:44:06 UTC" Now, the above tells us that between the system on which you ran the above nslookup and the internet there isn't any device truncating "oversized" DNS packets which is good; notice that to perform a good test you should run the above from a command prompt opened on your DNS server C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: 10.0.1.1 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n DNS reply size limit is at least 3843" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n sent EDNS buffer size 4000" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:46:37 UTC" judging from the above, the DNS at 10.0.1.1 is able to run external queries using EDNS0 which is good but then... C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: 10.0.1.1 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x476.rs.dns-oarc.net rst.x476.rs.dns-oarc.net canonical name = rst.x485.x476.rs.dns-oarc.net rst.x485.x476.rs.dns-oarc.net canonical name = rst.x490.x485.x476.rs.dns-oarc. net rst.x490.x485.x476.rs.dns-oarc.net text = "n.n.n.n DNS reply size limit is at least 490" rst.x490.x485.x476.rs.dns-oarc.net text = "n.n.n.n lacks EDNS, defaults to 512" rst.x490.x485.x476.rs.dns-oarc.net text = "Tested at 2011-10-01 11:48:09 UTC" this seems to deny what we saw above; to better understand what you did and what happened, it would be useful to know from which boxes you ran the commands; if the above "failed" nslookup was run from another box (from the one which returned "success" with 10.0.1.1) then probably there's something between such box and 10.0.1.1 which is truncating the EDNS packets C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 Server: UnKnown Address: 10.0.1.1 DNS request timed out. timeout was 2 seconds. *** Request to UnKnown timed-out C:\Users\Administrator>nslookup -type=TXT rs.dns-oarc.net. 10.0.1.1 Server: UnKnown Address: 10.0.1.1 Non-authoritative answer: rs.dns-oarc.net canonical name = rst.x3827.rs.dns-oarc.net rst.x3827.rs.dns-oarc.net canonical name = rst.x3837.x3827.rs.dns-oarc.net rst.x3837.x3827.rs.dns-oarc.net canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n sent EDNS buffer size 4000" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "Tested at 2011-10-01 11:49:54 UTC" rst.x3843.x3837.x3827.rs.dns-oarc.net text = "n.n.n.n DNS reply size limit is at least 3843" while the above seems to be working as needed; again, you'll need to make a note of the boxes on which you run your tests since it allows you (and me... and any other following this discussion) to try finding out and pinpointing the "show stopper" So... assuming 10.0.1.1 is your DNS server, fire up a command prompt there and run an nslookup agains 4.2.2.6 and a second one against the server itself, that is 10.0.1.1; this is ALL you need since it suffices that your DNS resolver (if you have more than one DNS repeat the tests on all your DNS resolvers) is able to carry out EDNS queries; running the same tests on clients or in any case on other boxes isn't usually needed since those won't need to sendout direct DNS queries or, better said, they should NOT be allowed (firewall blocking rules) to send out such queries [edit] A doubt Assuming all the tests you ran (and posted) came from the DNS server itself, the fact that some succeeded while other failed raise some questions, namely Is your DNS server a multihomed machine, that is, does it have multiple IP addresses / network cards and/or multiple gateways ? Are you using multiple wan connections in loadbalance or fault tolerance mode ? In both cases, you should ensure to check ALL the paths your traffic may take and ensure that whatever path will allow using EDNS

Hi ObiWan, 10.0.1.1 is my only DNS server and it has only one network card and there is only one gateway (my firewall) and one WAN connection to the firewall. The Firewall has no other network connections, so only one path to the internet. I ran all tests from the cmd prompt on the dns server. I did notice that there is a slightly longer delay for the failed nslookup than for the successful one before the results are displayed. I provide part time remote support to this network, hence the delay between my postings!

10.0.1.1 is my only DNS server and it has only one network card and there is only one gateway (my firewall) and one WAN connection to the firewall. The Firewall has no other network connections, so only one path to the internet. I ran all tests from the cmd prompt on the dns server. I did notice that there is a slightly longer delay for the failed nslookup than for the successful one before the results are displayed. I provide part time remote support to this network, hence the delay between my postings! Ok, I had to ask about multihoming/multiwan (or load balancing devices) to ensure there was nothing on your side causing the DNS traffic to take different paths to get out to the internet. As for the delay, it's expected, the DNS resolver waits for some time for the answer to get back before "bombing" with a timeout; keep in mind that we're working on UDP which is a connectionless protocol That said; if you were using forwarders, they may have been the issue since in case the DNS was using multiple forwarders and one (or more) of them didn't support EDNS that could cause the issue we observed, but from what you wrote, it sounds like the DNS isn't using any forwarders and is only using root-hints and recursion Now, if the DNS has no forwarders and assuming you checked your firewall settings, QoS/Shaping settings and all the other stuff to ensure that DNS traffic (going to port 53 UDP and TCP) isn't blocked and has a good priority, the only other cause may sit on your ISP/carrier network; in such a case, your ISP/carrier may be routing your traffic through different paths and some of those may be truncating the EDNS packets; in such a case I think that the only way to troubleshoot the issue may be contacting your ISP/Carrier and work together to solve the problem

ObiWan - thanks for your help on this. I have come to the same conclusion that my broadband provider Virgin is sending the requests on different routes. I will take this up with them. I will post the result, if and when this happens.

thanks for your response. I have changed the MaxCachettl to 2 days as suggested in one of the articles on the link you gave and so far the results are good. This does not resolve the 5501 errors in the log which I am pursuing separately.

thanks for your response. I have changed the MaxCachettl to 2 days as suggested in one of the articles on the link you gave and so far the results are good. This does not resolve the 5501 errors in the log which I am pursuing separately. For anyone who has followed this post, I have not had any problems since this change and my ISP denies that there is a problem with their routers!!