"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> "Daniel" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) oups.com...
>> But doesn;t that AD requires a registered FQDN in internet for it to
>> work ?
>
> No. Not at all. Not even close. Do you believe a Windows AD Domain cannot
> exist if the LAN isn't connected to the Internet? What would you do if the
> Internet had never been made public? What if Al Gore never invented it?
> (sorry, had to throw that in). They only thing in common between a Windows
> AD Domain and an Internet Public Domian is that they both use the word
> "domain" in them and the word domain starts with "D" in both of them
>
I feel I need to interject here, lest someone get the wrong impression:
Indeed, Windows domains and the domain names that we see on the Internet are
not dependent on each other, "directly". It's the word "directly" that
confuses people.
You can install a Windows domain and call it anything you want. When you set
up a public site on the internet, you need to follow a standard naming
scheme that adheres to the public DNS structure. This means that you need to
register a domain name under one of the publicly supported Top Level Domains
(like .com, .net, .org etc...).
There are many times when it is useful to use the same Internal domain name,
as the one you use Externally. In these cases, most (if not all) the
security concerns can be mitigated by using a "Properly" designed split-dns
architecture, and a good perimiter security strategy. Security in-depth is
always a good way to lock things down even further.
Split-DNS allows you to keep two separate DNS databases. One of them is used
for public/external facing clients (like anyone on the internet), and the
other one is used for private/internal clients (like anyone on your LAN). If
your public DNS server is set up to not transfer zone files or leak out
other information unsecurely, then it becomes extremely difficult for anyone
to even discover the host names that it maintains. Same thing goes for your
internal DNS servers. Just make sure you lock them down as much as possible,
following all the security best-practices you can find (there's a lot of
information out there on how to do this).
In conjunction with a proper application layer firewall (like ISA Server),
you don't even need to let external people into your inside network, in most
cases. But even if you did need to, there are many ways to secure these
sessions.
My point is, it's actually quite common to use a split-DNS architecture, so
don't let anyone tell you that it's not, or that it's unsafe. YES, it might
take a little more work, and you need to be diligent in making sure it's set
up correctly. But once it's set up properly, it is very secure and very
effective.
Some reasons why you would want to use split-DNS include:
- Email (you want your internal and external users to have access to your
Email services without complicting their lives too much)
- Shared portals
- Publicly available communications services, other than email
- SSL and other certificate-based applications sometimes break if there are
two different certificate names, and nothing acting as an intermediary
translator (like ISA).
etc...
Just my 2 cents...
Oliver
> Both the Internet and AD are dependent on DNS to function, therefore they
> both have similar structure,...it is no more complicated than that.
>
>> btw .loc is single label domain ?
>
> No. It is a Top Level Domain (TLD)
>
> "test.mycompany.loc" breaks down like this:
>
> "test" = either a host name or a child domain name (second level domain)
> "mycompany" = the actual domain name (first level domain)
> "loc" = the Top Level Domain name
>
> It reads backwards, from right to left,...
> top level domain,
> first level,
> second level,
> third level,
> ..<etc.>.....,
> hostname
>
> Keep the TLD to three characters or less. Some machine OS's don't like
> TLDs longer that three characters. Some versions of the MAC OS were this
> way.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
Similar Threads
Linear Mode
