How Secure is ".Local?"

Archived from groups: microsoft.public.win2000.dns (More info?)

Hi all,

I would like to run AD on my public DNS servers, 'hiding'
my private AD domain with a non-routable extension, like
the suggested '.local' (e.g., 'mycompany.local').

QUESTION: If the '.local' extension is common knowledge or
becomes a standard, it follows that 'mycompany.local' is
easily guessable. What will prevent eavesdroppers from
querying my public DNS servers for the private
'mycompany.local' AD names/addresses? Should I instead
employ something unobvious, like 'mycompany.abcxyz'?

Any advice is greatly appreciated.
18 answers Last reply
More about secure local
  1. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Dave" <anonymous@discussions.microsoft.com> wrote in message
    news:044e01c5171e$bcd4af40$a501280a@phx.gbl...
    : Hi all,
    :
    : I would like to run AD on my public DNS servers, 'hiding'
    : my private AD domain with a non-routable extension, like
    : the suggested '.local' (e.g., 'mycompany.local').
    :
    : QUESTION: If the '.local' extension is common knowledge or
    : becomes a standard, it follows that 'mycompany.local' is
    : easily guessable. What will prevent eavesdroppers from
    : querying my public DNS servers for the private
    : 'mycompany.local' AD names/addresses? Should I instead
    : employ something unobvious, like 'mycompany.abcxyz'?
    :
    : Any advice is greatly appreciated.

    http://www.windowsecurity.com/articles/Securing_Windows_2000_DNS_by_design_Part_1.html


    --
    Roland Hall
    /* This information is distributed in the hope that it will be useful, but
    without any warranty; without even the implied warranty of merchantability
    or fitness for a particular purpose. */
    Online Support for IT Professionals -
    http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
    How-to: Windows 2000 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
    FAQ W2K/2K3 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
  2. Archived from groups: microsoft.public.win2000.dns (More info?)

    Thank you, Roland, but this article only answers the
    question by saying, "don't do it." Other authors, such as
    the well-respected Mark Minasi, suggest that running AD on
    a public DNS server is a viable solution.

    FYI, I am running split-brain DNS already, as recommended
    by the article you present. But our network is so small
    that we no longer want to dedicate separate servers to DNS,
    AD, backup DNS and backup AD. It's just too much hardware
    for our modest needs. If we MUST have public DNS servers,
    then it seems logical to also put our AD there, if at all
    possible.

    Thank you for your response. I do appreciate it.
    >-----Original Message-----
    >"Dave" <anonymous@discussions.microsoft.com> wrote in message
    >news:044e01c5171e$bcd4af40$a501280a@phx.gbl...
    >: Hi all,
    >:
    >: I would like to run AD on my public DNS servers, 'hiding'
    >: my private AD domain with a non-routable extension, like
    >: the suggested '.local' (e.g., 'mycompany.local').
    >:
    >: QUESTION: If the '.local' extension is common knowledge or
    >: becomes a standard, it follows that 'mycompany.local' is
    >: easily guessable. What will prevent eavesdroppers from
    >: querying my public DNS servers for the private
    >: 'mycompany.local' AD names/addresses? Should I instead
    >: employ something unobvious, like 'mycompany.abcxyz'?
    >:
    >: Any advice is greatly appreciated.
    >
    >http://www.windowsecurity.com/articles/Securing_Windows_2000_DNS_by_design_Part_1.html
    >
    >
    >--
    >Roland Hall
    >/* This information is distributed in the hope that it
    will be useful, but
    >without any warranty; without even the implied warranty of
    merchantability
    >or fitness for a particular purpose. */
    >Online Support for IT Professionals -
    >http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
    >How-to: Windows 2000 DNS:
    >http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
    >FAQ W2K/2K3 DNS:
    >http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382

    >
    >
    >.
    >
  3. Archived from groups: microsoft.public.win2000.dns (More info?)

    In message <05b301c5176f$0021a1e0$a501280a@phx.gbl> "Dave"
    <anonymous@discussions.microsoft.com> wrote:

    >Thank you, Roland, but this article only answers the
    >question by saying, "don't do it." Other authors, such as
    >the well-respected Mark Minasi, suggest that running AD on
    >a public DNS server is a viable solution.
    >
    >FYI, I am running split-brain DNS already, as recommended
    >by the article you present. But our network is so small
    >that we no longer want to dedicate separate servers to DNS,
    >AD, backup DNS and backup AD. It's just too much hardware
    >for our modest needs. If we MUST have public DNS servers,
    >then it seems logical to also put our AD there, if at all
    >possible.

    Personally, I don't see the harm in having this information publicly
    available -- In most cases an attacker will already be able to perform
    DNS lookups within your network by the time they get far enough in to do
    any damage.

    All that being said, my DNS is in private name space. I use a
    internal.example.com nomenclature where everything under internal is
    only resolvable internally, externally most of it points to NXDOMAIN,
    although a few hosts have valid external IPs (the VPN server being a big
    one -- Some people VPN internally too, so it makes everybody's life
    easier)


    --
    I walked into a bar the other day and ordered a double.
    The bartender brought out a guy who looked just like me.
  4. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Dave" <anonymous@discussions.microsoft.com> wrote in message
    news:044e01c5171e$bcd4af40$a501280a@phx.gbl...
    > Hi all,

    To start: .local is not secure at all.

    It is not going to provide your zone info to anyone
    on the Internet since local is NOT a zone in the
    Internet namespace.

    Don't think of this as "security" -- it's not, except
    in the sense that you are definitely not publishing
    your INTERNAL resource names on the Internet,
    but then you should not do that no matter what name
    you pick.

    > I would like to run AD on my public DNS servers, 'hiding'
    > my private AD domain with a non-routable extension,

    Extentions have NOTHING to do with "routable" --
    local doesn't appear in the Internet namespace so is
    not resolvable from the Internet root (there is no local
    top level domain on the Internet.)

    > like the suggested '.local' (e.g., 'mycompany.local').

    It is impractical (and a very poor) design for your to run
    your internal (AD support) DNS on a public server.

    > QUESTION: If the '.local' extension is common knowledge or
    > becomes a standard, it follows that 'mycompany.local' is
    > easily guessable.

    You are misunderstanding the purpose of the local and
    the actual effect.

    It is merely to avoid registering on the Internet and publishing
    the name there, as well as guarantee that you will not class
    with anyone else (since they cannot register it either.)

    > What will prevent eavesdroppers from
    > querying my public DNS servers for the private
    > 'mycompany.local' AD names/addresses?

    Not a all. The way you prevent this is by NOT allowing
    your internal DNS server to offer resolution on the
    Internet. It doesn't matter what name you use, don't offer
    the internal zone on the Internet.

    > Should I instead
    > employ something unobvious, like 'mycompany.abcxyz'?

    No, you just should try to approach the problem as above.

    Most people shouldn't even be running ANY public DNS
    server themselves but should leave their public DNS as
    the registray.

    > Any advice is greatly appreciated.

    DNS for AD SHOULD be inside the firewalls -- obviously
    there may be exceptions for those people deploying and
    AD publicly but this is VERY uncommon and represents a
    serious security task (keeping the whole thing safe.)

    DNS for AD should GENERALLY be on the DCs for most
    small business situations. (More exceptions to this but it
    is a good practice.)

    From another message you mention the need to avoid
    addition hardware: This is among the reasons you do
    NOT want to run your external DNS as all -- move it
    (back) to the registrar in most cases.

    You cannot practically run the internal and external
    versions of a Shadow (or Split) DNS on the same
    server in any case.

    Once you choose a DNS name for your AD you cannot
    change it anyway (in Win2000 and difficult in Win2003)
    so you must BRING that zone which supports AD inside
    (whether it is the same as you use outside or not).

    In Shadow DNS, there really are two zones -- one version
    on the Internet, and another SEPARATE version of the zone
    on the internal Net. Once you realize that their are really
    TWO zones with the same name it makes easier to think
    about.

    General checks on DNS for AD
    1) Dynamic for the zone supporting AD
    2) All internal DNS clients NIC\IP properties must specify SOLELY
    that internal, dynamic DNS server (set.)
    3) DCs and even DNS servers are DNS clients too -- see #2
    4) If you have more than one Domain, every DNS server must
    be able to resolve ALL domains (either directly or indirectly)

    netdiag /fix

    ....or maybe:

    dcdiag /fix

    (Win2003 can do this from Support tools):
    nltest /dsregdns /server:DC-ServerNameGoesHere
    http://support.microsoft.com/kb/q260371/

    Ensure that DNS zones/domains are fully replicated to all DNS
    servers for that (internal) zone/domain.

    Also useful may be running DCDiag on each DC, sending the
    output to a text file, and searching for FAIL, ERROR, WARN.

    Single Label domain zone names are a problem Google:
    [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
  5. Archived from groups: microsoft.public.win2000.dns (More info?)

    Thanks a million, Herb.

    I probably fall into one of those 'special' cases. I am
    running a small, specialty web hosting company w/ roughly a
    dozen servers and ~500 websites/public domains. In fact,
    almost everything EXCEPT my AD domain controllers is
    publicly accessible. [Exception: backend SQL db servers.]

    Hence, I'm weighing the importance of split-brain DNS
    (requiring two servers dedicated to internal DNS/AD) vs.
    publishing everything (combining AD controllers/DNS servers
    and obfuscating our internal domain). This would squeeze
    me into a half-rack and save me a thousand or more per
    month. [Competition in the hosting sector is downright
    bloody anymore.]

    Does this change anything? Do you still recommend against
    AD on a public DNS server?

    Thank you VERY, VERY much!!! I greatly appreciate your
    time and effort. It may well save me a LOT of trouble.

    Dave

    >-----Original Message-----
    >"Dave" <anonymous@discussions.microsoft.com> wrote in message
    >news:044e01c5171e$bcd4af40$a501280a@phx.gbl...
    >> Hi all,
    >
    >To start: .local is not secure at all.
    >
    >It is not going to provide your zone info to anyone
    >on the Internet since local is NOT a zone in the
    >Internet namespace.
    >
    >Don't think of this as "security" -- it's not, except
    >in the sense that you are definitely not publishing
    >your INTERNAL resource names on the Internet,
    >but then you should not do that no matter what name
    >you pick.
    >
    >> I would like to run AD on my public DNS servers, 'hiding'
    >> my private AD domain with a non-routable extension,
    >
    >Extentions have NOTHING to do with "routable" --
    >local doesn't appear in the Internet namespace so is
    >not resolvable from the Internet root (there is no local
    >top level domain on the Internet.)
    >
    >> like the suggested '.local' (e.g., 'mycompany.local').
    >
    >It is impractical (and a very poor) design for your to run
    >your internal (AD support) DNS on a public server.
    >
    >> QUESTION: If the '.local' extension is common knowledge or
    >> becomes a standard, it follows that 'mycompany.local' is
    >> easily guessable.
    >
    >You are misunderstanding the purpose of the local and
    >the actual effect.
    >
    >It is merely to avoid registering on the Internet and
    publishing
    >the name there, as well as guarantee that you will not class
    >with anyone else (since they cannot register it either.)
    >
    >> What will prevent eavesdroppers from
    >> querying my public DNS servers for the private
    >> 'mycompany.local' AD names/addresses?
    >
    >Not a all. The way you prevent this is by NOT allowing
    >your internal DNS server to offer resolution on the
    >Internet. It doesn't matter what name you use, don't offer
    >the internal zone on the Internet.
    >
    >> Should I instead
    >> employ something unobvious, like 'mycompany.abcxyz'?
    >
    >No, you just should try to approach the problem as above.
    >
    >Most people shouldn't even be running ANY public DNS
    >server themselves but should leave their public DNS as
    >the registray.
    >
    >> Any advice is greatly appreciated.
    >
    >DNS for AD SHOULD be inside the firewalls -- obviously
    >there may be exceptions for those people deploying and
    >AD publicly but this is VERY uncommon and represents a
    >serious security task (keeping the whole thing safe.)
    >
    >DNS for AD should GENERALLY be on the DCs for most
    >small business situations. (More exceptions to this but it
    >is a good practice.)
    >
    >From another message you mention the need to avoid
    >addition hardware: This is among the reasons you do
    >NOT want to run your external DNS as all -- move it
    >(back) to the registrar in most cases.
    >
    >You cannot practically run the internal and external
    >versions of a Shadow (or Split) DNS on the same
    >server in any case.
    >
    >Once you choose a DNS name for your AD you cannot
    >change it anyway (in Win2000 and difficult in Win2003)
    >so you must BRING that zone which supports AD inside
    >(whether it is the same as you use outside or not).
    >
    >In Shadow DNS, there really are two zones -- one version
    >on the Internet, and another SEPARATE version of the zone
    >on the internal Net. Once you realize that their are really
    >TWO zones with the same name it makes easier to think
    >about.
    >
    >General checks on DNS for AD
    > 1) Dynamic for the zone supporting AD
    > 2) All internal DNS clients NIC\IP properties must
    specify SOLELY
    > that internal, dynamic DNS server (set.)
    > 3) DCs and even DNS servers are DNS clients too -- see #2
    > 4) If you have more than one Domain, every DNS server must
    > be able to resolve ALL domains (either
    directly or indirectly)
    >
    > netdiag /fix
    >
    >....or maybe:
    >
    > dcdiag /fix
    >
    > (Win2003 can do this from Support tools):
    > nltest /dsregdns /server:DC-ServerNameGoesHere
    >http://support.microsoft.com/kb/q260371/
    >
    >Ensure that DNS zones/domains are fully replicated to all DNS
    >servers for that (internal) zone/domain.
    >
    >Also useful may be running DCDiag on each DC, sending the
    >output to a text file, and searching for FAIL, ERROR, WARN.
    >
    >Single Label domain zone names are a problem Google:
    >[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
    >
    >
    >
    >.
    >
  6. Archived from groups: microsoft.public.win2000.dns (More info?)

    Thank you, DevilsPGD, but doesn't running a sub-domain
    (e.g., 'example.domain.com') require another pair of AD
    controllers? I was under the impression that each
    additional level requires a separate AD space w/ respective
    controllers.

    Thanks again.

    Dave

    >-----Original Message-----
    >In message <05b301c5176f$0021a1e0$a501280a@phx.gbl> "Dave"
    ><anonymous@discussions.microsoft.com> wrote:
    >
    >>Thank you, Roland, but this article only answers the
    >>question by saying, "don't do it." Other authors, such as
    >>the well-respected Mark Minasi, suggest that running AD on
    >>a public DNS server is a viable solution.
    >>
    >>FYI, I am running split-brain DNS already, as recommended
    >>by the article you present. But our network is so small
    >>that we no longer want to dedicate separate servers to DNS,
    >>AD, backup DNS and backup AD. It's just too much hardware
    >>for our modest needs. If we MUST have public DNS servers,
    >>then it seems logical to also put our AD there, if at all
    >>possible.
    >
    >Personally, I don't see the harm in having this
    information publicly
    >available -- In most cases an attacker will already be
    able to perform
    >DNS lookups within your network by the time they get far
    enough in to do
    >any damage.
    >
    >All that being said, my DNS is in private name space. I use a
    >internal.example.com nomenclature where everything under
    internal is
    >only resolvable internally, externally most of it points
    to NXDOMAIN,
    >although a few hosts have valid external IPs (the VPN
    server being a big
    >one -- Some people VPN internally too, so it makes
    everybody's life
    >easier)
    >
    >
    >--
    >I walked into a bar the other day and ordered a double.
    >The bartender brought out a guy who looked just like me.
    >.
    >
  7. Archived from groups: microsoft.public.win2000.dns (More info?)

    > Personally, I don't see the harm in having this information publicly
    > available -- In most cases an attacker will already be able to perform
    > DNS lookups within your network by the time they get far enough in to do
    > any damage.

    It is not a direct security threat (giving away
    passwords or keys or some such) but it is
    very analogous to making your internal telephone
    directory available to non-company persons.

    It allows the outsider to map your network to some
    extent and can easily provide the information needed
    to perform a "social hack" (e.g., call up and sound
    like the hacker is 'official' since he knows all the
    right names etc.)

    This problem is more pronounced in large companies
    which is again analogous to the telephone directory
    problem.

    --
    Herb Martin


    "DevilsPGD" <ihatespam@crazyhat.net> wrote in message
    news:nohh1190rnnkfjmmdrehe3o07m44base4f@localhost...
    > In message <05b301c5176f$0021a1e0$a501280a@phx.gbl> "Dave"
    > <anonymous@discussions.microsoft.com> wrote:
    >
    > >Thank you, Roland, but this article only answers the
    > >question by saying, "don't do it." Other authors, such as
    > >the well-respected Mark Minasi, suggest that running AD on
    > >a public DNS server is a viable solution.
    > >
    > >FYI, I am running split-brain DNS already, as recommended
    > >by the article you present. But our network is so small
    > >that we no longer want to dedicate separate servers to DNS,
    > >AD, backup DNS and backup AD. It's just too much hardware
    > >for our modest needs. If we MUST have public DNS servers,
    > >then it seems logical to also put our AD there, if at all
    > >possible.
    >
    > Personally, I don't see the harm in having this information publicly
    > available -- In most cases an attacker will already be able to perform
    > DNS lookups within your network by the time they get far enough in to do
    > any damage.
    >
    > All that being said, my DNS is in private name space. I use a
    > internal.example.com nomenclature where everything under internal is
    > only resolvable internally, externally most of it points to NXDOMAIN,
    > although a few hosts have valid external IPs (the VPN server being a big
    > one -- Some people VPN internally too, so it makes everybody's life
    > easier)
    >
    >
    > --
    > I walked into a bar the other day and ordered a double.
    > The bartender brought out a guy who looked just like me.
  8. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Dave" <anonymous@discussions.microsoft.com> wrote in message
    news:06f401c51787$5a27f8c0$a401280a@phx.gbl...
    > Thank you, DevilsPGD, but doesn't running a sub-domain
    > (e.g., 'example.domain.com') require another pair of AD
    > controllers?

    No, it does not require it, but it is the usual practice.

    Note, that this is again solved by leaving (returning)
    the PUBLIC DNS to the registrar where it generally
    belongs.

    > I was under the impression that each
    > additional level requires a separate AD space w/ respective
    > controllers.

    AD will require a different (sub) domain name for
    each domain of course, and each domain requires
    a corresponding DNS zone, but those zones COULD
    be placed on the same (set of) DNS server(s.)

    It is not the usual practice however.

    --
    Herb Martin


    >
    > Thanks again.
    >
    > Dave
    >
    > >-----Original Message-----
    > >In message <05b301c5176f$0021a1e0$a501280a@phx.gbl> "Dave"
    > ><anonymous@discussions.microsoft.com> wrote:
    > >
    > >>Thank you, Roland, but this article only answers the
    > >>question by saying, "don't do it." Other authors, such as
    > >>the well-respected Mark Minasi, suggest that running AD on
    > >>a public DNS server is a viable solution.
    > >>
    > >>FYI, I am running split-brain DNS already, as recommended
    > >>by the article you present. But our network is so small
    > >>that we no longer want to dedicate separate servers to DNS,
    > >>AD, backup DNS and backup AD. It's just too much hardware
    > >>for our modest needs. If we MUST have public DNS servers,
    > >>then it seems logical to also put our AD there, if at all
    > >>possible.
    > >
    > >Personally, I don't see the harm in having this
    > information publicly
    > >available -- In most cases an attacker will already be
    > able to perform
    > >DNS lookups within your network by the time they get far
    > enough in to do
    > >any damage.
    > >
    > >All that being said, my DNS is in private name space. I use a
    > >internal.example.com nomenclature where everything under
    > internal is
    > >only resolvable internally, externally most of it points
    > to NXDOMAIN,
    > >although a few hosts have valid external IPs (the VPN
    > server being a big
    > >one -- Some people VPN internally too, so it makes
    > everybody's life
    > >easier)
    > >
    > >
    > >--
    > >I walked into a bar the other day and ordered a double.
    > >The bartender brought out a guy who looked just like me.
    > >.
    > >
  9. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Dave" <anonymous@discussions.microsoft.com> wrote in message
    news:06f301c51786$ec6cb190$a401280a@phx.gbl...
    > Thanks a million, Herb.
    >
    > I probably fall into one of those 'special' cases. I am
    > running a small, specialty web hosting company w/ roughly a
    > dozen servers and ~500 websites/public domains.

    You may actually be correct. Managing so many zones
    is likely best done with (your own) automated scripts,
    so if you regularly use Perl or some other scripts or
    automated editing method to change MULTIPLE zones
    then you likely are better off on your own.

    If you always use the GUI, then the answer is likely "no",
    except for the tediousness of moving so many zones back
    to the registrar. <grin>

    > In fact,
    > almost everything EXCEPT my AD domain controllers is
    > publicly accessible. [Exception: backend SQL db servers.]

    And that should be kept sepepate in practically ALL cases.

    > Hence, I'm weighing the importance of split-brain DNS

    "Split brain" is an unfortunate term for something that already
    has two (man) names: Shadow DNS (or Split DNS.)

    Your problem (more DNS servers) has NOTHING to do with
    the split brain issue. Whether you use child, internal private,
    or public-Shadow DNS name you need to separate the internal
    from the external.

    > (requiring two servers dedicated to internal DNS/AD) vs.
    > publishing everything (combining AD controllers/DNS servers
    > and obfuscating our internal domain).

    Is your DC on the Internet?

    If not, you use the DC for the Internal DNS.

    If so, you have other security problems that make the
    name issue PALE in comparison.

    > This would squeeze
    > me into a half-rack and save me a thousand or more per
    > month. [Competition in the hosting sector is downright
    > bloody anymore.]

    You can rent a server for a fraction of that price.


    > Does this change anything? Do you still recommend against
    > AD on a public DNS server?

    Where is your AD DC? Put your internal DNS on that machine.

    If you really must run it on a public machine you might
    even consider Virtual Server (or a similar product.)

    > Thank you VERY, VERY much!!! I greatly appreciate your
    > time and effort. It may well save me a LOT of trouble.

    You can call me if you wish -- phone is on
    my web site: www.LearnQuick.Com


    --
    Herb Martin


    "Dave" <anonymous@discussions.microsoft.com> wrote in message
    news:06f301c51786$ec6cb190$a401280a@phx.gbl...
    > Thanks a million, Herb.
    >
    > I probably fall into one of those 'special' cases. I am
    > running a small, specialty web hosting company w/ roughly a
    > dozen servers and ~500 websites/public domains. In fact,
    > almost everything EXCEPT my AD domain controllers is
    > publicly accessible. [Exception: backend SQL db servers.]
    >
    > Hence, I'm weighing the importance of split-brain DNS
    > (requiring two servers dedicated to internal DNS/AD) vs.
    > publishing everything (combining AD controllers/DNS servers
    > and obfuscating our internal domain). This would squeeze
    > me into a half-rack and save me a thousand or more per
    > month. [Competition in the hosting sector is downright
    > bloody anymore.]
    >
    > Does this change anything? Do you still recommend against
    > AD on a public DNS server?
    >
    > Thank you VERY, VERY much!!! I greatly appreciate your
    > time and effort. It may well save me a LOT of trouble.
    >
    > Dave
    >
    > >-----Original Message-----
    > >"Dave" <anonymous@discussions.microsoft.com> wrote in message
    > >news:044e01c5171e$bcd4af40$a501280a@phx.gbl...
    > >> Hi all,
    > >
    > >To start: .local is not secure at all.
    > >
    > >It is not going to provide your zone info to anyone
    > >on the Internet since local is NOT a zone in the
    > >Internet namespace.
    > >
    > >Don't think of this as "security" -- it's not, except
    > >in the sense that you are definitely not publishing
    > >your INTERNAL resource names on the Internet,
    > >but then you should not do that no matter what name
    > >you pick.
    > >
    > >> I would like to run AD on my public DNS servers, 'hiding'
    > >> my private AD domain with a non-routable extension,
    > >
    > >Extentions have NOTHING to do with "routable" --
    > >local doesn't appear in the Internet namespace so is
    > >not resolvable from the Internet root (there is no local
    > >top level domain on the Internet.)
    > >
    > >> like the suggested '.local' (e.g., 'mycompany.local').
    > >
    > >It is impractical (and a very poor) design for your to run
    > >your internal (AD support) DNS on a public server.
    > >
    > >> QUESTION: If the '.local' extension is common knowledge or
    > >> becomes a standard, it follows that 'mycompany.local' is
    > >> easily guessable.
    > >
    > >You are misunderstanding the purpose of the local and
    > >the actual effect.
    > >
    > >It is merely to avoid registering on the Internet and
    > publishing
    > >the name there, as well as guarantee that you will not class
    > >with anyone else (since they cannot register it either.)
    > >
    > >> What will prevent eavesdroppers from
    > >> querying my public DNS servers for the private
    > >> 'mycompany.local' AD names/addresses?
    > >
    > >Not a all. The way you prevent this is by NOT allowing
    > >your internal DNS server to offer resolution on the
    > >Internet. It doesn't matter what name you use, don't offer
    > >the internal zone on the Internet.
    > >
    > >> Should I instead
    > >> employ something unobvious, like 'mycompany.abcxyz'?
    > >
    > >No, you just should try to approach the problem as above.
    > >
    > >Most people shouldn't even be running ANY public DNS
    > >server themselves but should leave their public DNS as
    > >the registray.
    > >
    > >> Any advice is greatly appreciated.
    > >
    > >DNS for AD SHOULD be inside the firewalls -- obviously
    > >there may be exceptions for those people deploying and
    > >AD publicly but this is VERY uncommon and represents a
    > >serious security task (keeping the whole thing safe.)
    > >
    > >DNS for AD should GENERALLY be on the DCs for most
    > >small business situations. (More exceptions to this but it
    > >is a good practice.)
    > >
    > >From another message you mention the need to avoid
    > >addition hardware: This is among the reasons you do
    > >NOT want to run your external DNS as all -- move it
    > >(back) to the registrar in most cases.
    > >
    > >You cannot practically run the internal and external
    > >versions of a Shadow (or Split) DNS on the same
    > >server in any case.
    > >
    > >Once you choose a DNS name for your AD you cannot
    > >change it anyway (in Win2000 and difficult in Win2003)
    > >so you must BRING that zone which supports AD inside
    > >(whether it is the same as you use outside or not).
    > >
    > >In Shadow DNS, there really are two zones -- one version
    > >on the Internet, and another SEPARATE version of the zone
    > >on the internal Net. Once you realize that their are really
    > >TWO zones with the same name it makes easier to think
    > >about.
    > >
    > >General checks on DNS for AD
    > > 1) Dynamic for the zone supporting AD
    > > 2) All internal DNS clients NIC\IP properties must
    > specify SOLELY
    > > that internal, dynamic DNS server (set.)
    > > 3) DCs and even DNS servers are DNS clients too -- see #2
    > > 4) If you have more than one Domain, every DNS server must
    > > be able to resolve ALL domains (either
    > directly or indirectly)
    > >
    > > netdiag /fix
    > >
    > >....or maybe:
    > >
    > > dcdiag /fix
    > >
    > > (Win2003 can do this from Support tools):
    > > nltest /dsregdns /server:DC-ServerNameGoesHere
    > >http://support.microsoft.com/kb/q260371/
    > >
    > >Ensure that DNS zones/domains are fully replicated to all DNS
    > >servers for that (internal) zone/domain.
    > >
    > >Also useful may be running DCDiag on each DC, sending the
    > >output to a text file, and searching for FAIL, ERROR, WARN.
    > >
    > >Single Label domain zone names are a problem Google:
    > >[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
    > >
    > >
    > >
    > >.
    > >
  10. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Dave" <anonymous@discussions.microsoft.com> wrote in message
    news:06f401c51787$5a27f8c0$a401280a@phx.gbl...
    : Thank you, DevilsPGD, but doesn't running a sub-domain
    : (e.g., 'example.domain.com') require another pair of AD
    : controllers? I was under the impression that each
    : additional level requires a separate AD space w/ respective
    : controllers.

    No. I'm running internal.domain.com. I wish I had done it differently as
    domain.local because the simple name would then be domain, instead of
    internal.

    Ex.
    domain\administrator vs internal\administrator

    You don't need the redundancy but is recommended as a secure model because
    if you have one and it's down, everyone has issues.

    Ex.

    If I have a single DC, running AD/DNS. All my users will point to this box
    for DNS resolution. If it is down, there is no backup so they cannot get to
    the Internet.

    --
    Roland Hall
    /* This information is distributed in the hope that it will be useful, but
    without any warranty; without even the implied warranty of merchantability
    or fitness for a particular purpose. */
    Online Support for IT Professionals -
    http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
    How-to: Windows 2000 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
    FAQ W2K/2K3 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
  11. Archived from groups: microsoft.public.win2000.dns (More info?)

    "DevilsPGD" wrote in message
    news:nohh1190rnnkfjmmdrehe3o07m44base4f@localhost...
    : In message <05b301c5176f$0021a1e0$a501280a@phx.gbl> "Dave"
    : <anonymous@discussions.microsoft.com> wrote:
    :
    : >Thank you, Roland, but this article only answers the
    : >question by saying, "don't do it." Other authors, such as
    : >the well-respected Mark Minasi, suggest that running AD on
    : >a public DNS server is a viable solution.
    : >
    : >FYI, I am running split-brain DNS already, as recommended
    : >by the article you present. But our network is so small
    : >that we no longer want to dedicate separate servers to DNS,
    : >AD, backup DNS and backup AD. It's just too much hardware
    : >for our modest needs. If we MUST have public DNS servers,
    : >then it seems logical to also put our AD there, if at all
    : >possible.
    :
    : Personally, I don't see the harm in having this information publicly
    : available -- In most cases an attacker will already be able to perform
    : DNS lookups within your network by the time they get far enough in to do
    : any damage.

    So why make it available without having to break in to get it? A hacker
    should not be allowed to perform a zone transfer nor should she be able to
    engineer internal informaton externally.

    Keeping external entries on external servers and internal entries in
    internal servers does not expose anything. Hackers look for these to be run
    together so yes, then they do have recon information that can be used
    against you, not to mention social engineering attacks.

    Over 90% of what a hacker does is recon. That alone is the difference
    between a hacker and a script kiddie. 99% of what a script kiddie does is
    attack. I get *nix attacks against IIS and Windows attacks against STD
    Linux. They have no clue and don't care. A true hacker will never attack
    until she knows your network, your defenses, etc. and she will never attack
    directly.

    : All that being said, my DNS is in private name space. I use a
    : internal.example.com nomenclature where everything under internal is
    : only resolvable internally, externally most of it points to NXDOMAIN,
    : although a few hosts have valid external IPs (the VPN server being a big
    : one -- Some people VPN internally too, so it makes everybody's life
    : easier)

    Any door you create into your private network is another door for a
    potential hacker to exploit. Doors should be kept at a minimum. MSFT was
    hacked twice through a VPN into the private network. How? The user on the
    other end was not secure and while conned into downloading a soon to be
    released version of a game, also downloaded a trojan which gave the hackers
    the ability to traverse the internal network through the tunnel. All they
    had to do was wait until he opened the door and then they just walked right
    in.

    : --
    : I walked into a bar the other day and ordered a double.
    : The bartender brought out a guy who looked just like me.

    Cute. (O:= I like silly tags. One of my favorites is:
    Two cannibals are eating a clown.
    One turns to the other one and asks, "Does this taste funny to you?"

    --
    Roland Hall
    /* This information is distributed in the hope that it will be useful, but
    without any warranty; without even the implied warranty of merchantability
    or fitness for a particular purpose. */
    Online Support for IT Professionals -
    http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
    How-to: Windows 2000 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
    FAQ W2K/2K3 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
  12. Archived from groups: microsoft.public.win2000.dns (More info?)

    In news:OKm1HW5FFHA.1392@tk2msftngp13.phx.gbl,
    Roland Hall <nobody@nowhere> commented
    Then Kevin replied below:
    > No. I'm running internal.domain.com. I wish I had done
    > it differently as domain.local because the simple name
    > would then be domain, instead of internal.
    >
    > Ex.
    > domain\administrator vs internal\administrator

    This one is your own fault, you could have just as easily used the NetBIOS
    name of domain instead of internal. There doesn't have to be any
    relationship between the DNS and NetBIOS domain name at all. You could have
    just as easily named the NetBIOS name 'ROLAND'.


    --
    Best regards,
    Kevin D4 Dad Goodknecht Sr. [MVP]
    Hope This Helps
    ===================================
    When responding to posts, please "Reply to Group"
    via your newsreader so that others may learn and
    benefit from your issue, to respond directly to
    me remove the nospam. from my email address.
    ===================================
    http://www.lonestaramerica.com/
    ===================================
    Use Outlook Express?... Get OE_Quotefix:
    It will strip signature out and more
    http://home.in.tum.de/~jain/software/oe-quotefix/
    ===================================
    Keep a back up of your OE settings and folders
    with OEBackup:
    http://www.oehelp.com/OEBackup/Default.aspx
    ===================================
  13. Archived from groups: microsoft.public.win2000.dns (More info?)

    In message <eoAAXi5FFHA.624@TK2MSFTNGP15.phx.gbl> "Roland Hall"
    <nobody@nowhere> wrote:

    >: Personally, I don't see the harm in having this information publicly
    >: available -- In most cases an attacker will already be able to perform
    >: DNS lookups within your network by the time they get far enough in to do
    >: any damage.
    >
    >So why make it available without having to break in to get it? A hacker
    >should not be allowed to perform a zone transfer nor should she be able to
    >engineer internal informaton externally.

    I didn't say anything about zone transfers, just that there is little
    (to no) harm in allowing DNS lookups.

    In general, by the time someone is far enough along that they can make
    use of the knowledge of internal IPs they can likely just do resolution
    anyway.

    It might not be best practice, but it's not generally harmful either.

    >: All that being said, my DNS is in private name space. I use a
    >: internal.example.com nomenclature where everything under internal is
    >: only resolvable internally, externally most of it points to NXDOMAIN,
    >: although a few hosts have valid external IPs (the VPN server being a big
    >: one -- Some people VPN internally too, so it makes everybody's life
    >: easier)
    >
    >Any door you create into your private network is another door for a
    >potential hacker to exploit. Doors should be kept at a minimum. MSFT was
    >hacked twice through a VPN into the private network. How? The user on the
    >other end was not secure and while conned into downloading a soon to be
    >released version of a game, also downloaded a trojan which gave the hackers
    >the ability to traverse the internal network through the tunnel. All they
    >had to do was wait until he opened the door and then they just walked right
    >in.

    Agreed. My VPN is relatively secure since there are a limited number of
    users with access, and an even smaller number of them know their own VPN
    credentials (so they can't just walk into an internet cafe and VPN from
    there)

    The VPN doesn't completely bypass the firewall either, it just gives you
    access to some internal resources that are otherwise inaccessible. It
    would be a good place to start and attack, but the attacker had better
    get the password within three tries if they want to go anywhere other
    then to a syslog somewhere.

    While this doesn't protect against a compromised user, that's not a huge
    concern here, I trust all of the VPN-enabled users to maintain their
    PC's security.

    >: I walked into a bar the other day and ordered a double.
    >: The bartender brought out a guy who looked just like me.
    >
    >Cute. (O:= I like silly tags. One of my favorites is:
    >Two cannibals are eating a clown.
    >One turns to the other one and asks, "Does this taste funny to you?"

    I like...


    --
    If you've had half as much fun reading this as I've had writing it,
    I've had twice as much fun as you.
  14. Archived from groups: microsoft.public.win2000.dns (More info?)

    "Kevin D. Goodknecht Sr. [MVP]" <admin@nospam.WFTX.US> wrote in message
    news:ewynBg7FFHA.3840@tk2msftngp13.phx.gbl...
    : In news:OKm1HW5FFHA.1392@tk2msftngp13.phx.gbl,
    : Roland Hall <nobody@nowhere> commented
    : Then Kevin replied below:
    : > No. I'm running internal.domain.com. I wish I had done
    : > it differently as domain.local because the simple name
    : > would then be domain, instead of internal.
    : >
    : > Ex.
    : > domain\administrator vs internal\administrator
    :
    : This one is your own fault, you could have just as easily used the NetBIOS
    : name of domain instead of internal. There doesn't have to be any
    : relationship between the DNS and NetBIOS domain name at all. You could
    have
    : just as easily named the NetBIOS name 'ROLAND'.
    :

    The NetBIOS [computer] name is FS1. I named the AD internal.domain.com
    (domain.com obviously an alias of what it actually is) I have a public
    domain to match it (domain.com). I wouldn't name my AD domain the name of
    my server.

    However, unless I'm willing to scratch what I have...

    --
    Roland Hall
    /* This information is distributed in the hope that it will be useful, but
    without any warranty; without even the implied warranty of merchantability
    or fitness for a particular purpose. */
    Online Support for IT Professionals -
    http://support.microsoft.com/servicedesks/technet/default.asp?fr=0&sd=tech
    How-to: Windows 2000 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
    FAQ W2K/2K3 DNS:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
  15. Archived from groups: microsoft.public.win2000.dns (More info?)

    >Is your DC on the Internet?

    It is behind the same firewall that our publicly-accessible
    DNS servers are behind. All can be managed remotely from a
    trusted IP. This isn't a problem, is it?

    >Where is your AD DC? Put your internal DNS on that machine.

    That's how things are setup now. I have two AD
    controllers, also running DNS services for internal name
    resolution ('mycompany.net'). Then, there are two public
    DNS servers (yes, we employ lots of scripts) which hold the
    ~500 public domains, including a public (read 'false')
    rendition of the 'mycompany.net' zone.

    So, at the risk of overstaying my welcome, WHERE AM I
    CONFUSED?! It occurs to me that the only reason I am
    running separate private and public DNS servers is to hide
    the internal 'mycompany.net' zone employed by AD. [And why
    does this require separate DNS servers? Simply because
    Microsoft's DNS service will not permit me to restrict zone
    transfers for a specific domain to only trusted IPs. Such
    restrictions are possible, but global.] It then follows
    that if this zone cannot be individually secured, then
    perhaps it can be obfuscated. Then, I wouldn't need two
    separate sets of DNS servers. Being that AD and DNS run
    together nicely, I would deploy a new pair of AD
    controllers (with the new 'mycompany.local' or
    'mycompany.abcxyz' domain), and complete with now
    publicly-accessible DNS. Our security measures would
    restrict access to our AD/DNS servers to only the DNS
    server service through port 53.

    Where has my logic or assumptions gone wrong?

    Again, thank you so very much for your help.

    Dave
  16. Archived from groups: microsoft.public.win2000.dns (More info?)

    "DevilsPGD" <ihatespam@crazyhat.net> wrote in message
    news:1tei11944shqt50d133fnqcssmkr1pv8mc@localhost...
    : In message <eoAAXi5FFHA.624@TK2MSFTNGP15.phx.gbl> "Roland Hall"
    : <nobody@nowhere> wrote:
    :
    : >: Personally, I don't see the harm in having this information publicly
    : >: available -- In most cases an attacker will already be able to perform
    : >: DNS lookups within your network by the time they get far enough in to
    do
    : >: any damage.
    : >
    : >So why make it available without having to break in to get it? A hacker
    : >should not be allowed to perform a zone transfer nor should she be able
    to
    : >engineer internal informaton externally.
    :
    : I didn't say anything about zone transfers, just that there is little
    : (to no) harm in allowing DNS lookups.

    I threw that in to strengthen my argument but I disagree with your
    statement. Unless you're a network security professional you may not
    realize how all information gained can and will be used against you. BTW...
    I have found numerous DNS zones completely open. I've even seen OWA fully
    exposing a companies private information with a link on their main web page.
    The identity theives would have peed their pants to get it.

    : In general, by the time someone is far enough along that they can make
    : use of the knowledge of internal IPs they can likely just do resolution
    : anyway.
    :
    : It might not be best practice, but it's not generally harmful either.

    If I know the name of your users logon or system or their name for that
    matter, or even the name of the main DC, I can use that to social engineer
    your users. I'm generally an optimist, except with it comes to network
    security. I trust nobody, including myself.

    Whether you can perceive it to be harmful or not is not the point. The
    point is there is no reason to expose it.

    Have you ever ordered pizza over the phone for delivery and paid by credit
    card that you gave to them over the phone? Did you hear them repeat it, so
    as to make sure it was correct? Didn't they also take your address and
    phone number so they could verify you were who you said you were and so they
    could deliver it? At the time... did you feel it not generally harmful?

    : >: All that being said, my DNS is in private name space. I use a
    : >: internal.example.com nomenclature where everything under internal is
    : >: only resolvable internally, externally most of it points to NXDOMAIN,
    : >: although a few hosts have valid external IPs (the VPN server being a
    big
    : >: one -- Some people VPN internally too, so it makes everybody's life
    : >: easier)
    : >
    : >Any door you create into your private network is another door for a
    : >potential hacker to exploit. Doors should be kept at a minimum. MSFT
    was
    : >hacked twice through a VPN into the private network. How? The user on
    the
    : >other end was not secure and while conned into downloading a soon to be
    : >released version of a game, also downloaded a trojan which gave the
    hackers
    : >the ability to traverse the internal network through the tunnel. All
    they
    : >had to do was wait until he opened the door and then they just walked
    right
    : >in.
    :
    : Agreed. My VPN is relatively secure since there are a limited number of
    : users with access, and an even smaller number of them know their own VPN
    : credentials (so they can't just walk into an internet cafe and VPN from
    : there)

    And who setup their end? Nobody mentioned an internet cafe. I'm talking
    about the system they're on at home. How secure is it? Do their kids use
    their system? Do they download applications from the Internet? When did
    they last update their antivirus software? Is it enabled at all times? How
    much spyware do you think they have on their system? If the spyware can get
    in, just how secure are they? How many ports do they expose to the
    Internet? Do they even have a firewall? Do they use file sharing like
    eDonkey or Kazaa? Are they running host-based IDS? When is the last time
    they checked their log files, for the OS, the personal firewall, IDS, border
    firewall? How many Windows updates have they downloaded that have yet to be
    installed? I was on a system the other day. All patches were downloaded
    and none were installed and these were on Windows 2000. He had almost 600
    spyware instances. You couldn't hardly do anything with all the popups.
    Removing one removed part of Winsock. Winsock registry entries had to be
    removed and TCP/IP reinstalled before connectivity could be restored.
    BTW... he was running antivirus and sitting behind a firewall.

    : The VPN doesn't completely bypass the firewall either, it just gives you
    : access to some internal resources that are otherwise inaccessible.

    You have internal resources outside your firewall? How is that possible?
    How can something internal be outside? What exactly is an incomplete
    bypass?

    : It
    : would be a good place to start and attack, but the attacker had better
    : get the password within three tries if they want to go anywhere other
    : then to a syslog somewhere.

    It doesn't work that way. If your user is compromised, they just wait for
    the user to unlock the door. You are logging successful and unsucceful
    attempts right? Do you run a packet sniffer to log all traffic?

    : While this doesn't protect against a compromised user, that's not a huge
    : concern here, I trust all of the VPN-enabled users to maintain their
    : PC's security.

    You're very understanding. So, how do you protect your network from your
    users? You do realize they are more dangerous than others, don't you?

    : >: I walked into a bar the other day and ordered a double.
    : >: The bartender brought out a guy who looked just like me.
    : >
    : >Cute. (O:= I like silly tags. One of my favorites is:
    : >Two cannibals are eating a clown.
    : >One turns to the other one and asks, "Does this taste funny to you?"
    :
    : I like...
    :
    : --
    : If you've had half as much fun reading this as I've had writing it,
    : I've had twice as much fun as you.

    It's nice to see you don't take disagreements with your philosophy personal.
    I always like to hear the other side. To date, I have not been on a network
    that was not lacking in security somewhere.
  17. Archived from groups: microsoft.public.win2000.dns (More info?)

    <anonymous@discussions.microsoft.com> wrote in message
    news:070801c517de$80e83f90$a501280a@phx.gbl...
    > >Is your DC on the Internet?
    >
    > It is behind the same firewall that our publicly-accessible
    > DNS servers are behind. All can be managed remotely from a
    > trusted IP. This isn't a problem, is it?
    >
    > >Where is your AD DC? Put your internal DNS on that machine.
    >
    > That's how things are setup now. I have two AD
    > controllers, also running DNS services for internal name
    > resolution ('mycompany.net'). Then, there are two public
    > DNS servers (yes, we employ lots of scripts) which hold the
    > ~500 public domains, including a public (read 'false')
    > rendition of the 'mycompany.net' zone.

    This is your largest problem -- you cannot hold
    two DIFFERENT versions of the same zone on
    the same DNS server.

    (I can make it work with BIND "views" , but you will
    need an additional NICs or at least IP on each NIC for
    the distinction.)

    But with BIND you would lose your ability to have
    Secure Only Updates which ARE an absolute requirement
    for a public DNS server which allows updates (ughhh!)

    > So, at the risk of overstaying my welcome, WHERE AM I
    > CONFUSED?! It occurs to me that the only reason I am
    > running separate private and public DNS servers is to hide
    > the internal 'mycompany.net' zone employed by AD.

    And to keep it secure. Remember that AD requires not just
    a DNS zone but a DYNAMIC one.

    If you don't put it on a DC it cannot be "secure only."


    > [And why
    > does this require separate DNS servers? Simply because
    > Microsoft's DNS service will not permit me to restrict zone
    > transfers for a specific domain to only trusted IPs.

    It will allow you to so restrict ZONE TRANSFERS what it
    (MS DNS) will not allow you to is to offer different VIEWS.

    > Such
    > restrictions are possible, but global.]

    Zone transfers are on a per zone basis; they must be logically
    since the secondaries of one zone may not be the secondaries
    of another zone.

    > It then follows
    > that if this zone cannot be individually secured, then
    > perhaps it can be obfuscated. Then, I wouldn't need two
    > separate sets of DNS servers.

    AD DNS needs to be INSIDE and protected (secured and
    almost certainly unreachable.)

    The fact that you have another business supplying DNS (or
    web sites etc) should not be confused with your AD.

    > Being that AD and DNS run
    > together nicely, I would deploy a new pair of AD
    > controllers (with the new 'mycompany.local' or
    > 'mycompany.abcxyz' domain), and complete with now
    > publicly-accessible DNS. Our security measures would
    > restrict access to our AD/DNS servers to only the DNS
    > server service through port 53.

    And you could JUST make this work with "Secure Updates
    Only" but it is not something that I would ever recommend.

    OF course this means destroying your current domain and
    recreating it -- or upgrading it to Win2003 (special mode)
    to rename a doman.

    > Where has my logic or assumptions gone wrong?

    It's a bad architecture to consider exposing the internal
    AD zone publicly.

    > Again, thank you so very much for your help.
  18. Archived from groups: microsoft.public.win2000.dns (More info?)

    In news:OvxJBW8FFHA.3368@TK2MSFTNGP10.phx.gbl,
    Roland Hall <nobody@nowhere> commented
    Then Kevin replied below:
    > "Kevin D. Goodknecht Sr. [MVP]" <admin@nospam.WFTX.US>
    > wrote in message
    > news:ewynBg7FFHA.3840@tk2msftngp13.phx.gbl...
    >> In news:OKm1HW5FFHA.1392@tk2msftngp13.phx.gbl,
    >> Roland Hall <nobody@nowhere> commented
    >> Then Kevin replied below:
    >>> No. I'm running internal.domain.com. I wish I had done
    >>> it differently as domain.local because the simple name
    >>> would then be domain, instead of internal.
    >>>
    >>> Ex.
    >>> domain\administrator vs internal\administrator
    >>
    >> This one is your own fault, you could have just as
    >> easily used the NetBIOS name of domain instead of
    >> internal. There doesn't have to be any relationship
    >> between the DNS and NetBIOS domain name at all. You
    >> could have just as easily named the NetBIOS name
    >> 'ROLAND'.
    >>
    >
    > The NetBIOS [computer] name is FS1. I named the AD
    > internal.domain.com (domain.com obviously an alias of
    > what it actually is) I have a public domain to match it
    > (domain.com). I wouldn't name my AD domain the name of
    > my server.
    >
    > However, unless I'm willing to scratch what I have...

    I was referring to this line:
    >>> No. I'm running internal.domain.com. I wish I had done
    >>> it differently as domain.local because the simple name
    >>> would then be domain, instead of internal.

    The simple name is the NetBIOS name i.e. the name you see in Network places.
    You still could have used "domain" insted of "internal" You were given the
    choice during DCPROMO, you can elect to accept the default name, or you
    could have used a different name.

    Personnaly I like the name I chose, HOME for the NetBIOS name with the DNS
    name of 'home.domain.com'
    This work very well, as I have delegated the name home in the public DNS to
    the internal DNS server and private IP for the internal name. This is for
    VPN clients, so the DNS resolution is seemless when they connect. No hosts
    files are needed in this setup.


    --
    Best regards,
    Kevin D4 Dad Goodknecht Sr. [MVP]
    Hope This Helps
    ===================================
    When responding to posts, please "Reply to Group"
    via your newsreader so that others may learn and
    benefit from your issue, to respond directly to
    me remove the nospam. from my email address.
    ===================================
    http://www.lonestaramerica.com/
    ===================================
    Use Outlook Express?... Get OE_Quotefix:
    It will strip signature out and more
    http://home.in.tum.de/~jain/software/oe-quotefix/
    ===================================
    Keep a back up of your OE settings and folders
    with OEBackup:
    http://www.oehelp.com/OEBackup/Default.aspx
    ===================================
Ask a new question

Read More

DNS Extension Servers Windows Product