Good Morning,

We're currently at the beginning of an eDir to AD migration. We
currently run DNS on linux. We've created our AD structure and enabled
a DNS zone for our AD domain. Now we'd like to move our public DNS
server to Windows. I'm debating whether or not to integrate our public
DNS records with AD. I very much like the benefits of having DNS stored
and replicated in AD however I'm concerned about exposing one of our DCs
to the general public (this is a medium size college campus). I was
thinking about integrating DNS on our two Domain controllers then having
one member server, totally dedicated to DNS, run a secondary copy of
the zone and having it exposed to the internet. As far as the "world"
is concerned, this would be our primary DNS server. Would this work?
Is it overkill? Is there an issue with exposing one of our DCs to the
internet for DNS services? If so, what is the best way to mitigate
those risks?

Thanks,

Travis

You absolutely do not want a DC exposed to the Internet. A standalone DNS is
the way to go.
You can copy your public zones to it, as secondaries,
Anthony


"Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
news:OTo3h2CzGHA.4816@TK2MSFTNGP06.phx.gbl...
> Good Morning,
>
> We're currently at the beginning of an eDir to AD migration. We currently
> run DNS on linux. We've created our AD structure and enabled a DNS zone
> for our AD domain. Now we'd like to move our public DNS server to
> Windows. I'm debating whether or not to integrate our public DNS records
> with AD. I very much like the benefits of having DNS stored and
> replicated in AD however I'm concerned about exposing one of our DCs to
> the general public (this is a medium size college campus). I was thinking
> about integrating DNS on our two Domain controllers then having one member
> server, totally dedicated to DNS, run a secondary copy of the zone and
> having it exposed to the internet. As far as the "world" is concerned,
> this would be our primary DNS server. Would this work? Is it overkill?
> Is there an issue with exposing one of our DCs to the internet for DNS
> services? If so, what is the best way to mitigate those risks?
>
> Thanks,
>
> Travis

"Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
news:OTo3h2CzGHA.4816@TK2MSFTNGP06.phx.gbl...
> Good Morning,
>
> We're currently at the beginning of an eDir to AD migration. We currently
> run DNS on linux. We've created our AD structure and enabled a DNS zone
> for our AD domain. Now we'd like to move our public DNS server to
> Windows.

That's perfectly fine technically but notice that it is a REALLY POOR
practice to use an INTERNAL DNS server (containing sensitive information
and generally a sensitive box itself) for EXTERNAL DNS.

> I'm debating whether or not to integrate our public DNS records with AD.
> I very much like the benefits of having DNS stored and replicated in AD
> however I'm concerned about exposing one of our DCs to the general public
> (this is a medium size college campus).

You should be; don't do this. Separate DNS for external and internal
DNS purposes -- this should MOST of the time be true even in Linux
(except that AD is much more likely to contain private info.)

Generally, all but the largest companies should put their PUBLIC DNS
BACK at the REGISTRAR.

> I was thinking about integrating DNS on our two Domain controllers then
> having one member server, totally dedicated to DNS, run a secondary copy
> of the zone and having it exposed to the internet.

Ok, but why would you wish to expose all of the private information
kept in a DNS zone supporting AD to the Internet?

Two main strategies are this:

1) Use an ENTIRELY different DNS zone for your internal domain

2) Use "shadow DNS" (aka "split DNS") with the same zone name
internally and externally on the two distinct (sets of) DNS
Server(s).

> As far as the "world" is concerned, this would be our primary DNS server.
> Would this work?

Yes, but it is a poor practice. (See above.)

> Is it overkill? Is there an issue with exposing one of our DCs to the
> internet for DNS services? If so, what is the best way to mitigate those
> risks?

And yes, you do NOT want to expose a DC to the Internet (at least
not one that runs your internal business -- there are limited exceptions
for those who actually use AD for external customer accounts etc. but
in those case they would NOT mix the internal AD with the external
or customer AD.)

Put your DNS for public services back at the REGISTRAR where
it generally belongs.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

> Thanks,
>
> Travis

Sorry, I think we're on the same page. I do have an entirely separate
zone for our public DNS. I'd like our internal servers to have a copy
of it (preferably in AD if possible). My thinking was that I'd have a
dedicated flat file DNS server that pulls the public zone off the DC as
a secondary copy. This server would only have a copy of the public zone
and would be the only one exposed to the internet (sorry I didn't make
that clear in my post). So, do I have that right or am I still missing
something?

thanks,

Travis

Herb Martin wrote:
> "Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
> news:OTo3h2CzGHA.4816@TK2MSFTNGP06.phx.gbl...
>> Good Morning,
>>
>> We're currently at the beginning of an eDir to AD migration. We currently
>> run DNS on linux. We've created our AD structure and enabled a DNS zone
>> for our AD domain. Now we'd like to move our public DNS server to
>> Windows.
>
> That's perfectly fine technically but notice that it is a REALLY POOR
> practice to use an INTERNAL DNS server (containing sensitive information
> and generally a sensitive box itself) for EXTERNAL DNS.
>
>> I'm debating whether or not to integrate our public DNS records with AD.
>> I very much like the benefits of having DNS stored and replicated in AD
>> however I'm concerned about exposing one of our DCs to the general public
>> (this is a medium size college campus).
>
> You should be; don't do this. Separate DNS for external and internal
> DNS purposes -- this should MOST of the time be true even in Linux
> (except that AD is much more likely to contain private info.)
>
> Generally, all but the largest companies should put their PUBLIC DNS
> BACK at the REGISTRAR.
>
>> I was thinking about integrating DNS on our two Domain controllers then
>> having one member server, totally dedicated to DNS, run a secondary copy
>> of the zone and having it exposed to the internet.
>
> Ok, but why would you wish to expose all of the private information
> kept in a DNS zone supporting AD to the Internet?
>
> Two main strategies are this:
>
> 1) Use an ENTIRELY different DNS zone for your internal domain
>
> 2) Use "shadow DNS" (aka "split DNS") with the same zone name
> internally and externally on the two distinct (sets of) DNS
> Server(s).
>
>> As far as the "world" is concerned, this would be our primary DNS server.
>> Would this work?
>
> Yes, but it is a poor practice. (See above.)
>
>> Is it overkill? Is there an issue with exposing one of our DCs to the
>> internet for DNS services? If so, what is the best way to mitigate those
>> risks?
>
> And yes, you do NOT want to expose a DC to the Internet (at least
> not one that runs your internal business -- there are limited exceptions
> for those who actually use AD for external customer accounts etc. but
> in those case they would NOT mix the internal AD with the external
> or customer AD.)
>
> Put your DNS for public services back at the REGISTRAR where
> it generally belongs.
>
>

That's what I thought. Thanks!

Anthony wrote:
> You absolutely do not want a DC exposed to the Internet. A standalone DNS is
> the way to go.
> You can copy your public zones to it, as secondaries,
> Anthony
>
>
> "Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
> news:OTo3h2CzGHA.4816@TK2MSFTNGP06.phx.gbl...
>> Good Morning,
>>
>> We're currently at the beginning of an eDir to AD migration. We currently
>> run DNS on linux. We've created our AD structure and enabled a DNS zone
>> for our AD domain. Now we'd like to move our public DNS server to
>> Windows. I'm debating whether or not to integrate our public DNS records
>> with AD. I very much like the benefits of having DNS stored and
>> replicated in AD however I'm concerned about exposing one of our DCs to
>> the general public (this is a medium size college campus). I was thinking
>> about integrating DNS on our two Domain controllers then having one member
>> server, totally dedicated to DNS, run a secondary copy of the zone and
>> having it exposed to the internet. As far as the "world" is concerned,
>> this would be our primary DNS server. Would this work? Is it overkill?
>> Is there an issue with exposing one of our DCs to the internet for DNS
>> services? If so, what is the best way to mitigate those risks?
>>
>> Thanks,
>>
>> Travis
>
>

"Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
news:Ojb3zPEzGHA.4452@TK2MSFTNGP05.phx.gbl...
> Sorry, I think we're on the same page. I do have an entirely separate
> zone for our public DNS. I'd like our internal servers to have a copy of
> it

That is perfectly reasonable. Merely make the internal DNS
server a "Secondary" to the external server(s).

> (preferably in AD if possible).

That makes the AD-DNS (effectively) the Primary, or "Master"
of the zone. There is nothing particularly wrong with this, but
what is the advantage? (Hint: There is almost none if any.)

> My thinking was that I'd have a dedicated flat file DNS server that pulls
> the public zone off the DC as a secondary copy. This server would only
> have a copy of the public zone and would be the only one exposed to the
> internet (sorry I didn't make that clear in my post). So, do I have that
> right or am I still missing something?

That will work, but you are still not considering just putting the
public zone back at the Registrar where it most effectively belongs
for most companies.

With the way caching works, there is almost no advantage to
have the external zone in AD on your internal servers -- and for
no advantage you have to do the extra setup including letting
(vulnerable) external servers maintain contact with internal
(sensitive) DCs.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

>
> thanks,
>
> Travis
>
> Herb Martin wrote:
>> "Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
>> news:OTo3h2CzGHA.4816@TK2MSFTNGP06.phx.gbl...
>>> Good Morning,
>>>
>>> We're currently at the beginning of an eDir to AD migration. We
>>> currently run DNS on linux. We've created our AD structure and enabled
>>> a DNS zone for our AD domain. Now we'd like to move our public DNS
>>> server to Windows.
>>
>> That's perfectly fine technically but notice that it is a REALLY POOR
>> practice to use an INTERNAL DNS server (containing sensitive information
>> and generally a sensitive box itself) for EXTERNAL DNS.
>>
>>> I'm debating whether or not to integrate our public DNS records with AD.
>>> I very much like the benefits of having DNS stored and replicated in AD
>>> however I'm concerned about exposing one of our DCs to the general
>>> public (this is a medium size college campus).
>>
>> You should be; don't do this. Separate DNS for external and internal
>> DNS purposes -- this should MOST of the time be true even in Linux
>> (except that AD is much more likely to contain private info.)
>>
>> Generally, all but the largest companies should put their PUBLIC DNS
>> BACK at the REGISTRAR.
>>
>>> I was thinking about integrating DNS on our two Domain controllers then
>>> having one member server, totally dedicated to DNS, run a secondary copy
>>> of the zone and having it exposed to the internet.
>>
>> Ok, but why would you wish to expose all of the private information
>> kept in a DNS zone supporting AD to the Internet?
>>
>> Two main strategies are this:
>>
>> 1) Use an ENTIRELY different DNS zone for your internal domain
>>
>> 2) Use "shadow DNS" (aka "split DNS") with the same zone name
>> internally and externally on the two distinct (sets of) DNS
>> Server(s).
>>
>>> As far as the "world" is concerned, this would be our primary DNS
>>> server. Would this work?
>>
>> Yes, but it is a poor practice. (See above.)
>>
>>> Is it overkill? Is there an issue with exposing one of our DCs to the
>>> internet for DNS services? If so, what is the best way to mitigate
>>> those risks?
>>
>> And yes, you do NOT want to expose a DC to the Internet (at least
>> not one that runs your internal business -- there are limited exceptions
>> for those who actually use AD for external customer accounts etc. but
>> in those case they would NOT mix the internal AD with the external
>> or customer AD.)
>>
>> Put your DNS for public services back at the REGISTRAR where
>> it generally belongs.
>>

> That will work, but you are still not considering just putting the
> public zone back at the Registrar where it most effectively belongs
> for most companies.

We're a medium size college campus with about 10,000 users (and growing
rapidly) and the CIO wants to have DNS locally housed.

>
> With the way caching works, there is almost no advantage to
> have the external zone in AD on your internal servers -- and for
> no advantage you have to do the extra setup including letting
> (vulnerable) external servers maintain contact with internal
> (sensitive) DCs.
>

I'm not sure I see the "extra setup" as being an issue, I just turn DNS
on and tell it to pull in the zone right? Also, how big of a security
issue really is allowing the "external" DNS server pull a zone transfer
from an internal one? I'm really asking for my own education, I just
have a hard time seeing why that is an issue.

Thanks for all your !

Travis

"Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
news:e1OzBePzGHA.2208@TK2MSFTNGP03.phx.gbl...
> > That will work, but you are still not considering just putting the
>> public zone back at the Registrar where it most effectively belongs
>> for most companies.
>
> We're a medium size college campus with about 10,000 users (and growing
> rapidly) and the CIO wants to have DNS locally housed.

The realities of being a University computer infrastructure
may modify some of the normal "best practices".

The main reason is that you (likely) have essentially a semi-open
physical access to your infrastructure. This is similar to the
problem businesses have started experiencing due to wireless
access but much more pervasive since likely you cannot easily
use authentication at the physical or datalink level for access
to your hubs and switches. Likely anyone can "walk in" to the
University and perhaps "plugin" to an Ethernet connection.

Running your own Public DNS is not a "bad" thing but more
trouble than it is worth for most with a small presence on the
Internet.

A commercial enteprise with 10,000 users would likely have
only a hand full to a few dozen max "Internet servers" while
a University may have such public access for EVERY major
school or college within that enterprise.

Maintaining such elaborated DNS resource records MAY be
easier if you maintain the DNS internally, and you may have
the 24/7 support needed to keep it running without failure or
outage.

>> With the way caching works, there is almost no advantage to
>> have the external zone in AD on your internal servers -- and for
>> no advantage you have to do the extra setup including letting
>> (vulnerable) external servers maintain contact with internal
>> (sensitive) DCs.
>>
>
> I'm not sure I see the "extra setup" as being an issue, I just turn DNS on
> and tell it to pull in the zone right? Also, how big of a security issue
> really is allowing the "external" DNS server pull a zone transfer from an
> internal one? I'm really asking for my own education, I just have a hard
> time seeing why that is an issue.

The real issue here is "defense in depth" strategies. By definition
your "Public DNS Server" is open to public attack by every hacker
in the world PLUS every student (or others) who works from inside
your network.

Such publicly exposed servers are typically best considered as
"sacrificial hosts" (see some good book on 'firewall' design for
more details but note that to those who design 'firewalls' defenses,
firewall are most than just hardware OR software but the ENTIRE
set of machines and software that runs from the external screen to
the internal screen and all of the protections for those public and
semi-publice machines.)

Sacrificial Hosts are those (exposed) servers which you can afford
to LOSE because you have full backups and can easily re-create them
if they are compromised AND which have limited sensitive data
locally.

Now this doesn't mean you would be 'happy' to lose them, just that
you think about them differently than you would servers which you
really cannot (easily) afford to lose to the control of a hacker (these
are typically known as "Bastion Hosts".)

For every Sacrificial Host that is allowed to contact either a Bastion
or Internally secured server you run additional risk.

Imagine the hacker that compromises and can work from the DNS
server: It is now only ONE STEP from there to the DC if you allow
the DNS to talk to that DC directly.

Is this (always) a terrible security risk? No, of course not, but whenever
I am given a way to limit exposure and decrease the "attack surface"
I try to recommend taking that path.

Security is something that is best handled from "grant no access" UNLESS
it is NECESSARY, rather than "open everything, and secure what is
important."

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

> Thanks for all your !
>
> Travis

Thanks Herb, I appreciate the advice! I'll have a chat with our
security folks and see what they want to do.

Much appreciated.

Travis

Herb Martin wrote:
> "Travis Montgomery" <tmontgomery_removethis_@nccu.edu> wrote in message
> news:e1OzBePzGHA.2208@TK2MSFTNGP03.phx.gbl...
>> > That will work, but you are still not considering just putting the
>>> public zone back at the Registrar where it most effectively belongs
>>> for most companies.
>> We're a medium size college campus with about 10,000 users (and growing
>> rapidly) and the CIO wants to have DNS locally housed.
>
> The realities of being a University computer infrastructure
> may modify some of the normal "best practices".
>
> The main reason is that you (likely) have essentially a semi-open
> physical access to your infrastructure. This is similar to the
> problem businesses have started experiencing due to wireless
> access but much more pervasive since likely you cannot easily
> use authentication at the physical or datalink level for access
> to your hubs and switches. Likely anyone can "walk in" to the
> University and perhaps "plugin" to an Ethernet connection.
>
> Running your own Public DNS is not a "bad" thing but more
> trouble than it is worth for most with a small presence on the
> Internet.
>
> A commercial enteprise with 10,000 users would likely have
> only a hand full to a few dozen max "Internet servers" while
> a University may have such public access for EVERY major
> school or college within that enterprise.
>
> Maintaining such elaborated DNS resource records MAY be
> easier if you maintain the DNS internally, and you may have
> the 24/7 support needed to keep it running without failure or
> outage.
>
>>> With the way caching works, there is almost no advantage to
>>> have the external zone in AD on your internal servers -- and for
>>> no advantage you have to do the extra setup including letting
>>> (vulnerable) external servers maintain contact with internal
>>> (sensitive) DCs.
>>>
>> I'm not sure I see the "extra setup" as being an issue, I just turn DNS on
>> and tell it to pull in the zone right? Also, how big of a security issue
>> really is allowing the "external" DNS server pull a zone transfer from an
>> internal one? I'm really asking for my own education, I just have a hard
>> time seeing why that is an issue.
>
> The real issue here is "defense in depth" strategies. By definition
> your "Public DNS Server" is open to public attack by every hacker
> in the world PLUS every student (or others) who works from inside
> your network.
>
> Such publicly exposed servers are typically best considered as
> "sacrificial hosts" (see some good book on 'firewall' design for
> more details but note that to those who design 'firewalls' defenses,
> firewall are most than just hardware OR software but the ENTIRE
> set of machines and software that runs from the external screen to
> the internal screen and all of the protections for those public and
> semi-publice machines.)
>
> Sacrificial Hosts are those (exposed) servers which you can afford
> to LOSE because you have full backups and can easily re-create them
> if they are compromised AND which have limited sensitive data
> locally.
>
> Now this doesn't mean you would be 'happy' to lose them, just that
> you think about them differently than you would servers which you
> really cannot (easily) afford to lose to the control of a hacker (these
> are typically known as "Bastion Hosts".)
>
> For every Sacrificial Host that is allowed to contact either a Bastion
> or Internally secured server you run additional risk.
>
> Imagine the hacker that compromises and can work from the DNS
> server: It is now only ONE STEP from there to the DC if you allow
> the DNS to talk to that DC directly.
>
> Is this (always) a terrible security risk? No, of course not, but whenever
> I am given a way to limit exposure and decrease the "attack surface"
> I try to recommend taking that path.
>
> Security is something that is best handled from "grant no access" UNLESS
> it is NECESSARY, rather than "open everything, and secure what is
> important."
>