ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Using non MS DHCP in MS AD

    IT Discussion
    active directory dhcp
    4
    10
    860
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • DashrenderD
      Dashrender
      last edited by

      I'm not ready to get rid of AD just yet, but I'm looking for ways to keep my environment more resilient when AD is down.

      I'm the typical SMB, AD VM that also has DNS/DHCP on the same VM. If this VM goes down today, I lose internet access because DNS is gone. (it's amazing how quick windows clients give up the DNS cache for a site they are still using)

      I have an Ubiquiti USG firewall.

      Goal: not have internet access go down when AD/DNS/DHCP go down.

      As most of us know - when Windows client fail to their secondary DNS, they do not fall back to the primary until there is a failure on the secondary. This prevents us from having the clients being directly aware of an external DNS provider like CloudFlare, because if the primary DNS has a blip, now those clients can't utilize any internal resources until the machine is forced back to the primary DNS.

      1 Reply Last reply Reply Quote 0
      • DashrenderD
        Dashrender
        last edited by

        As a current stop gap I've made the following changes:

        DHCP/DNS are still on the AD server

        DHCP provides DNS Primary (AD Server) secondary (USG)

        USG's DNS is configured Primary (AD Server) secondary (1.1.1.1)

        The expectation here is that the USG will fall back to the priamry as soon as it comes back online, no user intervention required. (need to test to confirm)

        Without testing AD DNS failure situation itself, I have confirmed that a device using the USG as it's DNS will pull DNS from the AD DNS sever as desired.

        This leaves solving DHCP being down on the AD box. My current DHCP lease time is 12 hours. I could easily make this 24 or 48, etc - but let's just plan for the worst, a long outage, so I want to move DHCP as well.

        Does anyone see any issue in moving DHCP to the USG, still having DHCP provide DNS Primary (AD Server) Secondary (USG)? My question is about clients registering themselves with AD DNS. Assuming normal working conditions, I want them registering themselves with DNS.

        1 Reply Last reply Reply Quote 0
        • PhlipElderP
          PhlipElder
          last edited by

          Problem: One network blip and the intranet clients will lose their ability to resolve internal DNS A records for whatever the TTL setting is for them. BTDT

          Public DNS servers do not belong anywhere near your intranet setup.

          I.E. don't have DNS0 192.168.33.5 DC/DNS and DNS1 8.8.8.8 or whatever public DNS server. Bad. Just. Bad.

          There are two ways to solve this that won't cause you grief:

          • Set up as you are but leave DHCP off on the secondary device
          • Set up DHCP Failover via a second DC

          The second option can be licensed via your favourite SPLA provider for very little cost per month over purchasing a full license.

          JaredBuschJ 1 Reply Last reply Reply Quote 0
          • JaredBuschJ
            JaredBusch
            last edited by

            @Dashrender Vyatta (thus USG/EdgeRouter) handles this simply.

            You simply add a DNS forwarding option to your setup.
            I have multiple VPN mesh networks setup like this to prevent a VPN outage from killing all internet.

            First DNS setup (note this is from EdgeRouter, USG will be someplace in the GUI):

            set service dns forwarding cache-size 150
set service dns forwarding listen-on eth3
set service dns forwarding name-server 10.204.20.2 <--- Local Pi-hole but could simply be router
set service dns forwarding name-server 1.1.1.1 <--- Cloudflare
set service dns forwarding options server=/domain.local/10.1.1.4 <-- AD across VPN
set service dns forwarding options server=/domain/10.1.1.4 <-- AD across VPN

            Second the DHCP setup:

            set service dhcp-server shared-network-name SiteB authoritative disable
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 default-router 10.204.20.1
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 dns-server 10.204.20.1 <-- clients look to router not Pi-Hole
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 domain-name domain.local <-- ensures clients have the AD domain suffix in use.
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 lease 86400
            DashrenderD 1 Reply Last reply Reply Quote 3
            • JaredBuschJ
              JaredBusch @PhlipElder
              last edited by

              @PhlipElder said in Using non MS DHCP in MS AD:

              Problem: One network blip and the intranet clients will lose their ability to resolve internal DNS A records for whatever the TTL setting is for them. BTDT

              Completely misguided.
              With the correct design, you can easily have non-windows DHCP and DNS and have zero issues.

              1 Reply Last reply Reply Quote 0
              • 1
                1337
                last edited by

                Stupid question perhaps but are the clients really registering themselves with the DNS? I thought the clients got their IP from the DHCP server and it's the DHCP server that registers the DHCP hostname in DNS.

                DashrenderD 1 Reply Last reply Reply Quote 0
                • DashrenderD
                  Dashrender @JaredBusch
                  last edited by

                  @JaredBusch said in Using non MS DHCP in MS AD:

                  @Dashrender Vyatta (thus USG/EdgeRouter) handles this simply.

                  You simply add a DNS forwarding option to your setup.
                  I have multiple VPN mesh networks setup like this to prevent a VPN outage from killing all internet.

                  First DNS setup (note this is from EdgeRouter, USG will be someplace in the GUI):

                  set service dns forwarding cache-size 150
set service dns forwarding listen-on eth3
set service dns forwarding name-server 10.204.20.2 <--- Local Pi-hole but could simply be router
set service dns forwarding name-server 1.1.1.1 <--- Cloudflare
set service dns forwarding options server=/domain.local/10.1.1.4 <-- AD across VPN
set service dns forwarding options server=/domain/10.1.1.4 <-- AD across VPN

                  Second the DHCP setup:

                  set service dhcp-server shared-network-name SiteB authoritative disable
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 default-router 10.204.20.1
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 dns-server 10.204.20.1 <-- clients look to router not Pi-Hole
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 domain-name domain.local <-- ensures clients have the AD domain suffix in use.
set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 lease 86400

                  yeah, this is close to what I do, except I have my clients talk to my AD DNS first, and the firewall second... the firewall then talks to the AD DNS first, and CloudFlare second...
                  Jared's example gives the clients only one DNS entry - the firewall itself, and it handles all routing to whatever DNS server is actually handling stuff.

                  1 Reply Last reply Reply Quote 0
                  • DashrenderD
                    Dashrender @1337
                    last edited by

                    @Pete-S said in Using non MS DHCP in MS AD:

                    Stupid question perhaps but are the clients really registering themselves with the DNS? I thought the clients got their IP from the DHCP server and it's the DHCP server that registers the DHCP hostname in DNS.

                    This is the real root of the question - if you'll notice the title is about DHCP, not DNS... but I wanted to cover all bases here.

                    But onto registering in DNS - It's my understanding that Windows clients will register on their own, they understand dynamic DNS, so they don't need DHCP to do it for them.

                    Other devices apparently don't understand/care about dynamic DNS, so DHCP can then help those devices register into DNS.

                    Assuming all the above is correct, then my setup where my primary is my AD DNS, then my Windows clients should register without issue - this is also why I need AD's DNS needs to be primary.

                    1 Reply Last reply Reply Quote 0
                    • JaredBuschJ
                      JaredBusch
                      last edited by

                      Setup the way I show, Windows DNS still gets updated form workstations.

                      03b94431-bd00-4eb2-ad58-a26eb0814fd0-image.png

                      DashrenderD 1 Reply Last reply Reply Quote 0
                      • DashrenderD
                        Dashrender @JaredBusch
                        last edited by

                        @JaredBusch said in Using non MS DHCP in MS AD:

                        Setup the way I show, Windows DNS still gets updated form workstations.

                        03b94431-bd00-4eb2-ad58-a26eb0814fd0-image.png

                        Good to know Windows is doing what it's supposed to do!

                        Thanks Jared

                        1 Reply Last reply Reply Quote 0
                        • 1 / 1
                        • First post
                          Last post