RE: [ActiveDir] DNS resolution - prioritization

Thu, 08 Sep 2005 06:16:16 -0700

has some info on this subject. An excerpt can be found below.
 
neil
 
---------------------------------------
Neil Ruston
Nomura International Plc
Tel: 020 7521 3481
[EMAIL PROTECTED]
 
 

How DFS Is Used During the Logon Process

When a client logs on to a domain, the client contacts a domain controller and requests a special type of referral, known as a SYSVOL or NETLOGON referral, to gain access to the scripts and policies stored in the SYSVOL and NETLOGON shared folders on domain controllers. (Specifically, the client requests SYSVOL and NETLOGON referrals from the active domain controller, which is preceded by a + under the appropriate domain in the client’s domain cache.) These referrals map the paths \\DomainName\Sysvol and \\DomainName\Netlogon to a list of SYSVOL and NETLOGON shared folders for all domain controllers. Clients store these referrals in their referral cache. To see examples of these referrals, see the figure “Sample Referral Cache Output” earlier in this section.

DFS objects do not exist in Active Directory for these shared folders; instead, the domain controller simply recognizes that it is responsible for these paths and responds to queries of the form \\DomainName\Sysvol and \\DomainName\Netlogon. These referrals are distinct in that although the targets are hosted on a domain controller, the targets are not roots themselves and do not appear in any of the DFS tools, nor can the SYSVOL and NETLOGON shared folders host links.

Domain controllers generate SYSVOL and NETLOGON referrals each time a client requests a referral. By default, the list of domain controllers listed in a SYSVOL or NETLOGON referral are sorted as follows:

1.

All domain controllers in the client’s site are grouped in random order at the top of the list.

2.

Domain controllers outside of the client’s site are listed in random order.

It is possible to configure DFS to sort the domain controllers outside of the client’s site in order of lowest cost. You can enable this feature by adding the SiteCostedReferrals registry entry on each domain controller and then restarting the DFS service on each domain controller. The DFS service then obtains site cost information for all domain controllers and stores this information in its site cost cache.

 


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]
Sent: 08 September 2005 13:53
To: [email protected]
Subject: RE: [ActiveDir] DNS resolution - prioritization

Yeah, \\example.com is not managed by Dfs.  You’re right on that Alex… I assume it follows netmask ordering w/ RR to present the closest records from being displayed.  If you’re interested in netmask ordering, here’s a good article on it:

 

http://support.microsoft.com/?kbid=842197

:m:dsm:cci:mvp

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Fontana
Sent: Tuesday, September 06, 2005 12:47 PM
To: [email protected]
Subject: RE: [ActiveDir] DNS resolution - prioritization

 

DFS is site aware, but what about non-dfs?  \\example.com will always resolve to “some” domain controller, dfs or no dfs, using round-robin dns, right? 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, September 06, 2005 8:59 AM
To: [email protected]
Subject: RE: [ActiveDir] DNS resolution - prioritization

 

Dfs is site aware.  Since \\example.com\netlogon is managed by Dfs, the client will receive the location closest to it based on site.  What you were referring to on returning DNS records is called “netmask ordering”.  You’re right about the limitations of it.

 

:m:dsm:cci:mvp

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh Parmar
Sent: Tuesday, September 06, 2005 11:18 AM
To: [email protected]
Subject: Re: [ActiveDir] DNS resolution - prioritization

 

I agree client logon won't be a issue, as clients & DC fit in the site boundary.

 

But some of my startup script access netlogon as \\example.com\netlogon, and I suppose accessing any network resource by UNC has nothing to do with site boundary, it is pure DNS resolution.

 

also what about domain DFS traffic ? will it consider site boundaries while, finding the nearest replica partner? or it will use plain DNS resolution?
 

-

Kamlesh
 

On 9/6/05, Phil Renouf <[EMAIL PROTECTED]> wrote:

Just wondering what the actual issue is here though, when a client logs in they will get a DC within their local site, that shouldn't be dependant on the clients subnet mask, just whether their IP falls within the scope of a site defined in AD. If there is a DC in that site then they should be reffered to that DC during logon processes.

 

The behaviour of ping is not going to be site aware, but logon traffic will be.

 

Phil

 

On 9/6/05, Kamlesh Parmar <[EMAIL PROTECTED] > wrote:

Thanks Roger for the reply,

Problem is not the site setting, you see... when I ping for my domain's DNS name... or access the netlogon folder on DC as  \\example.com\netlogon

This DNS resolution, will NOT consider site boundaries and give me appropriate IP of local DC.
this DNS resolution will ask for client's subnet mask and if it finds any matching IP of DC which falls into this client network, it will provide that DC IP as first one. (making sure traffic remains inside LAN)

but, since client IP network is restrictive /21,  the server which is there in the same physical LAN but in different subnet, will not be returned as first choice.

I hope it clears it a bit.

 

On 9/6/05, Roger Seielstad <[EMAIL PROTECTED] > wrote:

I'd create smaller subnet records in AD (probably matching the /25 VLANs) and assign those to the sites which house the domain controller which you want them to use. You can keep the /21 subnet entry as a catch all as well, just in case.

 

--------
Roger Seielstad
E-mail Geek

 

 

From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Kamlesh Parmar
Sent: Monday, September 05, 2005 3:30 AM
To: [email protected]
Subject: [ActiveDir] DNS resolution - prioritization

 

Dear All,

 

We have around 50 sites with 80 DCs, all in single domain.

 

Now issue is three sites, have very restrictive network configuration for subnets. (all having 500+ machines)

 

i.e. their subnet specification in AD is  10.*/21

but at the network level they have divided this subnet into VLANs with mask of /25, all inclusive in mask /21 defined for subnet at AD level.

 

Problem:  when machine tries to find the nearest DC using domain DNS name, DNS server doesn't give IP of nearest DC first.

as server falls into only into one of the /25 subnets. ( "subnet mask request" in DNS server is enabled)

And as a result, machines go to other DCs for netlogon related activities/scripts. (generating unnecessary WAN traffic, slow login)

 

I am working with Network team to initiate the feasibility of so many VLANs, (long process)

and if its possible to merge some VLAN, then I will move the DC in that subnet.

 

Any solution other than hard coding nearest DC in host file of all these machines.

 

Regards,

Kamlesh
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~
 




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~

 




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~

PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.

Reply via email to