Choosing a DNS namespace for AD

Discussion in 'Active Directory' started by AI, Jan 25, 2005.

  1. AI

    AI Guest

    I will be implementing an Active Directory migration at my company, and the
    first decision is how to design the DNS namespace. I have looked around on
    the net for advice about how to proceed, and although the topic is a common
    one, the discussions always seem to be very generic and superficial, often
    not saying much more than "X is recommended. Y is not recommended."
    Sometimes advice in different places is contradictory. I hope I can get some
    more specific advice here.

    We have a single domain with NT 4.0 domain controllers. We have two
    external DNS servers, authoritative for the domain mycompany.com, and two
    internal DNS servers authoritative for the domain corp.mycompany.com. All
    DNS servers are running on Windows 2000. I am planning on implementing an AD
    domain alongside the NT 4.0 domain, not on upgrading the NT 4.0 domain in
    place.

    The question is, what would be the best name for the AD domain?

    The first option is to use the same namespace internally and externally. I
    know that would be a hassle because it would be necessary to maintain
    duplicate entries for servers that need to be accessible from both inside and
    outside, but I've also seen it mentioned that it's somehow less secure,
    because it creates the risk that the names of internal hosts will be exposed.
    How so? If only the internal DNS servers, inside the firewall, have records
    for internal hosts, how would those records ever be exposed?

    The remaining options are to use mycompany.local, or to use a subdomain of
    the external namespace, either the corp.mycompany.com domain that we're
    currently using, or a new one. I've seen articles/discussions saying that
    ..local is recommended, and is preferable to a subdomain of the external
    domain, and I've seen others that say that a subdomain is preferable, and
    using .local or a fake TLD is not a good idea. However, I haven't seen much
    discussion of why (Microsoft's deployment guide is a good example, saying
    that mycompany.local is not recommended, and providing no explanation
    whatsoever).

    So, what are the advantages and disadvantages of each?

    I saw one article saying that .local should not be used because CAs won't
    issue certificates unless you're using an Internet TLD, but I don't
    understand what the problem is, if the namespace is only intended for
    internal use. If any internal servers need to be accessible from the
    Internet, the client would use an external name which the firewall would
    forward to the internal server, so the internal server's certificate could
    bear the external name. Is there a problem here that I'm overlooking?

    If I end up using a subdomain, is there any problem with using a NetBIOS
    name that is not the same as the lowest level domain? For example, if I use
    corp.mycompany.com as the AD domain name, but I want users to select the
    company name when they log in, can I set the NetBIOS name to MYCOMPANY rather
    than CORP, or will that cause headaches?
     
    AI, Jan 25, 2005
    #1
    1. Advertisements

  2. AI

    Allen Firouz Guest

    AI,

    The battle rages on. I am gonna get the ball rolling and I hope that the
    MVP's will put in their 2 cents.

    The question of namespace is one that is personal and relates to how your
    company will grow. Before I tell you my preference, the reason it was
    originally recommended that a .local namespace be designated for internal
    purposes was to essentially "mask" the internal systems from the internet
    (and it works as stated). However, with newer technology introduced in the
    past few years (PKI, CA, RPC over HTTP, etc), it is a good idea to consider
    using the same namespace for internal and external domains. Keeping the same
    internal and external namespace makes scalability of a network simpler. To
    still keep the domain safe, I recommend using an empty root as an extra layer
    of security between external and internal domains.

    My experience has been to retain the same namespace incorporated with an
    empty root. It makes transition to newer technology and any future plans
    easier to manage and you can add and remove child domains as necessary (with
    proper planning, of course). Some examples of technologies that are easier
    with the same namespace are Exchange's RPC over HTTP, PortalServer,
    ProjectCentral and even web based data mining programs. That's my
    recommendation, but as you stated in your post, there are arguments for each
    side. Good luck. This should be a fun post to follow.

    -Allen Firouz
     
    Allen Firouz, Jan 25, 2005
    #2
    1. Advertisements

  3. First of all, an empty root domain does not offer any additional security
    over a single forest/single domain model. In a large environment that will
    have multiple child domains I think it is a good design and it can still be
    considered a decent idea to use an empty root domain to separate the Schema
    Master and Domain naming master FSMO roles, but that still does not offer any
    security enhancement.

    To echo Allen's statements, the reason you see conflicting information is
    that there is no one way to architect Active Directory DNS. You can do it any
    of the ways that you have outlined (and others) and have AD work fine. I can
    say that Using the same name internally and externally is generally not
    recommended because of the additional administrative overhead involved in
    maintaining a dual level DNS. As the environment grows this gets more and
    more difficult to manage. I can also mention that when people say using the
    same name internally and externally could expose internal IPs to the internet
    is referencing someone setting up their DNS so that they use the same DNS
    structure internally and externally; not a dual level dns like you describe
    but actually using the same DNS namespace which would put all the internal
    hosts in the DNS database of the externally facing DNS server (did that make
    sense?).

    I generally recommend that a company use another name that they do not use
    externally, but use an actual TLD and make sure that they register that name.
    So if you use mycompany.com externally then perhaps you would register
    mycompany.net and use that for AD, or perhaps mycomp.com etc. This will still
    let Exchange function properly and you will still be able to use your
    external DNS name for email. I have yet to run into an application that will
    have issues with this type of setup, but using a non-standard TLD (like
    ..local or .ad) can cause some problems for applications that are expecting to
    see one of the official TLDs.

    The reason that you see people mention certificates as an issue is in
    reference to PKI and internal CAs, not for external 3rd party certificates
    from someone like Verisign.

    Did I miss any of your questions?

    Phil
     
    Phillip Renouf, Jan 25, 2005
    #3
  4. AI

    AI Guest

    Yes, this makes sense. Other than the extra maintenance of adding some
    entries to two sets of DNS servers which are both authoritative for the same
    domain, are there any advantages/disadvantages?
    Would Exchange 2003 (which is also in the offing) have a problem with an
    unofficial TLD, and if so, what? Regarding the e-mail addresses, the way I
    see it, internally, users would use the GAL to find mail recipients, and
    externally, people would use the external domain name as they do now. It
    should not pose a problem if the internal namespace is different, as long as
    the MX record for the external domain name points to the Exchange server (or,
    as we have it set up, a mail gateway which forwards to the Exchange server).
    Is there something more to it that I should be aware of?
    What applications do you know of that would have a problem with that?
    I'm not sure I'm following - are you saying that internal CAs wouldn't issue
    certificates for a domain with an unofficial TLD?? AFAIK, internal CAs can
    issue certificates for any domain name. The only way a problem could arise,
    as I see it, is if commercial CAs as a matter of policy only issue
    certificates for registered domains, but my question is, would there ever be
    a case where I would need a commercial CA to issue a certificate bearing my
    internal domain name?
    How about the possibility of using a subdomain of the external namespace?
    Any advantages/disadvantages? Also:
     
    AI, Jan 26, 2005
    #4
  5. AI

    AI Guest

    I think an empty root would be overkill, my environment really only needs
    one domain, and adding child domains is exceedingly unlikely to become an
    issue. How exactly does using the same internal and external namespace help
    network scalability?
    What problems would different internal and external namespaces pose to using
    RPC over HTTP?
     
    AI, Jan 26, 2005
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.