Re: Restrict Dynamic Updates

In news:34309465-E5DE-4772-A0ED-57FA08E240FF@xxxxxxxxxxxxx,
Robert Lindholm <RobertLindholm@xxxxxxxxxxxxxxxxxxxxxxxxx> typed:
Ace:

Currently I have a firewalled AD test lab setup, so I'm not
experiencing updates from unexpected external hosts, but our
procduction environment is quite different.

Our current production network doesn't have a perimeter firewall, nor
do we we have dedicated separate external/internal DNS servers.

Our current [BIND] DNS servers provide both external/internal name
resolution and have public IP addresses.

The current plan is to continue to point our clients to the BIND DNS
servers for external / non-AD internal name resolution, but delegate
the AD zones to provide internal AD-specific name resolution.

The other alternative option is to point our clients to the AD/DNS
servers for internal AD-specific name resolution, but use forwarders
to point clients to our BIND/DNS servers for internal non-AD and
external name resolution.

At this point, I'm not sure which scenario is preferable, but have
decided to start with the option that requires the least amount of
rework, with the assumption that I can change this if required.

As the AD/DNS server(s) will in all likelihood have public IP
addresses too, I'm trying to maximize their security configuration in
an effort to minimize their exposure to external networks and the
Internet.

I've tried re-enabling the Windows firewall with the DNS ports
outlined in the article "HOW TO Configure DNS for Internet Access in
Windows Server 2003", realizing that that was not the initial intent
of this article, but in doing so may have "broken" some other [NTDS]
functionality.

Any further recommendations are greatly appreciated.

Thanks,

Bob

Bob,

See, that is one thing I *highly* suggest not to do, that is allow an
internal DNS server host external public data. It's exposed. I know BIND has
the ability to create 'views', however I don't agree with allowing an
internal DNS server that hosts your internal AD infrastructure access from
the outside world. If it gets compromised, they may be able to find or alter
your internal resources.

So you are also saying your internal production network uses public IP
addresses? Curious, why wasn't a private IP scheme utilized?

Also, if you use the BIND servers as an additional IP in a client's IP
properties, and the BIND server does not host the AD zone, you are inviting
AD errors on your clients and DCs.

Apparently it seems you didn't fully read KB825036, which explains DNS
settings for domain controllers, the resolution process, and other options,
and KB291382, which explins in more detail. Bot clearly state you cannot use
an ISP or a DNS server that doesn't host the AD zone. Let's go over it a
little more in detail with a design suggestion.

Keep in mind, the cardinal rule with AD is simple and you can ask any
engineer who is familiar with AD or had the mishap of using an ISP's DNS and
found lot's of problems that when he/she re-pointed to their internal DNS to
find the problems disappear.

ONLY, ONLY point ALL domain members (DCs, workstations, laptops, member
servers, etc) ONLY to the internal DNS server that is hosting the AD zone.
Do not mix and match them or you will experience errors, as you've seen
already. This is because of the defaul client-side resolution process that
all machines use, especially Windows, since you have an AD infrastructure,
this is highly important. See if the first doesn't respond, it will ask the
second one. Now if the second one is the BIND server, and let's say it is
not hosting the AD zone, then it will fail and the client cannot logon,
authenticate to printers, and about 50 other errors. I think you already
experienced one of them, a DC NTDS error. That is NOT good.

Then for efficient internet resolution, configure a forwarder to your BIND
servers in DNS properties. KB323380 shows you how. See my links I offered in
my previous post.

Suggestions and recommendations:
1. The ideal and secured scenario is to use internal private IPs behind a
secured NAT device, such as a Cisco PIX. There are other comparable devices,
but I am partial to these guys. Don't use public IPs, for the best you can
do is firewall, whereas a NAT 'hides' internal resources. Firewalling cannot
do the job as best as a NAT device.
2. Setup DNS on your DC(s). Only use these DNS servers for the internal
machines.
3. In DNS properties, configure a forwarder to your ISP's DNS server, or in
your case, your BIND servers. (KB323380)
4. Place your BIND servers in a public IP DMZ. This will be on the other
side of the NAT device.
5. Since you have public data you want to host, I would suggest to setup a
two-prong firewall/NAT design. In this design, a router, which you obviously
have now, will be the entry point. On the internal subnet of the router is
where the BIND machines will sit. This is the DMZ subnet. On the same
subnet, hook up the PIX (or whatever you choose to purchase). The "WAN"
interface will be sitting on the DMZ. The internal or "LAN" interface will
connect to your internal switch that all your machine will be connected to.
Come up with a private IP range. Depending on how many hosts (machines) you
have will dictate the IP range and subnet mask. You can safely use a
10.10.0.0/16 range (/16 is equal to 255.255.0.0), which will support up to
65,000 hosts. If you have multiple sites (locations), let's say one other
site, we can make that IP range, for example, 10.20.0.0/16. Even if you have
300 hosts, or even 100 hosts, this range will work fine and allow you to
grow.

So let's look at resolution in this scenario. A client needs to logon. It
looks at the first DNS addres in IP properties, it sends a query for the SRV
records it needs to locate domain resources to that DNS server and queries
for a DC to logon. The DNS server responds with the necessary SRV response
and the client logons. Now if the client has a web browser open and want to
visit www.microsoft.com, it sends the query to the same DNS server. The DNS
server says, "I don't know that answer, however I have a forwarder
configured. I'll just send the query to that guy and let him resolve it and
it will send the response back to me, and I will give it to the client that
originally asked for it."

This way AD works, clients get their internet name resolution working
efficiently, and all is well.

I hope I made this easy to understand.

Also, please re-read 291382 and

Ace


.

Relevant Pages

  • [UNIX] Hardening the BIND DNS Server
    ... Hardening the BIND DNS Server ... Your Domain Name Service is the road sign to your systems on the Internet. ...
    (Securiteam)
  • Re: Can Internet Computers see my private address DNS server?
    ... To let your DNS server resolve these external names I typically just ... I would recommend using your 2003 server to perform your DHCP. ... and there are 6 clients. ... In the DNS server dialog box, I have entered my Internet Service ...
    (microsoft.public.windows.server.dns)
  • Re: Problem with ICW
    ... 825763 How to configure Internet access in Windows Small Business Server ... This newsgroup only focuses on SBS technical issues. ... On the DNS Server, create the DNS Forwarder to forward the external ...
    (microsoft.public.windows.server.sbs)
  • RE: web access slow / unreliable
    ... Smarthost or DNS Server only. ... Internet to launch CEICW. ... Suggestion 3: Double check network configuration on SBS and client computer: ...
    (microsoft.public.windows.server.sbs)
  • Re: Setting Up Home Network
    ... High Speed internet connection ... Network Printer which is already connected to the Wireless Router ... Wireless Router which connects, My Server, Printer and Wirless Laptop. ... The Internal DNS server will usually Forward ...
    (microsoft.public.windows.server.active_directory)