Users can't register DNS unless they have Admin rights

I have a technician that is having this situation in a few sites. He logs a domain user to his/her machine and the users can't resolve names. Try to use Outlook 2003 and can't find the server. If he setup the domain user as a local admin then he can resolve names and everything works fine. Where should I look to troubleshoot this problem. I always thought that DNS registration didn't have anything to do with the user on the computer. Thanks!
Who is Participating?
calvinetterConnect With a Mentor Commented:
  Assuming you have DNS setup "properly", ie clients *only* point to your local DNS server(s) (ie DCs w/ DNS installed, etc), local DNS servers have ISP DNS servers configured  as their forwarders, the root ('.') zone has been removed if it was present, then DNS resolution will happen as follows (a bit simplified):
  Any DNS request for a hostname/domain that isn't a part of your local DNS/AD domain, the DNS server will know that it isn't in the local DNS zone that it is responsible for, so it forwards the request to the configured ISP DNS servers.  As long as the hostname exists somewhere, the local client will get a response & be able to resolve the IP of the remote host.

>a DNS server on the Internet will provide name resolution regardless of the ISP, right?

>I was under the impression...that I need to have each site using the ISP DNS settings.
  Re-reading 1 of your earliers posts above, it sounds like you may have the following setup (please clarify if this isn't the case):
- corporate HQ office w/ local DNS server (DC or otherwise); for illustration, let's say your internal AD domain is "corp.local"
- 40 branch offices each w/ their own Internet connection
- (all?) branch offices have a local DNS server on the internal LAN?
- Are all branch office hosts members of the "corp.local" AD domain, same as the corporate HQ?  If so, that would indicate all branch offices have some method to get to the internal LAN at the HQ, such as via a site-to-site VPN connection or a private leased line.  Is this the case?

  If all of the above is true, here's how I'd recommend configuring DNS:
(Agree w/ jessmca above: use your local DNS servers as much as possible)
- Local DNS servers at each branch have DNS configured as follows:  
  A) DNS updates for the entire "corp.local" domain are synchronized with main DNS server(s) at corp HQ (preferably w/ DNS configured as type "AD-integrated")
  B) root forward lookup zone ('.') has been deleted from the local DNS server configs
  C) DNS settings on NIC of local DNS servers: each server points to it's own IP for DNS resolution; eg, if the server's IP is, your only configured DNS server *on the NIC of that server* is (itself).
  D) local DNS server has DNS forwarders configured for the local ISP serving that branch office

- Local clients at each branch office configured as follows:
  A) If IP is provided by DHCP, the *only* DNS server provided would be the local DNS server(s)
  B) If IP is configured manually on a PC, also point only to local DNS server(s)

This way, at each branch office, DNS can be resolved for both the "corp.local" AD domain & also for Internet addresses.  Local DNS servers are used by their local workstations, saving your main corp HQ DNS server(s) from being bogged down by requests from all 40 branches.

You are correct in thinking that the PC user does not need to be admin.   DNS registration is when the PC itself registers itself within an Active Directory Integrated zone - I believe you mean "DNS Resolution".

I am curious about the following:

- are there any errors in event viewer?
- are the listed DNS servers for the PC the local AD domain controllers?
     - if so, what happens if you change the listed DNS server to another- perhaps one outside your network supplied by your ISP?
- what happens if you ping a domain name (, logged in as a user?  
- what happens if you test using NSLookup at the command line:
     - nslookup

I have never heard of anything like this even ONCE - let alone at multiple sites...  Please post back with the results!


Does the computer name clash with another in the domain?

It doesnt sound like a dns issue but more a premissions clash with active directory rejecting the computer being logged onto the domain.
Look in AD under computers and see of there is an x under the computers name in question.

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

menendezaAuthor Commented:
Thank you for the responses. Because the machines are not in my location I'm gonna try to answer to the best of my knowledge.

Event viewers errors: On the local pc or the DNS server? I don't see any on the DNS server which is were I have access.
Yes, the only local DNS server is the same as Active Directory. These sites are hard coded like this:
static ip address
Primary DNS = Our local DNS (Which works like a charm inside the office and in other remote locations)
Seconmdary DNS = The ISP DNS
A third DNS is provided which is the secondary DNS of the ISP. This configuration works fine in other locations.
I haven't asked the technician what happen if he ping other domains or run NSlookup (I was just in shock about giving users local admin rights!!!)

As far as I can see there are no computers with an X in AD but I have a couple of old known machines like that. I will verify that this is not the case.

I definitevily keep you posted although I won't be able to do anything else now until Monday. It does makes me feel better that you guys are interested into knowing the resolution. I sure appreciate it!
 From past experience & MS best practices:  AD domain workstations should *only* have DNS servers that point to your local DCs (domain controllers)  or local DNS servers.  (Configure your local DNS servers with your ISP DNS servers as their forwarders, so external addresses are resolved.)  Otherwise, if you have ISP DNS servers in the client's settings & the local DNS servers don't answer up right away, your users can experience a horrendous wait when trying to logon (ie, up to 15+ min!).  Even if it "works at some sites" don't do it - you'll save yourself & your users a lot of grief when troubleshooting problems that arise.
  Your DCs should have their own DNS settings point to themselves if they're also running DNS or point to a local DNS server for the internal domain.  The DCs should not have ISP DNS servers on their NIC settings, or the Netlogon service won't correctly register with AD.

Agree with calvinetter , if you have your ISP assigned as secondary and third DNS, every other lookup will be sent to your ISP asking the ip for a local computer.  How is your ISP going to know this info??

ISP dns should only be configured as forwarders and therefore only used for rquests your DNS dows not have the answer for.
If you are assigning these in DHCP, you must be experiencing regular freeze ups and poor network performence.
Definitey correct this first.

menendezaAuthor Commented:
That really makes an interesting point. Now, in this case I have over 40 sites and not all have the same ISP. We have about 8 different ISP. Isn't going to create a conflict if I configure the DNS from 8 different ISP's? If a machine needs to resolve for example, how the workstations will know which DNS to look that pertains to its site? Will that matter at all? Does it matter the number of forwarders that I can configure in DNS?

I'm really willing to give that a shot but want to make sure I understand all the in's & out's.

You mention "MS best practices", Can you provide a link or an article number where i can look up for more information. I will sure appreciate that.

That is really irrelevant.  All dns servers will be able tio resolve an address if it is valid from the root servers down.

What you are looking for is to reduce traffic overhead by using the nearest dns servers.  On clients this should be your lan dns only.
For active directory to function, all dns on the network cards should be local, never use a static ISP dns ever.

Configure an ISP dns as a forwarder. This should be the nearest external dns to your connection, usually the ISP who provides your connections dns.

Any ISP dns you have access to will be fine, no conflicts, choose the closest for bandwidth reduction only.;en-us;825036

Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider's (ISP's) DNS servers. If you configure the DNS client settings to point to your ISP's DNS servers, the Netlogon service on the domain controllers does not register the correct records for the Active Directory directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server.

To forward external DNS requests, add the ISP's DNS servers as DNS forwarders in the DNS management console. If you do not configure forwarders, use the default root hints servers. In both cases, if you want the internal DNS server to forward to an Internet DNS server, you also must delete the root "." (also known as "dot") zone in the DNS management console in the Forward Lookup Zones folder.

menendeza, the link above that jessmca provided is the main MS KB article I was referring to (#825036); the last 2 paragraphs above are a quote from that link.  Here's a list of links, info & troubleshooting on DNS, including domain issues & setup:

jessmca is also correct that as far as the DNS system is concerned, it doesn't matter at all what ISP's DNS servers you point to for external resolution.  DNS will work work external sites if you're connected to ISP A but are pointing to ISP B for DNS forwarders.  But, it's just best to point to your own ISP's DNS servers - your response times should be much quicker, & it's easier to find out if the DNS server IPs change.

  How to configure DNS forwarders:   <- 2003 server   <- 2000 server  (virtually identical steps as above)

menendezaAuthor Commented:
Thank you very much for the link!

So, let me see if I understand, if I don't configure the ISP DNS's on my DNS server console (not the card) and a client send a request to my internal DNS server, the server will look at the root hints to resolve the name, right? If I configure my DNS server with a forwarder to that site ISP DNS, when a remote site makes a request the dns server will use the ISP DNS server for the site of my internal DNS and send the request back, right?

I was under the impression (because of a local vendor suggestion) that I need to have each site using the ISP DNS settings. I guess, and please correct me if I'm wrong, a DNS server on the Internet will provide name resolution regardless of the ISP, right?
jessmcaConnect With a Mentor Commented:

All top level domains are owned by a select group of companies, there dns servers will point to all resellers who have also registered their dns with them


starts with the com registrar dns who will request the ip from the resellers dns server and so on til you get to the dns server the domain os located on.

There is a ttl value in the response, default 24 hours which means the ip returned is cached for that period and all foow up requests will return the value in cahe rather than look it up again

Another benefit of using the ISP dns as a forwarder is that many domains will be cached already giving a faster response
menendezaAuthor Commented:
Yes, there is only one domain (corp.local) and all the other sites are connected via VPN's (Cisco PIX's) Some of the bigger sites have their own DC's with DNS on them. These DC's are configured with the main DNS ( as their primary and ISP as secondary (but that's about to change after reading this thread and the articles you suggested.) I use AD Integrated.

The sites clients are configured to look at the main corporate site DNS ( instead to their local. Another vendor suggested that if a DC with DNS is available on a remote site to have the clients to look at their own local/internal DNS to minimize traffic. If this is the correct approach, and the site DNS server is looking at the main internal DNS ( I assume that I don't need to configure the main site as a forwarder since I use AD Integrated, right?

Sure appreciate your help on this jessmca and calvinetter!!!
Bottom line is:
- If branch offices don't have *any* local DNS servers at all on their local LAN (such as at smaller offices), then the clients should point to the main corporate DNS server(s) for all DNS resolution.  And assuming the main corp DNS server(s) has forwarders configured, the remote clients will still be able to surf the Internet as well as resolve internal corp.local hosts.
- If branch offices have local DNS servers, the clients need to point to their own local DNS server as their *only* DNS server.  And configure forwarders on these local DNS servers with the ISP that serves that particular office.

  I strongly suggest having at least 2 AD-integrated DNS servers at the main corporate HQ for redundancy & load-balancing.  If you do have 2 or more DNS servers at HQ, then At the sites that are too small to have their own local DNS servers, point them to the corp HQ DNS servers as primary & secondary.

menendezaAuthor Commented:
Yes, I have two DC at the Corporate office for that purpose. The sites with DC/DNS will need some tweak around based on these recomendations. I will work on that.

When adding the forwarders to the DNS servers, I still need to leave the root hints, right?
yes - but the servers won't need to look at the root hints if there is a forwarder entered.


menendezaAuthor Commented:
Thank you Calvinetter & Jessmca. I went ahead and split the points. I'm pretty sure the answer to the original question is greatly influenced by this whole topic.
Appreciate your help specially over the weekend!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.