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?
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)
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?
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.
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?
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.
AD network. There should be only one DNS namespace.
Yes. We have independent research groups who run their own private AD
who painted themselves into this corner. It's extremely difficult to get
out of.
A general observation:
If find a high number of DNS admins in AD networks that have the
preception that the earth, pardon DNS, is flat. It is not, it is a
hierarchy :). And every attempt too make it appear flat creates problems.
I don't think this accurately describes the issue, though I think I know
what you mean.
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.
In addition, having adopted Kerberos and DNS in Windows 2000, Microsoft
then went and ignored it in lots of places, so having broken DNS isn't
the showstopper it would be. Example: Windows does *not* use the DNS
name of a CIFS server to obtain a kerberos ticket. It uses the name the
CIFS server claims in the SMB connection setup. Which is horribly insecure.
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.
So the pressure on AD admins to "get it right" just isn't there, and
thus the knowledge base isn't either :o(
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.
Cheers,
Phil
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
