EDNS support was released in Server 2003, I think it was SP1. At that time, Yahoo, AOL, and just a couple of others would return lists of IP addresses that wouldn't fit in a standard 512 byte DNS response packet.
At THAT TIME, _most_ firewalls would prevent a UDP response packet of greater than 512 bytes being used. This was especially true of Cisco firewalls (PIX at the time) and various SOHO / SMB firewalls. With Cisco, it was an easy fix (protocol fixup dns 2048 - or some such). For responses greater than 512 bytes, you had to switch to TCP. Lots of folks didn't have TCP 53 open to DNS. So... DNS responses would time out. Today, geographically based responses are common (i.e., you query addresses for yahoo.com, you don't get all of them, you only get a few) and most firewalls have relaxed the restrictions to 1024 or 2048 bytes and most companies have TCP 53 open. So, it's rare - but it still can happen - even on the old operating systems. Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com From: m b [mailto:midphan12...@gmail.com] Sent: Wednesday, December 15, 2010 1:42 PM To: NT System Admin Issues Subject: Re: 2K8R2 DNS anomaly In my experience, I only witnessed & reproduced the issue versus Windows 2008 R2 servers. And they will resolve 99.999% of all queries, just a select few that present a problem. So far, none of the problem domain queries have been business-related. On Wed, Dec 15, 2010 at 12:12 PM, Kennedy, Jim <kennedy...@elyriaschools.org<mailto:kennedy...@elyriaschools.org>> wrote: Your results do indicate the EDNS issue. It is universal...it kills all 2008 servers that I have seen using DNS. As for the 2K3 server, who is it's forwarder? I will bet it's a 2K8 server. From: m b [mailto:midphan12...@gmail.com<mailto:midphan12...@gmail.com>] Sent: Wednesday, December 15, 2010 12:13 PM To: NT System Admin Issues Subject: Re: 2K8R2 DNS anomaly This becomes more interesting. ORCA has set up a reply-size test server (https://www.dns-oarc.net/oarc/services/replysizetest). The results look backwards to me, but follow the pattern of success/failure. An indication that this does have to do with UDP packet size. I'm hesitant to start applying the workaround & turning off EDNS capability. Contacting firewall team for their input. C:\Documents and Settings\me>nslookup -type=txt rs.dns-oarc.net<http://rs.dns-oarc.net/>. (our 2K8 server) Server: (our 2K8 server) Address: (our 2K8 server) DNS request timed out. timeout was 2 seconds. *** Request to (our 2K8 server) timed-out C:\Documents and Settings\me>nslookup -type=txt rs.dns-oarc.net<http://rs.dns-oarc.net/>. (our 2k3 server) Server: (our 2k3 server) Address: (our 2k3 server) DNS request timed out. timeout was 2 seconds. *** Request to (our 2k3 server) timed-out C:\Documents and Settings\me>nslookup -type=txt rs.dns-oarc.net<http://rs.dns-oarc.net/>. (our 2k8r2 server) Server: (our 2k8r2 server) Address: (our 2k8r2 server) Non-authoritative answer: rs.dns-oarc.net<http://rs.dns-oarc.net/> canonical name = rst.x3827.rs.dns-oarc.net<http://rst.x3827.rs.dns-oarc.net/> rst.x3827.rs.dns-oarc.net<http://rst.x3827.rs.dns-oarc.net/> canonical name = rst.x3837.x3827.rs.dns-oarc.net<http://rst.x3837.x3827.rs.dns-oarc.net/> rst.x3837.x3827.rs.dns-oarc.net<http://rst.x3837.x3827.rs.dns-oarc.net/> canonical name = rst.x3843.x3837.x3827.rs.dns-oa rc.net<http://rc.net/> rst.x3843.x3837.x3827.rs.dns-oarc.net<http://rst.x3843.x3837.x3827.rs.dns-oarc.net/> text = "(our 2k8r2 server) DNS reply size limit is at least 3843" rst.x3843.x3837.x3827.rs.dns-oarc.net<http://rst.x3843.x3837.x3827.rs.dns-oarc.net/> text = "(our 2k8r2 server) sent EDNS buffer size 4000" rst.x3843.x3837.x3827.rs.dns-oarc.net<http://rst.x3843.x3837.x3827.rs.dns-oarc.net/> text = "Tested at 2010-12-15 16:55:15 UTC" On Wed, Dec 15, 2010 at 10:23 AM, VIPCS <vi...@stny.rr.com<mailto:vi...@stny.rr.com>> wrote: Jeffrey just tried an nslookup query (results below) on two WS2K8 servers (one is R2) on two different networks and both resolved (both are DCs with DNS installed): Non-authoritative answer: Name: www.insead.edu<http://www.insead.edu/> Address: 213.182.38.52 Is it possible an upstream DNS forwarder is blocking access? Sincerely, Jeffrey and Mary Jane Harris VIPCS ________________________________ From: m b [mailto:midphan12...@gmail.com<mailto:midphan12...@gmail.com>] Sent: Wednesday, December 15, 2010 11:15 AM To: NT System Admin Issues Subject: 2K8R2 DNS anomaly Within our forest, all domain controllers are DNS servers. We've been working to upgrade from 2K3 to 2K8. Most of those that are upgraded are 2K8R2, while a few are just 2K8. I have heard some reports from users that they were unable to access certain websites that they were able to access from home. Today's example is www.insead.edu<http://www.insead.edu/>. When I do an nslookup against any of our 2K8R2 DNS servers, the lookup fails to resolve. If I do that same lookup against any 2K3 or 2K8 DNS server, it is successful. I'm not seeing any common event log errors/warnings among the 2K8R2 DNS servers. My only hunch is root hints. Anyone experienced something similar? ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
