|
|
|
|
||||||
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
Yesterday I put up a new single-server domain and encountered some of the
Windows DNS Server slowness that I've seen a few times before. For some reason, unbeknownst to me, most of my similar installations are fine/fast whereas some are not. Here's what I noticed yesterday on this brand new domain/server: 1. When a client PC's DNS points to LOCAL server only (WS03R2): * The 1st time you ping an external site like google.com there is a long delay (~10 secs) before it says "Pinging google.com [72.14.207.99] with 32 bytes of data". * The 2nd time you ping that external site that delay is gone and it's instant, the way it should be. * The "Reply from" results are fine! They are normal, e.g. 20ms for google.com. No difference in the times whether it's 1st time or 2nd time. * If I do IP release/renew, then pinging same site will have the 10 second delay for the 1st time, then not the 2nd time. * I also found some sluggish web-browsing, that seemed similar, but wasn't quite as clear & predictable as the pings. 2. When a client PC's DNS points to ISP's servers only: * There is never any ping delay as described above... the "Pinging google.com..." line appears instantly * There is no difference between 1st time & 2nd time pings... they are all fast. * The "Reply from" results are the same as above, i.e. 20ms for google.com * Web-browsing seems to load new sites faster, but again it wasn't quite as clear-cut as w/ pings. So it's clear that using the local Windows DNS Server is causing some delay on lookups. And the delay seems more with the DNS server's initial response rather than subsequently. Also note that when the packets actually route to external IP addresses (e.g. ping to Google.com at 72.14.207.99) they do that normally and quickly so it seems more a DNS problem than a routing problem. AHA! I just had a thought (after I wrote this really long post of course!)... This Windows DNS Server was set up to have a single forwarder: the local router/gateway. Whereas sometimes in the past I have created forwarders to the ISP's DNS servers instead. BTW, I did the single local forwarder because I had to setup the LAN at one location (ISP) and then shut it down and move everything to another location (different ISP) so I figured this would be easier, requiring less DNS Server changes. Could this be the problem? Could the local router/gateway hop be introducing the 10 second delay? But if so, I would think that Windows DNS Server would cache the lookup records so that once it knew that google.com = 72.14.207.99 it would just reply to my client instantly with that info so the ping tests could begin. But in my case that doesn't seem to happen. As I said above, if I do a release/renew and try pinging google.com again, the 10 second delay comes back the 1st time but not the 2nd time. The domain is now temporarily off and unavailable so I can't test it remotely. But I'll be back on-site in a couple of days and can do some more troubleshooting then. As always, thanks in advance! (and sorry for this really long initial post) -Rich |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
"Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message news:e7nTyUKbHHA.4000@TK2MSFTNGP02.phx.gbl... > Yesterday I put up a new single-server domain and encountered some of the > Windows DNS Server slowness that I've seen a few times before. For some > reason, unbeknownst to me, most of my similar installations are fine/fast > whereas some are not. > > Here's what I noticed yesterday on this brand new domain/server: > > 1. When a client PC's DNS points to LOCAL server only (WS03R2): Internal clients MUST do this. > * The 1st time you ping an external site like google.com there is a long > delay (~10 secs) before it says "Pinging google.com [72.14.207.99] with 32 > bytes of data". Check with NSLookup so you can eliminate the other things from the DNS resolution. > * The 2nd time you ping that external site that delay is gone and it's > instant, the way it should be. It's getting it from cache on your CLIENT or internal DNS server the second time -- if you use NSLookup the second time will show "non-authoritative" lookup when it comes out of cache. NSLookup also bypasses the client cache. > * The "Reply from" results are fine! They are normal, e.g. 20ms for > google.com. No difference in the times whether it's 1st time or 2nd time. > * If I do IP release/renew, then pinging same site will have the 10 > second delay for the 1st time, then not the 2nd time. Release shouldn't affect the DNS server cache or even the client side cache but perhaps it is doing the latter. IPConfige /flushdns makes clearing the client cache explicit. > * I also found some sluggish web-browsing, that seemed similar, but > wasn't quite as clear & predictable as the pings. > > 2. When a client PC's DNS points to ISP's servers only: If you have internal resources (esp. a domain) this is NOT possible for reliable operation. > * There is never any ping delay as described above... the "Pinging > google.com..." line appears instantly > * There is no difference between 1st time & 2nd time pings... they are > all fast. > * The "Reply from" results are the same as above, i.e. 20ms for > google.com > * Web-browsing seems to load new sites faster, but again it wasn't quite > as clear-cut as w/ pings. > > So it's clear that using the local Windows DNS Server is causing some > delay on lookups. And the delay seems more with the DNS server's initial > response rather than subsequently. Also note that when the packets > actually route to external IP addresses (e.g. ping to Google.com at > 72.14.207.99) they do that normally and quickly so it seems more a DNS > problem than a routing problem. Perhaps the internal DNS server is doing recursion (with or without Forwarding) and could best FORWARD to the ISP or another internet resolving DNS server. > AHA! I just had a thought (after I wrote this really long post of > course!)... > > This Windows DNS Server was set up to have a single forwarder: the local > router/gateway. Is that router DNS functioning correctly? Test explicitly with NSlookup again. NSLookup www.google.com IP.Address.Router.DNS > Whereas sometimes in the past I have created forwarders to the ISP's DNS > servers instead. BTW, I did the single local forwarder because I had to > setup the LAN at one location (ISP) and then shut it down and move > everything to another location (different ISP) so I figured this would be > easier, requiring less DNS Server changes. > > Could this be the problem? Could the local router/gateway hop be > introducing the 10 second delay? Yes, especially if it isn't working at all. > But if so, I would think that Windows DNS Server would cache the lookup > records so that once it knew that google.com = 72.14.207.99 it would just > reply to my client instantly with that info so the ping tests could begin. Yes. Once it gets in cache it should be fast -- cache on client OR server. > But in my case that doesn't seem to happen. As I said above, if I do a > release/renew and try pinging google.com again, the 10 second delay comes > back the 1st time but not the 2nd time. > > The domain is now temporarily off and unavailable so I can't test it > remotely. But I'll be back on-site in a couple of days and can do some > more troubleshooting then. > > As always, thanks in advance! (and sorry for this really long initial > post) > > -Rich > |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
Thanks for the prompt reply Herb. Sorry it took me longer to respond. ;-)
See my comments/questions in-line below... "Herb Martin" <news@learnquick.com> wrote in message news:ua7l9XLbHHA.4616@TK2MSFTNGP03.phx.gbl... > > "Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message > news:e7nTyUKbHHA.4000@TK2MSFTNGP02.phx.gbl... >> Yesterday I put up a new single-server domain and encountered some of the >> Windows DNS Server slowness that I've seen a few times before. For some >> reason, unbeknownst to me, most of my similar installations are fine/fast >> whereas some are not. >> >> Here's what I noticed yesterday on this brand new domain/server: >> >> 1. When a client PC's DNS points to LOCAL server only (WS03R2): > > Internal clients MUST do this. Yes I know that this is required for AD clients (e.g. joined XP computers) this but for testing purposes I wanted to try short-circuiting the Windows DNS Server setup. I >> * The 1st time you ping an external site like google.com there is a long >> delay (~10 secs) before it says "Pinging google.com [72.14.207.99] with >> 32 bytes of data". > > Check with NSLookup so you can eliminate the other things from the > DNS resolution. You mean just do a simple "nslookup google.com" instead of "ping google.com" and see if there is any delay? >> * The 2nd time you ping that external site that delay is gone and it's >> instant, the way it should be. > > It's getting it from cache on your CLIENT or internal DNS server the > second time > -- if you use NSLookup the second time will show "non-authoritative" > lookup > when it comes out of cache. > > NSLookup also bypasses the client cache. Yes that seems logical that the first time it's not from cache thus slower, and the 2nd time it's from cache. But still some things don't ring true... Even with a non-cache lookup, 10 seconds of delay seems way excessive, indicative of something significantly wrong, no? I don't have access to the customer's domain right now (I should be firing it up Monday) but on my own domain in my office when I do NSLookup I always get "Non-authoritative" as the response from any external domains like google.com or dell.com. The only time I do NOT get "Non-authoritative" is when I do nslookup of the AD domain itself. What can we conclude from that? >> * The "Reply from" results are fine! They are normal, e.g. 20ms for >> google.com. No difference in the times whether it's 1st time or 2nd >> time. >> * If I do IP release/renew, then pinging same site will have the 10 >> second delay for the 1st time, then not the 2nd time. > > Release shouldn't affect the DNS server cache or even the client side > cache but perhaps it is doing the latter. > > IPConfige /flushdns makes clearing the client cache explicit. I definitely saw a clear reset of the DNS situation when I did release/renew. It's as if it cleared the wkstn cache and that caused a 1st time delay. (but still 10 second delay seems way excessive) On my own domain (NOT the customer's where I was seeing delays before) when I did /flushdns on my wkstn, I didn't see any difference in results. But then with Pings on my domain, I've never experienced the 1st time delays so I don't know if this test tells anything. Also, after doing /flushdns I see no difference (again on my own domain) in NSLookup replies of "Non-authoritative". It's as I mentioned above. I *always* get "Non-authoritative" as an answer for external domains, and the only one I don't get this on is my local AD domain. So I'm not sure "Non-authoritative" has anything to do w/ wkstn cache. >> * I also found some sluggish web-browsing, that seemed similar, but >> wasn't quite as clear & predictable as the pings. >> >> 2. When a client PC's DNS points to ISP's servers only: > > If you have internal resources (esp. a domain) this is NOT possible for > reliable operation. Yes I know. I was only doing this for testing to isolate the cause of delays. >> * There is never any ping delay as described above... the "Pinging >> google.com..." line appears instantly >> * There is no difference between 1st time & 2nd time pings... they are >> all fast. >> * The "Reply from" results are the same as above, i.e. 20ms for >> google.com >> * Web-browsing seems to load new sites faster, but again it wasn't quite >> as clear-cut as w/ pings. >> >> So it's clear that using the local Windows DNS Server is causing some >> delay on lookups. And the delay seems more with the DNS server's initial >> response rather than subsequently. Also note that when the packets >> actually route to external IP addresses (e.g. ping to Google.com at >> 72.14.207.99) they do that normally and quickly so it seems more a DNS >> problem than a routing problem. > > Perhaps the internal DNS server is doing recursion (with or without > Forwarding) > and could best FORWARD to the ISP or another internet resolving DNS > server. The internal DNS server (DC) had a single forwarder defined (the Sonicwall TZ-170 router/gateway) and was using the default recursion setting, i.e. the box that says "Do not use recursion" was UNchecked. I've always thought that recursion was generally good for fault-tolerance, and left it because it was the default... right? >> AHA! I just had a thought (after I wrote this really long post of >> course!)... >> >> This Windows DNS Server was set up to have a single forwarder: the local >> router/gateway. > > Is that router DNS functioning correctly? Test explicitly with NSlookup > again. I'm pretty sure it was functioning fine, but I won't be able to confirm w/ any nslookup's until Mon/Tues when I fire everything up at the new production location. > NSLookup www.google.com IP.Address.Router.DNS When I try that on my own office's domain, the reply works fine & fast, but I get this at the beginning "Can't find server name... non-existent domain... Server: UnKnown". I presume this is normal response for NSLookup when it's going against a router that has nothing to do with an AD domain per se. Right? >> Whereas sometimes in the past I have created forwarders to the ISP's DNS >> servers instead. BTW, I did the single local forwarder because I had to >> setup the LAN at one location (ISP) and then shut it down and move >> everything to another location (different ISP) so I figured this would be >> easier, requiring less DNS Server changes. >> >> Could this be the problem? Could the local router/gateway hop be >> introducing the 10 second delay? > > Yes, especially if it isn't working at all. Well the Sonicwall was clearly working in general. Can't say I tested its DNS specifically (yet) but when I do I'll report back. Are you saying that IF the Sonicwall's DNS was NOT working right, and if the local Windows DNS Server forwards only to the Sonicwall and if forwarder recursion is enabled on the Windows Server then my symptoms could happen? IOW, the 1st time lookup could produce 10 sec delay (recursion) but subsequent lookups would be instant (cache)? >> But if so, I would think that Windows DNS Server would cache the lookup >> records so that once it knew that google.com = 72.14.207.99 it would just >> reply to my client instantly with that info so the ping tests could >> begin. > > Yes. Once it gets in cache it should be fast -- cache on client OR > server. Yeah, so this is why I'm most puzzled. I don't get the the 10 second delay thing. I figure that once the local DNS server learns the IP's the first time for google.com then there should never every be a delay in starting a ping. But as stated earlier, I found that the 10 sec delay would come back, e.g. on release/renew. Anyway, you can give me any generic answers to the above that you want to. And by Tuesday I hope to have the problematic network fired up at the new location (new ISP) and whatever results I get there I'll report back. Thanks again Herb for all your time!!! -Rich >> But in my case that doesn't seem to happen. As I said above, if I do a >> release/renew and try pinging google.com again, the 10 second delay comes >> back the 1st time but not the 2nd time. >> >> The domain is now temporarily off and unavailable so I can't test it >> remotely. But I'll be back on-site in a couple of days and can do some >> more troubleshooting then. >> >> As always, thanks in advance! (and sorry for this really long initial >> post) >> >> -Rich >> > > |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
"Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message news:uMYGMXZbHHA.2552@TK2MSFTNGP06.phx.gbl... > Thanks for the prompt reply Herb. Sorry it took me longer to respond. ;-) > See my comments/questions in-line below... > Show me the unedited text from "IPConfig /all" |
|
|
|
#5 |
|
Messages: n/a
Hébergeur: |
Hmm... I guess my last post was a waste.
Maybe rather than talk about DNS theory & how it should/does work, I'll just wait to see what happens when I power the network up in the new location. -Rich p.s. No problems with doing an "IPConfig /all" but I assume you mean for the customer domain where I was seeing the delays rather than for my own domain. If so, that's no possible until it gets powered up Mon/Tues. Still I'm not sure how much more ipconfig is going to tell you that we haven't already discussed. "Herb Martin" <news@learnquick.com> wrote in message news:eE2JHbZbHHA.2188@TK2MSFTNGP04.phx.gbl... > > "Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message > news:uMYGMXZbHHA.2552@TK2MSFTNGP06.phx.gbl... >> Thanks for the prompt reply Herb. Sorry it took me longer to respond. >> ;-) See my comments/questions in-line below... >> > > Show me the unedited text from "IPConfig /all" > |
|
|
|
#6 |
|
Messages: n/a
Hébergeur: |
"Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message news:u0gR50bbHHA.5044@TK2MSFTNGP05.phx.gbl... > Hmm... I guess my last post was a waste. > > Maybe rather than talk about DNS theory & how it should/does work, I'll > just wait to see what happens when I power the network up in the new > location. Actually it is better to UNDERSTAND DNS and fix it. My next guess is that you don't have the Client machines set to use STRICTLY the Internal DNS servers which are all working. > p.s. No problems with doing an "IPConfig /all" but I assume you mean for > the customer domain where I was seeing the delays rather than for my own > domain. Yes, I mean for the specifically for the client computer with The Problem. > If so, that's no possible until it gets powered up Mon/Tues. Still I'm > not sure how much more ipconfig is going to tell you that we haven't > already discussed. It will let me look at the DNS entries and compare that to the Router, WINS (if any), and the subnet the client computer is on. |
|
|
|
#7 |
|
Messages: n/a
Hébergeur: |
Herb,
Don't know what you mean exactly by "strictly" but as mentioned at the beginning, the clients are set by DHCP to use one and only one DNS server, the only local DNS server (WS03R2) on this small single-server domain. This thread seems to be unravelling a bit. (pun intended!) Remember that I got these delays when I was setting the new domain up in a test environment before it was to be moved to it's final production location (different ISP). Just in case this variable (location/ISP) is significant to the problem, I think it best for me to try it in the new location and see if the problem perisists and if so then we can tighten up this thread. I anticipate Mon/Tues to have things up in production. -Rich "Herb Martin" <news@learnquick.com> wrote in message news:%23Z9lrQcbHHA.1388@TK2MSFTNGP05.phx.gbl... > > "Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message > news:u0gR50bbHHA.5044@TK2MSFTNGP05.phx.gbl... >> Hmm... I guess my last post was a waste. >> >> Maybe rather than talk about DNS theory & how it should/does work, I'll >> just wait to see what happens when I power the network up in the new >> location. > > Actually it is better to UNDERSTAND DNS and fix it. > > My next guess is that you don't have the Client machines set to use > STRICTLY > the Internal DNS servers which are all working. > >> p.s. No problems with doing an "IPConfig /all" but I assume you mean for >> the customer domain where I was seeing the delays rather than for my own >> domain. > > Yes, I mean for the specifically for the client computer with The Problem. > >> If so, that's no possible until it gets powered up Mon/Tues. Still I'm >> not sure how much more ipconfig is going to tell you that we haven't >> already discussed. > > It will let me look at the DNS entries and compare that to the Router, > WINS (if any), and the subnet the client computer is on. > > |
|
|
|
#8 |
|
Messages: n/a
Hébergeur: |
"Rich Roller" <rich@*REMOVE-THIS*r2c.com> wrote in message news:e9%23M%23mcbHHA.3616@TK2MSFTNGP05.phx.gbl... > Herb, > > Don't know what you mean exactly by "strictly" but as mentioned at the Clients must NEVER use two different (sets of) DNS servers would return different information -- they must use "strictly" (only) those which can resolve ALL of the names the clients will ever (legitimately) need, whether internal or external. A common mistake is for some one to set the internal DNS Server(s) as Preferred and (incorrectly) set the ISP or other DNS server(s) as alternates. This is never reliable. > beginning, the clients are set by DHCP to use one and only one DNS server, Then it doesn't matter -- if the internal DNS server is the ONLY one then it has to be a correct list and the internal server is responsible (as it should be) for all internal and external resolutions. > the only local DNS server (WS03R2) on this small single-server domain. Good. > This thread seems to be unravelling a bit. (pun intended!) Remember that > I got these delays when I was setting the new domain up in a test > environment before it was to be moved to it's final production location > (different ISP). If your internal server is using a forward (set) test each of these explicitly (in order) and remove any that aren't responding. Then consider Checking "Do not use recursion" -- this should not be necessary but is generally a good idea and sometimes (without explanation) seems to speed things up -- if this s or resolves the problem PLEASE let me know as I am "collecting" instances where this s despite being unable to rationally explain why it does so. > Just in case this variable (location/ISP) is significant to the problem, I > think it best for me to try it in the new location and see if the problem > perisists and if so then we can tighten up this thread. I anticipate > Mon/Tues to have things up in production. Good. You don't have to answer immediately to keep *me* interested -- I generally put "Watches" on all threads and will most likely see them highlighted when anyone adds to the thread. -- Herb Martin, MCSE, MVP http://www.LearnQuick.Com (phone on web site) |
|
![]() |
| Outils de la discussion | |
|
|