| Author | Messages | |
DavidCliffe
Posts:10
 | | 03/24/2008 3:35 PM |
| Thanks for the clarification on 'disjoint' and 'non-contiguous'. I
suppose I had been incorrectly using them in my head to mean the exact
same thing. Still useful to know which apps may be more difficult to
support under one, the other, or either. In fact I was mostly
interested in reading any replies to Dan's question, but this thread
recently turned a bit towards discussing merits of Microsoft and other
implementations of DNS. (nothing against that btw!)
The few environments I've seen (not nearly 100,000 in any of them) have
used both flat and hierarchical child of AD domain, but I hven't seen
much non-contiguous yet, so that part interested me a bit. I like
seeing hierarchical especially if hostnames do not indicate geographic
location.
-DaveC
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ken St. Cyr
Sent: Monday, March 24, 2008 9:59 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Non-Windows DHCP in AD environment [MORPHED
INTO DISJOINTED DNS NAMESPACE]
We recently had a pretty lengthy discussion on this topic in AD Ranger
school (Laura - you were out that day). So first, disjoint means that
the clients are registering to a different DNS zone than the zone that
represents the domain that their joined to. Non-contiguous means that
your domain namespace is outside of the naming hierarchy of the forest.
The best way to handle disjoint registrations is to use the setting on
the network adapter configuration that says to register a specific DNS
name for that connection. The advantage here is that you can allow the
client to dual-register and still keep a record in the zone that
represents the domain as well as the alternate zone. We typically prefer
this approach over the registry mod.
So let's talk about the flat namespace discussion. I'm a big fan of the
flat namespace. The biggest problem I see with the flat namespace is the
DNS MMC tool itself and not the actual DNS design. It's well known that
the flatter the structure, the faster queries execute (since
AD-integrated DNS is a directory in the back-end). So here's my beef
with multiple zones per AD domain - it all comes down to zone transfer
scope. In the days when a primary/second DNS model was the only option,
it was preferable to break up zones by say, geographic region, because
you wanted a primary DNS server at the same site as the client. Even
now, when you talk to vendors of DNS appliances, this is their approach
because they don't typically do true multi-master DNS. The vendors that
I know of use a variation of the "cache and forward" methodology to give
a sense of multi-master; but still there is only one primary for a zone
that distributes updates to all other servers. With multiple primaries
(multiple zones) you overcome that. But with a true multi-master DNS
(AD-integrated), in most environments, there is no need to have multiple
zone transfer scopes. Granted, there are exceptions.
The one thing I will definitely agree with is that when you have 100,000
records, the DNS MMC takes *forever* to load/refresh. But IMO that's the
tool's problem and a flat design shouldn't be ruled out because of it. I
just think we need a better tool.
Counterpoints?
//Ken
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dan Holme
Sent: Friday, March 21, 2008 1:55 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Non-Windows DHCP in AD environment [MORPHED
INTO DISJOINTED DNS NAMESPACE]
Laura/Joe (and others)
I'm really curious about what you're saying b/c I have a very large
client (80k seats) that is disjointed currently and is looking at
FLATTENING to a single zone, primarily because of support issues in
applications that aren't expecting or happy with clients being in DNS
domains that are not equivalent to the AD domain. They've lived for
years with a disjointed namespace, but it's required major tweakage to
SPNs as well as the registry changes and AD ACL changes to do that. So
I agree that disjointed namespaces can be achieved.
But my understanding (from them) is that it's becoming increasingly
burdensome to maintain that environment. I'm not an SCCM person but
I've been told by the client's team that there's something about SCCM
that will not be happy in a disjointed namespace.
On a related front, they're needing to go to dynamic DNS (not currently
implemented) for obvious support-related issues (hard to support a
client if you can't find it).
What has been your experience with disjointed namespace and
application/service functionality outside of the 'core' MS Windows OS??
Second, why do you feel that a 100k+ record DNS zone is such a problem,
if you have multi-master replication, dynamic DNS, and secure updates
working? I've seen enough zones far bigger than that and (perhaps
because I'm not neck-deep in their DNS implementation) have not seen
problems arising from it... It seems to be simple and to 'just work' in
those environments...
I appreciate your feedback--I'm definitely not a DNS superhero, so I
know I have something to learn in this discussion!
Dan
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Laura A.
Robinson
Sent: Friday, March 21, 2008 5:37 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Non-Windows DHCP in AD environment
By general default, most people build one DNS zone per domain, I'd
wager, but that doesn't mean it's a requirement of DNS that it be that
way.
There
is an art to DNS design, IMO, and Joe is accurate (of course) in his
beef with MSFT DNS that it doesn't easily expose (or in some aspects,
support)
some of the more artful approaches to DNS design.
One of the things about Microsoft's DNS implementation is that it was
introduced as the de facto name resolution mechanism for AD without
there being a large pool of administrators/architects who were skilled
in DNS at the time of its release. Most of the people who built MS-DNS
in the early days of AD were people who had previously worked with WINS
as their primary name resolution mechanism, and DNS had been left to
"the UNIX guys".
This
lack of industry experience with DNS in the pool of Windows
administrators meant that over the years of the evolution of AD and
MS-DNS, the DNS implementation became wizarded to the nth degree.
Microsoft receives a HUGE number of support calls because of
misconfigured DNS, so their design decisions have often been around
making it easier to implement a functional default than around offering
guidance or exposure to more complicated hierarchical designs.
However, to answer your base question, no, it is not a requirement that
a single AD domain be represented by a single DNS zone. You could have
an AD domain called "northamerica.company.com" with that domain being
represented by, for example, separate DNS zones such as:
Newyork.northeast.northamerica.company.com
Chicago.midwest.northamerica.company.com
Dallas.southwest.northamerica.company.com
Seattle.northwest.northamerica.company.com
Research.development.internal
Big.muckety.mucks
Problem.children.corp
Northamerica.company.com
There is no requirement that a machine's DNS suffix match the name of
the AD domain of which it is a member, btw. However, the simple reality
is, implementing something other than the default requires a solid
knowledge of DNS that too many people lack, which brings us back to
design/guidance decisions made that produce a functional default rather
than exposing/encouraging design options that, in all likelihood, many
people would muck up.
I used to have a mantra that I would pound into people's heads- there is
no [required] one-to-one mapping of AD domains to DNS zones. However, as
soon as I'd begin my discussion of what I meant by that, people's eyes
would usually glaze over and there'd be a general response of, "that's
too hard; we'll just stick with the default config", and I began to see
why Microsoft had wizarded DNS to death and created a default
configuration that I have never used. I never, ever build AD without
building DNS first, and I never use the default configuration that the
AD build process constructs if you let it. However, I'm either a
dinosaur or just stubborn, because there are a lot of people out there
who will happily let dcpromo build their DNS and live with having
100,000 machines in the same DNS zone.
Simply put, it requires more work and knowledge to build DNS without a
one-to-one mapping of AD domain to DNS zone, so most people don't do it.
The
companies where I *do* see implementations that don't follow that
default configuration are almost always shops where the UNIX guys built
DNS.
Just my pennies,
Laura
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of RMS
Sent: Friday, March 21, 2008 10:49 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Non-Windows DHCP in AD environment
Thanks for all the replies folks! I guess it depends on what we're
trying to accomplish, but it seems that consensus is that it can be done
and there is no problem with using a non-win DHCP system.
With that said, joe's email brings up another interesting question I
have. My apologies as I totally go OT..
The part where joe describes one domain
"NorthAmerica.Domain.Com" and one DNS zone. Please forgive my total
newbness when I ask, isn't it generally one DNS zone per domain, at
least by general default? Say you do have a domain that is 100K+
devices, aren't you limited to one DNS zone inherently? Or am I
completely missing the point and there are other options?
Thanks again all!
--- joe <listmail@joeware.net> wrote:
> I worked in a very large environment and we used QIP, I had no issues
> with it once we were configured. Then we didn't run it either, we had
> DNS/DHCP experts (true experts, not people who knew how to click on
> the DNS DHCP Management MMC Icons) but this is important in all areas
> of IT management and often screwed up. We also didn't run QIP on
> Windows, it was on a unix flavor which may have had a lot to do with
> its stability, etc.
>
> I think one of the things we all really liked about it was a the
> ability to truly delegate the security to update various portions of
> it and handle it through a nice interface. Something that to my
> knowledge is absolutely and completely lacking in the MSFT toolbox.
> Also people in the MSFT world still seem to think that a single DNS
> zone of say NorthAmerica.Domain.Com is a good thing and do it because
> that is the actual AD domain name for that region even if it is
> 100,000+ people and even more machines... People like to bitch about
> WINS and then go and design flat DNS "hierarchies"... Happy Friday. 
>
> My biggest complaint I recall was not having scavenging on but I spent
> an afternoon and wrote a perl script that did the scavenging and never
> checked again to see if they turned QIP's scavenging on.
>
> joe
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
> _____
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Laura A.
> Robinson
> Sent: Thursday, March 20, 2008 3:51 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Non-Windows DHCP in AD environment
>
>
>
> Nah, just technotard-software averse. ;-)
>
>
>
> Laura
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
> Sent: Thursday, March 20, 2008 3:21 PM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] Non-Windows DHCP in AD environment
>
>
>
> Wimp.
>
> On Wed, Mar 19, 2008 at 8:43 PM, Laura A. Robinson
> <laurarobinson@verizon.net> wrote:
>
> QIP. <hiss.rattle.hiss>
>
>
>
> Laura
>
>
>
> From: ActiveDir-owner@mail.activedir.org
> [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al Mulnick
>
>
>
> I ran into that with QIP several years back. The
> client had QIP and wanted
> to use it (it costs money, so you may as well use it
> right?) but it had a
> few "flaws" and also would only run on a lower rev
> of Windows. Upgrading
> was a hassle because it required a different vendor
> to be involved vs.
> getting it from Microsoft who had already tested
> their own stuff against the
> upgrade (and needed it).
>
>
>
>
>
>
>
> No virus found in this outgoing message.
> Checked by AVG.
>
> Version: 7.5.519 / Virus Database: 269.21.7/1333 -
> Release Date: 3/18/2008
> 8:10 AM
>
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.21.7/1333 -
> Release Date: 3/18/2008
> 8:10 AM
>
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.21.7/1333 -
> Release Date: 3/18/2008
> 8:10 AM
>
>
>
________________________________________________________________________
____
________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.8/1337 - Release Date:
3/20/2008
8:10 PM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.8/1337 - Release Date:
3/20/2008
8:10 PM
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
This email was sent to you by Reuters, the global news and information company.
To find out more about Reuters visit www.about.reuters.com
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of Reuters Limited.
Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
| | | |
|
|