"It’s Always DNS" – Some Active Directory Integrated DNS and DHCP Best Practices

The following comment was made on a mailing list we are a part of:

We keep 8.8.8.8 as a secondary DNS server in DHCP in case the primary DNS server goes offline.

No. Bad Practice. Period.

Never, ever, put a public DNS server IP address as a frame of reference for internal endpoints.

All it takes is one blip somewhere and internal endpoints are looking for internal endpoints using an external DNS server so guess what?

If the Time To Live (TTL) is set to an hour, which is customary, folks are hooped for at least an hour.

Deal with the issues at hand.

“It’s always DNS”.

DNS and Active Directory Domain Services (ADDS) best practices:

  • DC with DNS or DNS on its own has DNS0 pointing to self. Period.
    • Some would recommend 127.0.0.1 as an alternative
  • ADDS integrated DNS takes care of pointing out all of the other DNS servers on the network and resolving _in DNS_.
    • Exception to the rule is when running DCPromo on a new DNS server:
      • DNS0 PDCe
      • DNS1 Self
      • Post Promo, Remove PDCe, shift Self to DNS0

The worst practice on a DC/DNS Server or an edge providing DHCP:

  • DNS0: Self
  • DNS1: Public DNS server

SMH ☹

DHCP Settings

The settings that should be configured in DHCP:

  • Scope Options
    • 006 DNS0: DC with DNS
    • 006 DNS1: Additional DC with DNS if present
    • 015 DNS Domain Name: HO.Domain.Com
      • We’ve deprecated .Local for all Greenfield deployments
      • We’ve SPLIT DNS for RDS farms on .Local to help with certificate issues
    • 003 Router: IP of Router
  • DHCP Credentials set for DHCP to update DNS
  • Update settings configured to update all as is shown in the snip below
  • Do _not_ enable DHCP Name Protection unless the ramifications are completely understood

image

DHCP DNS Update Options

In a Windows network, both DHCP and DNS are Active Directory integrated. They belong on Windows servers. DHCP does not belong on the edge!

NOTE: We do not do Essentials where DHCP may be elsewhere!

DHCP Failover

In a setting where we have two Domain Controllers we set up DHCP Failover in Active/Passive mode. That way we can leave some resources grabbing their IP via DHCP and trust that they will get one if the primary DHCP server goes offline.

DHCP DNS IP Update Setup

A domain user ID with DHCP Administrators group membership, but restricted from all resources, should be configured. That ID is then used in DHCP’s Advanced properties. That allows DHCP to update DNS with a new IP address for an endpoint that just renewed/refreshed.

image

DHCP Dynamic Update Credentials

Conclusion

If there is a problem internally, why do users “require access to the Internet”?

That justification seems to miss the point: Dealing with the internal problem so that users can be productive again.

If productivity impact is a concern, then look into deploying a proper highly available solution like an Azure Stack HCI small 2-node appliance that allows for all virtual machine guests to run highly available. If there is a hardware problem, user productivity impact is virtually nil.

UPDATE 2019-11-26: Fellow Microsoft MVP pointed out that the DHCP update account need only have the proper settings and an standard/restricted AD account. Post updated accordingly.

Found this in the process: Configure DNS Dynamic Update Credentials for DHCP with PowerShell

Philip Elder
Microsoft High Availability MVP
MPECS Inc.
www.s2d.rocks !
Our Web Site

Leave a comment

Your email address will not be published.