trashnet.xyz


Dynamic DNS with FreeIPA/Red Hat IdM & ISC DHCPD

Hey, do you have a DHCP server? Do you use FreeIPA or Red Hat Identity Management (IdM) for DNS? Do you want them to be good friends that love and respect one another? Well READ ON! I’m going to explain the steps necessary to do the following:

  1. Allow ISC DHCPD to update DNS records in IdM
  2. Let other networks use IdM as a recursive DNS server, not just registered hosts

Topology

In this scenario, we’re dealing with two machines:

dhcp.example.com 10.0.7.2
idm.example.com 10.0.7.3

…and a few networks:

Infra Network 10.0.5.0/24 *.infra.example.com
Lab Network 10.0.7.0/24 *.lab.example.com
Home Network 192.168.1.0/24 *.home.example.com

The shared secret

First, SSH to your IdM host. We will use /etc/rndc.key as our shared secret between IdM and DHCPD. In case you don’t have this file, it can be generated by running sudo rndc-confgen -a.

Copy it to the DHCP host as well.

The contents look like this (example):

key "rndc-key" {
	algorithm hmac-sha256;
	secret "bILqFfyKab69jPP8uNRQ15MPVqTOPBF0d/gkW/YruLA=";
};

Configuring IdM

/etc/named/ipa-ext.conf

 acl "trusted_network" {
   localnets;
   localhost;
   /* CIDRs for Infra, Lab, and Home */
   10.0.5.0/24;
   10.0.7.0/24;
   192.168.1.0/24;
 };

include "/etc/rndc.key";

Here we add our Infra, Lab, and Home networks to the “trusted_network” ACL and include our shared secret.

/etc/named/ipa-options-ext.conf

allow-recursion { trusted_network; };

Adding this option allows members of the “trusted_network” ACL to make recursive DNS queries.

Restart IdM with systemctl restart ipa and access the web UI as an admin user.

Web UI

Go to Network Services > DNS > DNS Zones. For each zone and reverse zone, go to its settings tab and make sure

  1. Dynamic update is set to True
  2. BIND update policy includes grant "rndc-key" zonesub ANY;

Configuring DHCPD

/etc/dhcp/dhcpd.conf

ddns-updates on;
ddns-update-style standard;
include "/etc/rndc.key";

zone infra.example.com. {
  primary 10.0.7.3;
  key rndc-key;
}

zone lab.example.com. {
  primary 10.0.7.3;
  key rndc-key;
}

zone home.example.com. {
  primary 10.0.7.3;
  key rndc-key;
}

zone 0.0.10.in-addr.arpa. {
  primary 10.0.7.3;
  key rndc-key;
}

zone 1.168.192.in-addr.arpa. {
  primary 10.0.7.3;
  key rndc-key;
}

This turns on Dynamic DNS updates, includes our shared secret, and defines the zones (including reverse!) that DHCPD will update in IdM.

Now we can define some subnets:

# Infra subnet
# ------------
subnet 10.0.5.0 netmask 255.255.255.0 {
  option domain-name "infra.example.com";
  option routers 10.0.5.1;
  range 10.0.5.100 10.0.5.250;
}

# Lab subnet (no DHCP)
# --------------------
subnet 10.0.7.0 netmask 255.255.255.0 {}

# Home subnet
# -----------
subnet 192.168.1.0 netmask 255.255.255.0 {
  option domain-name "home.example.com";
  option routers 192.168.1.1;
  max-lease-time 14400;

  # default pool
  pool {
    deny members of "iot";
    range 192.168.1.10 192.168.1.199;
  }

  # iot pool
  pool {
    allow members of "iot";
    range 192.168.1.200 192.168.1.250;
    option domain-name-servers 1.1.1.1;
  }
}

And that’s it! DHCPD can securely talk to IdM and make DNS changes thanks to the shared secret and grant on each of the zones. Any machine on our trusted networks can query our IdM DNS server as well, regardless of whether or not it is enrolled as a host.

stephen@trashnet.xyz