Question

Locked

What is the precedence for dns client settings

By keith.abbott ·
Hi,

Quick question if you know, but slow if you're trying to find the answer.

The question pertains to NT4 domain and AD2003 domain with XP and Win2k Clients:

For settings such as dns suffix search order, who has precedence: settings configured on the local machine, or settings specified by DHCP?

And is there "overlay"? ie if the first in precedence has 2 search suffixes, and the second in precedence has those two plus a third, do you wind up with all 3 suffixes, or just the 2 specified by first precedence source?

OK I lied - not a quick question but a few questions:

Should you include the suffix listed in "use this suffix for dns registration" in the search suffix as the first search suffix, or leave it out?

and what about the 2 check boxes below that: wouldn't you always want to register the connection (at least for the primary nic) and use the configured DNS suffix?

What are best practices here?

Thanks for your input
k

This conversation is currently closed to new comments.

19 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Answers

Collapse -

huh ?

by CG IT In reply to What is the precedence fo ...

here's how it works,

on the workstation, in the NIC card TCP/IP properties, there are boxes for DNS server listings. First one is called the primary DNS server and any DNS queries are directed to that server. IF that server can not resolve the query, it forwards it to other DNS servers in it's fowards list or root hint list.

The second DNS server listing is there in case the first DNS server is unavailable. Then DNS queries are sent to that server. If you list a 3rd one, if the first and second DNS servers are unavailable, queries are sent to that one. The however, is, if the first DNS server listed is available for queries, all queries are sent to it and no others.

Registering the connection in DNS simply means that the workstation/computer registers itself in DNS with the address it has.

If you use DHCP to get addresses, then the option for DNS servers needs to be configured in DHCP with the DNS servers to use. If that option isn't configured, then DHCP will not provide it to clients. same with routers option. The router's option provides clients with the default gateway address [router] out of the local network.

Collapse -

right, but..

by keith.abbott In reply to huh ?

right but what I am talking about is in the case where the NIC card is set to DHCP, but there are still settings in the advanced tab, for DNS suffix search order, and 'suffix for this connection'. And there are potentially different settings configured in DHCP for suffix search order and'suffix for this connection'.

In this situation are the DHCP settings in effect, or the NIC card settings?

Collapse -

If the NiC is configured manually, then that

by CG IT In reply to right, but..

configuration takes precedence. If the Nic is configured to obtain info from DHCP, that takes precedence.

suffix is the "added at the end" part. Primary suffix = Active Directory domain name.

So if everything was working well with the NT server listed first to answer DNS queries, and you changed to the W2003 server and everything went bad, then change it back.

The DNS problem sounds like a zone problem.


note: DNS server order of precedence is first always unless that becomes unavailable [server goes down] then queries go to the second DNS server listed [redundancy]. Not load balance.

so if the computer name is xyz and you do a query lookup for xyz in dns the return will be xyz.domain name.com/net/ [or private extension].

Collapse -

For absolute clarity

by keith.abbott In reply to If the NiC is configured ...

ok, to make sure my understanding is what you're communicating:

two clients, (one on an NT domain, one on an AD domain called 'grouchy.com') nic has 'Obtain IP address automatically' checked, but if you click on the advanced button, and DNS tab,
x.x.x.48 is listed as the primary server
x.x.x.30 is listed as the secondary server
'Append these DNS suffixes' is also checked and listed is:
frog.com
fish.com
lizard.com

In 'DNS suffix for this connection' frog.com is listed

register this connections address in dns is checked
Use this connections DNS suffix in DNS registration is checked

Then in DHCP, DHCP specifies DNS servers of
x.x.x.30 as primary
x.x.x.48 as secondary

and a suffix list of:
frog.com
bird.com
snake.com
orange.com

Both clients try to ping a client specified only as warthog (Ping warthog)

According to my understanding of your message that DHCP takes precedence,

For the NT client (call it electron):
it will use server x.x.x.30
it will register with x.x.x.30 as electron.frog.com (listed as 'dns suffix for this connection' and (register this connections address' and 'use this connections dns suffix'
It will first attempt to resolve
warthog.frog.com (listed as 'dns suffix for this connection')
then
warthog.frog.com again because it is the first entry in the suffix list - which suggests it shouldnt be there since its already handled by the clients suffix
warthog.bird.com
warthog.snake.com
warthog.orange.com

for the AD client (call it lepton):
it will use server x.x.x.30
it will register as lepton.grouchy.com - AD always wants to use the domain name

it will try
warthog.grouchy.com - tries its own suffix first
warthog.frog.com
warthog.bird.com
warthog.snake.com
warthog.orange.com


also in this scenario, changing the order of the server list at the client will have no effect because the order specified by DHCP takes precedence.

Is this a correct understanding?

Finally,

For the NT client, if you have 'register this connection' and 'use this connections dns suffix' checked, but 'dns suffix for this connection' is blank, what happens?

Same question for AD - I assume it doesn't care and registers as lepton.grouchy.com

For AD client,if you uncheck 'register this connection', does it not register it? That doesn't seem probable since DNS is so integral to AD. If it still registers, then that checkbox doesnt really matter, correct?

For AD client, what about the next checkbox? Won't it always register as grouchy.com regardless of what you put in that checkbox and the 'dns suffix for this connection' box? If not, you will most certainly break it by putting in the wrong thing.

For the NT client unchecking 'register this connection' truely causes it not to register.

for the NT client what suffix will it register if 'use this connection's DNS suffix' is uncheck?

for the AD client, I know (or at least think I do) any settings in group policy will override all of the local and DHCP settings correct? But in the case where group policy specifies some settings and not others (specifies suffix order but not server addresses for instance) I assume the client uses the suffix order specified by the group policy, but servers specified by DHCP, or NIC settings. Correct?

Thanks for all your help! The basics I know, but the devil is in the details and I have to know the details to really see how things should work.

k

Collapse -

long post here's what happens

by CG IT In reply to For absolute clarity

If you choose to configure the Nic statically, and you can do this with DNS servers or ip addressing or both static entries take precedence.

Registering the computer in DNS does so with the Nic information. Registration in DNS is for the address to computer name records. registering the suffix is the computer name.domain name.extention. If you don't want suffix registration in DNS, then it's simply the computer name to address [basically same as a WINS regisration].

Suffix registration really is for a multi domain environment so that computers can be found based on what domain they are in. Domains are security boundries and computers can have the same name yet be in different domains. DNS wouldn't know the difference in a multi domain environment if only the computer name is used.

note: multi-domain environment means an enterprise environment or a domain environment with trust relationships.

Collapse -

some background

by keith.abbott In reply to long post here's what ha ...

OK, that clears up some of the questions.
The reason I am asking is that at one time we had a large number of statically address machines. Those have long since been changed to DHCP, but the change was made by simply checking the 'get address automatically' box and leaving all of the other settings in place. Therein creating the issue of who has precedence.

When we only had one domain, it wasn't too much of an issue: everything was the same (just provided different ways) and everyone played nice.

Now that we have the AD domain with trusts between the two, with additional dns servers and suffixes, these million-year-old legacy settings become a concern.

And from what I am now understanding, it sounds like any local (NIC) settings will take precedence over DHCP on both NT and AD clients.

(Group Policy trumps all for AD client)

Or the succinct version is:
Order of Precedence for AD client:
1. Group Policy
2. Local Settings
3. DHCP

Order of Precedence for NT client
1. Local Settings
2. DHCP

And, that, since we are running multi-domain, we need to be sure to register suffixes so things resolve to the right domain for the client.


Is all of that correct?
thx again

Collapse -

but I forgot to ask

by keith.abbott In reply to some background

One thing that came out in the long post - that I wanted to ask:

for the NT client,
If the domain suffix for that client is specified in the 'dns suffix for this connection' box, should, or should not, the suffix also be specified (and listed first) in the 'append these DNS suffixes' list?

Does doing so cause it to make the same query twice?
warthog.frog.com because frog.com is listed as the client's suffix,
and again warthog.frog.com because frog.com is listed in the 'append these' list?

what about the AD client?

thx
k

Collapse -

well Group Policy has it's own order

by CG IT In reply to some background

local machine, site, domain and OU in that order.

but that's a whole different ball game and doesn't apply to network cards.


network cards have two ways of being configured. static entries and dynamically assigned entries.

if you use static entries, they are the entries the NIC uses and dont' change unless manually changed.

Dynamic entries change if and when you want them to change via DHCP on a DHCP server.

you can change your whole network addressing scheme including routers, DNS servers, etc via DHCP and not visit workstations.

if workstations have static entries, the only way to change em is to visit them and change them manually.

order of precedence is simply static never changes even if there is DHCP services running and what DHCP has is different than what is statically assigned to the network card. Static is just that, never changes.

Nic cards do not choose which one to use. The default TCP/IP properties is obtain automatically. If they can't get one then they assign themselves an address in the IP range 169.X.X.X

If configured statically, they use that. If the address is configured dynamically but DNS servers statically, DNS will never change but addresses will. If DNS is dynamic and IP is static, DNS servers can change.

depends on how you want clients to get their addresses, default gateways, DNS server information.

If you have 2 domains with a trust between them, both on 2 different physical networks, [best way to go really] they each use their respective network addressing and DNS servers. If you have two non-contigious named domains on the same network segment, then that's really more tricky. DNS servers have to lookup names in zones and if they don't have zones for a name, they will shoot the query out to root hint or specified forwarders.

Collapse -

group policy - not so sure

by keith.abbott In reply to some background

well I'm not sure about the group policy point. Case in point:

one group of our users need to be able to resolve names from a different site. Their legacy software was not really written to run from multiple sites and only specifies the server name rather than the FQDN. To resolve the issue we included the remote domain in the suffix search order. But when we moved them to the AD domain, that stopped working and even though you would put the suffix in the search list, when you did an IPconfig /all, the suffix was never listed with the normal suffixes.

Come to find out, there was a network group policy in place that specified only the normal suffixes and it had precedence over the local settings.

As far as the domain trusts, we're in the second case you listed. Two domains on a single subnet (one AD one NT). Except both domains use the same DHCP and DNS servers.

The PDCE on the AD domain - which of course is also Primary DNS for all clients on the domain, has a secondary zone for the NT domain.

On another AD DC, a secondary DNS server is configured and has the NT domain configured as a Primary zone and the AD domain as 'AD integrated'

k

Collapse -

muti-domain environment NT and Active Directory

by CG IT In reply to long post here's what ha ...

big admin headache but hey that's why you get the big bucks huh.

if you have a NT domain, then you probably have DNS and DNS Zones running for it..[ for those security domains in NT]. If you have pre W2K workstations, god forbid, then you probably run WINS as well.

The tricky part comes with what DNS server handles what zone for what domain.

If you had seperate DNS servers for NT and Active Directory, life is good. NT people use theirs. AD people use their.

if you 2 logical domain networks on the same physical subnet, things get a bit dicey. Especially if you use 1 DHCP server and 1 subnet addressing scheme. This sounds like what's going on. DHCP gives out DNS servers and those on the NT network can't find the NT domain PDCs to authenticate with but they can find the AD domain controller.

Note: Group Policy can be used to configure network settings but what's the point if you have DHCP?

If I were you and in this situation where I have two logical domains on a single physical network, as a last resort, I'd do superscopes in DHCP. Assign 1 range to 1 logical domain and another range to the other logical domain. But for ease of administrative work and less headaches, for the NT domain, give em static addressing.

bottom line is the NT clients need their PDC to authenticate with and that PDC should be listed in their DNS server that hosts the NT domain [security domains] DNS zone. That DNS server will then tell clients that the NT PDC is such and such server. That DNS server is then listed in the NIC card properties or provided to the workstations by DHCP. it should be the first DNS server listed.

For complexity sake, and to make the admins life really fun, if NT domain clients use a different DNS server than the one for their domain, and it's not an authoritative DNS server for the domain and does not hold the DNS zone for the domains and that DNS server is available on the network, that server will forward unresolved queries to either root hint or forwarders. you can configure that DNS server to forward unresolved queries to a server you specify. So for instance your AD DNS server can't resolve queries for the NT domain, you can have it forward to the NT DNS server.

If you only have 1 DNS server, then you can configure different zones for the different domains and that 1 DNS server can resolve queries for the different domains.....

Depends on how much complexity you want.

Back to Software Forum
19 total posts (Page 1 of 2)   01 | 02   Next

Software Forums