0

Looking for some input on a best practices approach.

  • Currently have an AD domain w/ secure dynamic DNS updates disabled (e.g. any client can update a DNS record). Would like to move away from this.
  • 50+ remote sites (connected w/ MPLS and each has an Internet circuit too) -- some with local DHCP servers (Windows) and many with DHCP running off of Cisco switches. only about 30-40% of sites have local IT staff.
  • Some clients point to AD for DNS (but most sites don't have an AD server), others to BIND resolvers. Moving more to BIND resolvers at local sites to handle Internet resolution out of the site's Internet circuit for best geolocation and performance for SaaS apps as well as for RPZ. We slave the AD zones to the BIND servers for performance and resiliency. If clients point to BIND, however, obviously Dynamic DNS updates won't work.

We are trying to standardize and keep things as secure as possible. Looking at options:

  1. Enable Secure DNS updates in AD and have DHCP servers handle update of DNS names on behalf of clients. Seems like this doesn't add any security value as anyone can send a DHCP Request with an Option 81 header. Also, not sure Cisco devices can update dynamic DNS securely (e.g. w/ Kerberos). Guessing not.
  2. Similar to #1, but use MS DHCP only for the updates (DHCP would not necessarily be local to the office in this case if site doesn't have server infrastructure).
  3. Get AD server at every site which can be used for primary DNS (and DHCP) by clients (and handle secure DNS updates directly from clients). Also have BIND server for Internet lookups.
  4. Same as #3 but have AD do both internal and Internet. However, we make pretty heavy use of BIND views so not sure this is possible unless we moved Server 2016 (on 2012 now).

What do those of you out there in mid-size to large orgs do?

1
  • enterprises are going to have 2 local domain controllers at each site, with sites and services configured, and with your situation I would stick with bind as your AD forwarders. Jan 23, 2017 at 4:59

1 Answer 1

0

In my 1000+ location network, we long ago gave up on having AD DCs at each location for obvious cost reasons, not to mention the fact that if the network is down, the users aren't getting any work done anyway, AD or no AD (the industrial systems are handled separately). We have various approaches in place for DHCP/DNS, but the main one is:

  • centralized DHCP on dedicated appliances (which essentially wrap ISC DHCP and BIND). They handle dynamic DNS updates from option 81 to the AD DNS servers using a specific service account to do so. Elsewhere in the world this is still handled using MS DHCP. We do not particularly trust the names that are dynamically updated in DNS, but have not felt the need to go a step further so far, as this would most likely require much better perimeter security on the network so that non-managed devices can't get on the network in the first place.
  • Internal DNS on AD domain controllers available on the datacenters and largest user locations
  • dedicated appliances for public name resolution
  • the clients all point to AD DNS, which then forwards to the appliances for external domains. There isn't much in the way of advanced functionality here.

The main issue with this setup is that geolocalization doesn't work since there are public resolvers only on the 3 main datacenters. This is usually not a big problem as most browser requests are proxied through a cloud filtering service which handles DNS, but has lately been complicating things when we use video services (e.g. Google Hangouts) that would benefit from accurate geo information to select the right datacenter.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .