Slow logon time

  • Thread starter Thread starter Al Morrison
  • Start date Start date
A

Al Morrison

It is taking about 2 minutes to log on to our new domain.
I was told it was a DNS issue on the client side. Not
sure what exacly this means. We are obtaining out IP and
DNS from a Cisco router (DHCP) and each client is set up
with "obtain IP from ....". Anyways, any suggestions
would be great.

Al Morrison
 
Hi Danny:

Thanks for your info. Just for clarification. I have
only one server functioning as domain controller. Do I
need to configure the TCP/IP properties as per your link
or do I need to run the DNS Server also. If so does the
"Forward Lookup Zone" point back to my one server IP
address?

Thanks again for the help.

Allan
 
Hi Again:

It's late and my head is pounding from a day glued to the
server... anyways, what you are saying is that rather
than the clients pointing to the ISP DNS that they point
to the Domain controller which has AD on it. Is this
right?

Presently, all clients have "obtain auto. DNS" within
their network conftg.

Thanks again.

Al
 
In Al Morrrison <[email protected]>
posted their concerrns,
Then Kevin D4Dad added his reply at the bottom.
Hi Again:

It's late and my head is pounding from a day glued to the
server... anyways, what you are saying is that rather
than the clients pointing to the ISP DNS that they point
to the Domain controller which has AD on it. Is this
right?

Presently, all clients have "obtain auto. DNS" within
their network conftg.

Thanks again.

Al
Click to expand...

All clients and servers served by this domain controller must point to its
DNS servers' address. This is required for Active Directory to function
properly.
 
That's right. Set up forwarders in DNS on your DC. Point
forwarders to the ISP. Then in the client's TCP/IP
settings, set the address of the DC as the preferred DNS
address.

Chris C
 
That's right. Set up forwarders in DNS on your DC. Point forwarders to the
ISP. Then in the client's TCP/IP settings, set the address of the DC as
the preferred DNS address.
Click to expand...

Why do people continue to recommend this? Let the DNS server do it's job
and resolve all DNS queries for you. So long as you delete the root zone
if it exists and so long as the root hints are there - which they should
be - the server can resolve any Internet host you want. There is no need
to rely on your ISP's DNS servers by setting up forwarders.

--
John LeMay
kc2kth
Senior Technical Manager
NJMC | http://www.njmc.com | Phone 732-557-4848
Specializing in Microsoft and Unix based solutions
 
In John LeMay <[email protected]>
posted their concerrns,
Then Kevin D4Dad added his reply at the bottom.
Why do people continue to recommend this? Let the DNS server do it's
job and resolve all DNS queries for you. So long as you delete the
root zone
if it exists and so long as the root hints are there - which they
should
be - the server can resolve any Internet host you want. There is no
need
to rely on your ISP's DNS servers by setting up forwarders.
Click to expand...

There is nothing wrong with using a forwarder, by using a forwarder,
provided that the forwarder you use is relatively secure, you can greatly
reduce the load on your DNS server. Enabling forwarders does not stop it
from still being able to resolve names on its own, unless you check "Do not
use recursion", it will still use its root hints if the forwarders time out.
 
In
John LeMay said:
Why do people continue to recommend this? Let the DNS server do it's
job and resolve all DNS queries for you. So long as you delete the
root zone
if it exists and so long as the root hints are there - which they
should
be - the server can resolve any Internet host you want. There is no
need
to rely on your ISP's DNS servers by setting up forwarders.

--
John LeMay
kc2kth
Senior Technical Manager
NJMC | http://www.njmc.com | Phone 732-557-4848
Specializing in Microsoft and Unix based solutions
Click to expand...

It's recommended because it's less work on your DNS server. If your server
must resolve thru the Roots, which creates additional steps & traffic.
Albeit, might not be much extra in either regard, but magnify that in a
large envoronment. Your server may also be running other services, which
would contribute to more work load in addition to recursive search using
the Roots.

This could be a point of failure. You could add two or more in the list. You
wouldn't have to rely on that one ISP or outside nameservers in general, but
rather use that as a first step. Keep "Do Not Use Recursion" in the
Forwarders tab unchecked. It'll query the ISP's, if no answer, then it hits
the Roots.

http://support.microsoft.com/?id=291382


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
There is nothing wrong with using a forwarder, by using a forwarder,
provided that the forwarder you use is relatively secure, you can greatly
reduce the load on your DNS server. Enabling forwarders does not stop it
from still being able to resolve names on its own, unless you check "Do
not use recursion", it will still use its root hints if the forwarders
time out.
Click to expand...

How much load is a DC serving as your DNS server REALLY under? I
understand your argument, but I don't believe it really applies that well
in the real world. If I have an environment with 50 clients and two
DCs/DNS servers I can split the load across the two DNS servers (alternate
DNS server entries on the clients through any one of a number of methods -
manual, DHCP, virtual IP, etc.) and neither server will ever really get
hit that hard - not even between 8 and 9 am or between 12 and 1 pm <g>.

In smaller environments, a single server built properly (decent hardware,
CPU, RAM, disks, etc) can handle the load of DC and DNS as well as file
and print server without bogging down.

In larger environments using a dedicated caching only DNS server (well, a
couple of them anyhow) and setting up DC's that are DNS servers to forward
to it (the caching server) makes a lot of sense.

However, forwarding to a host that is on the Internet already just doesn't
convince me that you are saving anything. The gain found by reducing the load on
the DCs will most likely be lost in performance by the latency of
waiting for the request to come back from an Internet host.

--
John LeMay
kc2kth
Senior Technical Manager
NJMC | http://www.njmc.com | Phone 732-557-4848
Specializing in Microsoft and Unix based solutions
 
It's recommended because it's less work on your DNS server. If your server
must resolve thru the Roots, which creates additional steps & traffic.
Albeit, might not be much extra in either regard, but magnify that in a
large envoronment. Your server may also be running other services, which
would contribute to more work load in addition to recursive search using
the Roots.
Click to expand...

In a large environment one has more than a single DNS server that is also
acting as a DC. Caching only servers are highly recommended in these
environments for this and many other reasons (SPOF, bandwidth, etc.)
Besides, in a larger environment (and I'm talking large here) I would bet
forwarding all your queries to your ISP would really piss them off and
might get you a slap on the wrist from the ISP. They don't want the extra
load any more than you do.

In a smaller environment chances are you won't notice a performance hit by
resolving locally compared with the latency introduced by using an
Internet host for name resolution.

I really think the argument you provide applies only in a minute
percentage of cases, if at all. While it looks good on paper, it doesn't
account for many factors that will have a negative impact on the process.

My recommendation is to overbuild the servers a bit in the first place and
handle all the name resolution stuff myself. Maybe it's a control thing.

--
John LeMay
kc2kth
Senior Technical Manager
NJMC | http://www.njmc.com | Phone 732-557-4848
Specializing in Microsoft and Unix based solutions
 
In John LeMay <[email protected]>
posted their concerrns,
Then Kevin D4Dad added his reply at the bottom.
How much load is a DC serving as your DNS server REALLY under? I
understand your argument, but I don't believe it really applies that
well
in the real world. If I have an environment with 50 clients and two
DCs/DNS servers I can split the load across the two DNS servers
(alternate
DNS server entries on the clients through any one of a number of
methods - manual, DHCP, virtual IP, etc.) and neither server will
ever really get
hit that hard - not even between 8 and 9 am or between 12 and 1 pm
<g>.

In smaller environments, a single server built properly (decent
hardware,
CPU, RAM, disks, etc) can handle the load of DC and DNS as well as
file
and print server without bogging down.

In larger environments using a dedicated caching only DNS server
(well, a couple of them anyhow) and setting up DC's that are DNS
servers to forward
to it (the caching server) makes a lot of sense.

However, forwarding to a host that is on the Internet already just
doesn't convince me that you are saving anything. The gain found by
reducing the load on the DCs will most likely be lost in performance
by the latency of
waiting for the request to come back from an Internet host.
Click to expand...

You must realize that in an AD enviornment that the entire network is
reliant on DNS and continually uses DNS for for every thing you do across
the LAN That is how clients find the domain controllers. Speed may be the
only issue you are looking at on a per client basis. There are other factors
involved here, using root hints only requires more bandwidth through the
internet link, if you have a limited bandwith then you can start getting
other errors from the loss of bandwidth, pretty common these days are 5504
events which can be caused by the link being clogged.

All in all it is best practice to let your DNS server proxy out as many
requests as it can and save the bandwidth for better purposes. Unless say,
you are sitting on a 45Mb trunk. (That may be somewhat overstated)
 
Could you clarify. At this point I am told to ensure the DC has DNS set
up in network properties pointing to itself and that the DNS server has
forwarders to the IPS.

In the client, I should remove the DNS setting (which is now automatic)
and point it to the DC - not the ISP.

Is this right? If not, could you give step-by-step solution to my error.
Thanks.
Click to expand...

Hi Allan,

Ignore the forwarders issue for now - it will not effect what you are
trying to accomplish either way.

Assuming you do not have access to the Cisco router to alter the DHCP
configuration, go to each client and manually set their DNS servers to
point to the AD server. This will fix the login issue you are having. A
reboot may be required depending on the client OS.

If you do have access to change the Cisco DHCP server settings, change the
DNS server entries in the DHCP scopt to point only to the AD server. Renew
the lease on a client station, verify you received the new DNS server
settings, and try to login again.

Once everything works and you can login in under 2 minutes, you could go
back to the router and add in one of the ISP's DNS servers as a secondary
DNS server in the DHCP scope, but it's probably not necessary.


--
John LeMay
kc2kth
Senior Technical Manager
NJMC | http://www.njmc.com | Phone 732-557-4848
Specializing in Microsoft and Unix based solutions
 
AF> It's recommended because it's less work on your DNS server.

It should be recommended because it is _less traffic over the link_.

However, there are equally valid reasons for _not_ using a proxy DNS service
provided by one's ISP, which must be weighed against this. One is that it
leaves one vulnerable to whatever weaknesses and misconfigurations the ISP's
proxy DNS server has. (e.g. If the ISP's proxy DNS server is vulnerable to
cache poisoning, then so is everyone who forwards queries to it.) Another is
that the ISP's selection of DNS namespace might not match what one wants.
(e.g. Some ISPs still don't use the augmented root.) A third is that it far
easier to diagnose, and to avert, query resolution problems if the resolving
proxy DNS server is under one's own direct control. (e.g. It's far quicker to
slap a quick database override into one's own resolving proxy DNS server to
avoid someone else's duff delegation than it is to contact one's ISP and
persuade it to do the same. It's also far easier to diagnose a query
resolution problem when one can look at the log and _see_ what content DNS
servers are being sent what queries.)
 
I pointed the client to the DC and log on time is excellent. However,
they cannot see the internet now? Did I incorrecly configure the server?

Allan
Click to expand...

Possibly.

Can you access the Internet from the server?

There are not a "." zone in your DNS configuration on the server, correct?
(If there is, delete it)

How did you change the client config? Do you still have the default
gateway of the client properly defined as the Cisco router?

--
John LeMay
kc2kth
Senior Technical Manager
NJMC | http://www.njmc.com | Phone 732-557-4848
Specializing in Microsoft and Unix based solutions
 
JLM> Why do people continue to recommend this?

Partly for sound technical reasons; but (yes) also partly because the notion
that everything should be handed off to one's ISP (irrespective of the actual
technical pros and cons) is endemic, and partly because two separate pieces of
advice ("The DNS Clients on Microsoft Windows machines must always be
configured to use only one's own local DNS server(s) if Active Directory, and
thus 'split-horizon' DNS service, is being used." and "You can configure your
local DNS server(s) to forward to your ISP's proxy DNS server if the benefits
happen to outweigh the costs.") have been conflated into one.
 
KDGS> You must realize that in an AD enviornment that the entire
KDGS> network is reliant on DNS and continually uses DNS for for
KDGS> every thing you do across the LAN[. ] That is how clients
KDGS> find the domain controllers.

This has no bearing upon upon whether or not one employs forwarding, however.
The query traffic that you refer to deals purely with the "internal" portion
of the DNS namespace, and thus _in either case_ wouldn't result in DNS traffic
over the link to the rest of the world. Moreover, the CPU and I/O load placed
upon the DNS server itself in handling that particular traffic is not lessened
by employing forwarding.

KDGS> All in all it is best practice to let your DNS server proxy
KDGS> out as many requests as it can and save the bandwidth for
KDGS> better purposes. Unless say, you are sitting on a 45Mb trunk.
KDGS> (That may be somewhat overstated)

It's actually vastly overstated. In general, the amount of IP traffic
relating to DNS service, even if one has one's own resolving proxy DNS server,
is dwarfed by the amount of IP traffic relating to SMTP, HTTP, NNTP, and the
like. If one's link is too small to handle the traffic to and from one's
resolving proxy DNS server, then it is certainly too small to handle one's
SMTP, HTTP, NNTP, and other traffic. Performing query resolution onesself
does not, of itself, require one to have a high bandwidth link.

Put another way: If one is concerned about opmimal use of an expensive or
congested link, then if one has not _already_ deployed one's own caching proxy
HTTP server at the near end of the link it shows a marked lack of perspective
if one decides to configure a forwarding proxy DNS server "in order to reduce
the traffic over the link". But, on the other hand, if one _has_ already
dealt with the duplicated and unnecessary traffic caused by other procotols,
then deploying forwarding DNS service instead of resolving DNS service will -
indeed - yield a minor additional benefit.

But, on the gripping hand, there are other considerations, already mentioned
in this thread, that weigh against the savings in traffic over the link.
 
In Jonathan de Boyne Pollard <[email protected]>
posted their concerns,
Then Kevin D4Dad added his reply at the bottom.
KDGS> You must realize that in an AD environment that the entire
KDGS> network is reliant on DNS and continually uses DNS for
KDGS> every thing you do across the LAN[. ] That is how clients
KDGS> find the domain controllers.
Click to expand...
JDBP> This has no bearing upon upon whether or not one employs forwarding,
JDBP> however.

This is correct Jonathan, I was only stating that an internal DNS server in
an AD environment is under continuous load anyway from handling local
traffic it is my opinion that a DNS server requires less CPU to do a simple
query than a recursive query, (makes sense to me) why not let you ISP's DNS
do the recursive lookups. They are getting your money and you are paying
extra and should be. (At least I pay extra for the enhanced service)
KDGS> All in all it is best practice to let your DNS server proxy
KDGS> out as many requests as it can and save the bandwidth for
KDGS> better purposes. Unless say, you are sitting on a 45Mb trunk.
KDGS> (That may be somewhat overstated)
Click to expand...
JDBP> It's actually vastly overstated. In general, the amount of IP traffic
JDBP> relating to DNS service, even if one has one's own resolving proxy
JDBP> DNS server, is dwarfed by the amount of IP traffic relating to SMTP,
JDBP> HTTP, NNTP, and the like. If one's link is too small to handle the
JDBP> traffic to and from one's resolving proxy DNS server, then it is
JDBP> certainly too small to handle one's SMTP, HTTP, NNTP, and other
JDBP> traffic. Performing query resolution onesself does not, of itself,
JDBP> require one to have a high bandwidth link.

I overstated it to try to make it clear, you are correct that DNS is
miniscule in relation to other traffic, but if the link is congested for
what ever reason, DNS will pay a proportional price and some DNS packets
will get lost which can cause 5504 Warnings in the event log. These are hard
to diagnose because they can also be caused by invalid characters. But if
you are getting 5504s using forwarders can reduce them provided the DNS you
are forwarding to can handle the traffic.
 
Back
Top