Re: How Secure is ".Local?"
From: Dave (anonymous_at_discussions.microsoft.com)
Date: 02/20/05
- Next message: Dave: "Re: How Secure is ".Local?""
- Previous message: Herb Martin: "Re: How Secure is ".Local?""
- In reply to: Herb Martin: "Re: How Secure is ".Local?""
- Next in thread: Herb Martin: "Re: How Secure is ".Local?""
- Reply: Herb Martin: "Re: How Secure is ".Local?""
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 20 Feb 2005 12:01:10 -0800
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: ]
>
>
>
>.
>
- Next message: Dave: "Re: How Secure is ".Local?""
- Previous message: Herb Martin: "Re: How Secure is ".Local?""
- In reply to: Herb Martin: "Re: How Secure is ".Local?""
- Next in thread: Herb Martin: "Re: How Secure is ".Local?""
- Reply: Herb Martin: "Re: How Secure is ".Local?""
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
