Hello Phil,
Phil Mayers <p.may
...@imperial.ac.uk> writes:
> On 10/24/2012 10:17 PM, Carsten Strotmann wrote:
>> my experience is that it is safe to place clients in either a DNS domain
>> with the same name as the AD domain, or in a subdomain of the AD
>> domain.
> What does "place" mean, exactly?
configure the clients DNS-Suffix (local domain name) to be a subdomain
of the AD-Domain. Example:
Base DNS domain delegated: example.com
DC-Server:
AD-Domain: ad.example.com
DNS-Suffix: ad.example.com
Client:
AD-Domain: ad.example.com
DNS-Suffix: client.ad.example.com
> Bear in mind that, unfortunately, Microsoft chose to embed DNS names
> in a lot of places when they retrofitted Kerberos, DNS and LDAP to the
> NT domain protocols.
> You've got:
> 1. The clients own idea of its "main" hostname
> 2. Global DNS search suffixes
> 3. Connection-specific DNS suffixes
> 4. The value of the "dNSHostName" AD attribute
> 5. The suffixes to qualified servicePrincipalNAme AD attribute(s)
> 6. The value of msDS-AllowedDNSSuffixes on the domain OU
> 7. Finally, DNS names which point to the clients addresses
> ...and that's just off the top of my head. Telling me it's "safe to
> put the client in another DNS zone" doesn't really tell me anything
> about the interaction of those things, I'm afraid ;o)
Unfortunatly, to my knowledge there is no single documentation available
on all the different interactions of AD and name services (DNS and
others).
>> Using a subdomain has the benefit of seperating infrastructure
> Yes, obviously it's desirable. The question is, how do you
> appropriately configure all of the above (and anything else besides)
> in a safe, scalable and supported way, that won't cause odd things to
> break, in such a way as to achieve that?
I've used DHCP for that, Group Policy is also an option.
> This is largely a dead issue to me - we just live with the massive
> inconsistency of clients believing they're one thing, and DNS saying
> another - so my knowledge is a bit rusty, but from what I recall, it's
> a huge pain configuring clients into sub-domains of the AD domain,
> because there are so many places you have to get it right. And
> *renaming* is even harder.
Not at all. To my knowledge it is just the one option in DHCP. It is not
renaming the machine (hostname), just the DNS-Suffix (local domain name).
> So we just stopped trying. All clients think they live in
> "example.com", and we use DNS names as we like
> e.g. "dept.example.com", "building.example.com". The problems it
> causes are less hassle than a mass reconfiguration of 20k machines...
>> AD-Domain DNS-Zone. Putting AD-Clients into a DNS-Suffix (aka "local
>> domain") that is a different branch of the DNS namespace than the
>> AD-Domain DNS name creates problems and is not
>> recommended.
> Why? And again, "putting" means what here?
See above.
>> Using connection-specific DNS-Suffixes to my knowledge are used in the
>> case that one machine has network connections into mutliple AD-networks
>> (a gateway machine, or a common server that servers multiple, disjoint
>> AD domains).
> I don't think this is everything. IIRC, connection-specfic DNS
> suffixes are candidates for the client to perform DDNS updates,
> depending on your configuration. And this, of course, is where the
> thread has spent much of it's time.
connection specific DNS suffixes are influencing the DDNS updates, but
they are not required. If connection specific DNS suffixes are not
configured, the global DNS suffix will be used to create the FQDN name
of the client combining the hostname and the global DNS suffix.
> I think the issue is that AD servers and clients make it EXTREMELY
> DIFFICULT to run what you and I would describe as a best-practice DNS,
> due to the above mentioned plethora of things you have to get "just
> right", and the extremely awkward ways of doing so.
Not my experience. I have worked with clients having existing AD
environments, as well as green field deployments. And we were able to
clean up DNS in these environments, and nothing broke (it requires
careful planning and a good knowledge of the DNS traffic towards the DNS
servers to be able to fix misconfigurations before the cleanup).
> Hell, if you've got WINS running and broadcast netbios, I think it's
> still possible to log in with *no* working DNS at all.
I would recommend to shutdown or isolate other nameing services in the
network (except DNS) if all possible. Troubleshooting name lookup issues
in a network with DNS, WINS, LLMNR and NetBIOS is not implossible, but
close to impossible.
> If someone can give pointers to comprehensible docs about how to make
> all this work in *all* the places it needs to, I'd be really
> interested. Because it'd be great to have a subdomain at our site that
> clients just register themselves into, and it all just work.
Unfortunatly I do not know a single comprehensible documentation. All
books on the topic are unfortunatly too old (Windows 2003) or not really
helpful :(
But starting with a
good understanding of DNS, then setting up a AD / DNS test network with
its own root zone, TLD zones and proper delegation and install AD and
clients and inspect the DNS communication (Wireshark or MS NetMon).
Having the recursive DNS server on Unix (BIND with querylog) and run all
Microsoft DNS servers (the AD DC Servers hosting the DNS zones for AD)
in authoritative only mode (turn off recursion) helps to understand
the way how DNS works in an AD environment. I once did
"AD with BIND" trainings, and this lab setup was an eye opener for some
students.
-- Carsten
