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:
- Allow ISC DHCPD to update DNS records in IdM
- 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
- Dynamic update is set to True
- 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.