Dynamic DNS update PowerDNS in-depth tutorial by the experts at Bobcares.
At Bobcares, we come up with solutions for every query, big and small, as a part of our Server Management Service.
Let’s dive in and learn all about dynamic DNS update for PowerDNS from our skilled Support Techs!
All about Dynamic DNS update PowerDNS
DNS update support is available since PowerDNS Authoritative Server 3.4.0. However, our Support Engineers would like to point out that there is no support for GIS*TSIG and SIG.
In order to implement the new update, we have to ensure the backend supports several new operations. Presently, the DNS update is supported by
-
- gmysql
- gsqlite3
- gpsql
- godbc
Dynamic DNS update PowerDNS : Configuration options
We can use the following configuration parameters within the PowerDNS configuration file as seen below:
- dnsupdate:
We can use this setting to enable or disable DNS update support. While the default is set to no, we can change the setting to dnsupdate=yes and enable DNS update support if required. - allow-dnsupdate-from:
We use this configuration option to set a list of IP ranges that have permission to perform updates on any domain.Since 127.0.0.0/8 is the default value, all loopback addresses are accepted. We can also use multiple entries in this configuration option as seen below:
allow-dnsupdate-from=198.51.100.0/8 203.0.113.2/32
If we leave the value empty, everything is disallowed. In this scenario, we have to use it along with ALLOW-DNSUPDATE-FROM domain metadata setting per zone.
Furthermore, we can set a range here as well as in ALLOW-DNSUPDATE-FROM to enable updates from any of the two address ranges.
- forward-dnsupdate:
This option informs PowerDNS to forward to the master server in case the zone is configured as a slave. The default setting is “yes”. In other words, it will try to forward.If an update packet is being processed, TSIG-ALLOW-DNSUPDATE and allow-dnsupdate-from are processed first. In this scenario, these permissions come in effect before forward-dnsupdate.
- lua-dnsupdate-policy-script:
We can use this script with function updatepolicy in order to validate each update. Furthermore, it will TURN OFF all other authorization methods and we have to take care of everything manually.
According to our Support Engineers, a dynamic update is allowed by a per-zone ALLOW-DNSUPDATE-FROM metadata setting or the global allow-dnsupdate-from setting.
Moreover, if the zone includes a TSIG-ALLOW-DNSUPDATE metadata setting, it has to match as well.
Dynamic DNS update PowerDNS: Per zone settings
-
- ALLOW-DNSUPDATE-FROM
This per zone setting offers the same function as described earlier in the configuration options. For instance, it allows 203.0.113.2/32 and 198.51.100.0/8 to send DNS messages for example.org domain as seen below:pdnsutil set-meta example.org ALLOW-DNSUPDATE-FROM 198.51.100.0/8 203.0.113.2/32
- TSIG-ALLOW-DNSUPDATE
This per zone setting permits us to set the TSIG key, which in turn is required for a DNS update. In case GSS-TSIG is enabled, we can also use Kerberos prinicpals.For instance, here we use pdnsutil to create the key as seen below:
$ pdnsutil generate-tsig-key test hmac-md5 Create new TSIG key test hmac-md5 kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=
After that, we can add the key with the name test and also add the metadata as seen here:
pdnsutil import-tsig-key test hmac-md5 'kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=' pdnsutil set-meta example.org TSIG-ALLOW-DNSUPDATE test
According to our Support Engineers, we have to allow the IP( or IP range) of the updater via ALLOW-DNSUPDATE-FROM if TSIG key and ALLOW-DNSUPDATE-FROM is set.
- FORWARD-DNSUPDATE
- ALLOW-DNSUPDATE-FROM
It enables forwarding as mentioned earlier in the Configuration options. For instance:
pdnsutil set-meta example.org FORWARD-DNSUPDATE 'yes'
This setting allows forwarding, even if it has an empty value. In fact, this domain-specific setting is only handy when the configuration option by the same name is set to ‘no’. In this scenario, it will disable it globally. We can use the domainmetadata setting to enable it per domain.
- NOTIFY-DNSUPDATE
- We can use this setting to send a notification to each slave server after every update. It speeds up the process and is also handy for acme verification as seen below:
pdnsutil set-meta example.org NOTIFY-DNSUPDATE 1
- SOA-EDIT-DNSUPDATE
This setting indicates how the SOA serial has to be updated. We will take a closer look at this in the upcoming section.
Dynamic DNS update powerDNS: SOA Serial Updates
Did you know that the SOA serial is updated after every update? Well. This is a requirement as per section 3.7 of RFC 2136. We can do this via SOA-EDIT-DNSUPDATE option in domainmetadata. Furthermore, it has several options as seen below. In case we do not specify a behavior setting, the default value, DEFAULT comes into play.
SOA-EDIT-DNSUPDATE settings
Let’s take a look at the various settings available for SOA-EDIT-DNSUPDATE:
- DEFAULT:
It generates an SOA serial (YYYYMMDD01). In case the current serial is lower, it will use the generated serial. In case the current serial is equal or higher, it increases the current serial by 1. - INCREASE:
It increases the current serial by 1. - EPOCH:
It changes the SOA serial to the number of seconds passed since EPOCH (unixtime). - SOA-EDIT:
It changes the serial to what SOA-EDIT provides. - SOA-EDIT-INCREASE:
It changes the serial to what SOA-EDIT provides. If this is lower than the current SOA serial, later is increased by 1. However, if SOA-EDIT=INCEPTION-EPOCH, the SOA serial is changed at least 4 times the current EPOCH time.
Dynamic DNS update powerDNS: Setup dyndns/rfc2136 with dhcpd
The DNS update works with DHCP to offer a hostname automatically when a new IP address gets assigned by the DHCP server. Let’s take a look at how to set up PowerDNS in order to receive DNS updates via ISC’s dhcpd.
Setting up dhcpd
Here, we will use a TSIG key for security. First, we will generate the key with this command:
dnssec-keygen -a hmac-md5 -b 128 -n USER dhcpdupdate>/pre>
This results in the generation of two files, Kdhcpdupdate.*.key and Kdhcpdupdate.*.private.
# ls -l Kdhcp* -rw------- 1 root root 53 Aug 26 19:29 Kdhcpdupdate.+157+20493.key -rw------- 1 root root 165 Aug 26 19:29 Kdhcpdupdate.+157+20493.private # cat Kdhcpdupdate.+157+20493.key dhcpdupdate. IN KEY 0 3 157 FyhvwsW1ZtFZqWzsMpqhbg==
Here, we are going to pay more attention to the name of the key as well as the hash of the key.
We will use the details of the newly generated key and add them to the dhcpd.conf as seen below:
key "dhcpdupdate" { algorithm hmac-md5; secret "FYhvwsW1ZtFZqWzsMpqhbg=="; };
Next, we will inform dhcpd about our desire for the dynamic DNS to work with the help of this section:
ddns-updates on; ddns-update-style interim; update-static-leases on;
In other words, this section conveys the following to dhcpd:
- First, enable Dynamic DNS.
- Then, indicate the style to be used.
- After that, it updates static leases.
Furthermore, we also have to inform dhcpd about the domain to be updated and which master domain server it is running for each subnet.
ddns-domainname "example.org"; ddns-rev-domainname "in-addr.arpa."; zone example.org { primary 127.0.0.1; key dhcpdupdate; } zone 1.168.192.in-addr.arpa. { primary 127.0.0.1; key dhcpdupdate; }
In fact, this conveys the following to dhcpd:
- The domain to use
- The reverse-domain to sue
- The location of the primary master for the zones.
- The TSIG key to use
Setting up PowerDNS
Next up we have to make a couple of changes to PowerDNS to ensure it accepts the dynamic updates from dhcpd.
According to RFC 2136, the enabled DNS update supports PowerDNS functionality by adding this to pdns.conf( PowerDNS configuration file:
dnsupdate=yes allow-dnsupdate-from=
As a result, the PowerDNS will:
- Enable DNS update support.
- Allow updates from NO IP-address. This is done via ”allow-dnsupdate-from=”.
Here we have informed PowerDNS that we will not accept any updates from anybody via allow-dnsupdate-from parameter. Thereby, we will have to offer permission per zone through the domainmetadata table as seen below.
pdnsutil set-meta example.org ALLOW-DNSUPDATE-FROM 127.0.0.1 pdnsutil set-meta 1.168.192.in-addr.arpa ALLOW-DNSUPDATE-FROM 127.0.0.1
The above example shows how we are giving the 127.0.0.1 IP address access to send update messages. Our Support Engineers would like to remind you to use the IP address of the machine that is running dhcpd here.
Furthermore, we have to add TSIG security via the domainmetadata table as seen below:
pdnsutil import-tsig-key dhcpdupdate hmac-md5 FYhvwsW1ZtFZqWzsMpqhbg== pdnsutil set-meta example.org TSIG-ALLOW-DNSUPDATE dhcpdupdate pdnsutil set-meta 1.168.192.in-addr.arpa TSIG-ALLOW-DNSUPDATE dhcpdupdate
This results in:
- Adding the ‘dhcpdupdate’ key to the PowerDNS installation.
- Aligning the domains with the given TSIG key.
- Finally restarting PowerDNS.
Dynamic DNS update PowerDNS: How it works
Let’s take a look at how PowerDNS processes DNS update messages:
- The DNS update indication is received. In case TSIG is signed, it is validated against the tsigkeys table. If not, it is refused and returned to the sender.
- It checks to see whether the zone is valid. It returns ServFail if not valid.
- The PowerDNS checks the dnsupdate setting.
- PowerDNS checks for update policy Lua script. Skip to step 7 if the script is included.
- It checks the value of ALLOW-DNSUPDATE-FROM. If values do not match with the ones from the requester, it returns Refused.
- It checks if TSIG is signed and then compares it with the TSIG keyname value in domainmetadata.
- It queries backends to find the backend of the given domain.
- In case the domain is a slave domain, PowerDNS checks domainmetadata settings and the forward-dnsupdate option. In case forwarding is enabled, PowerDNS forwards the message to the master. If this fails, it tries the next master and continues till all the masters are tied. In case all masters fail, it returns ServFail. However, it returns the result from the master in case a master succeeds.
- It checks to ensure all the prerequisites and updates for the given zone are in place. If not, it returns NotZone.
- It starts the transaction with the backend.
- It starts prerequisite checks as per section 3.2 of RFC 2136. If a check fails, it returns the corresponding RCode and stops processing.
- It performs prescan checks as per the record in the update message. If this fails, it returns Rcode. If not, it performs the actual operation.
- It updates SOA serial if the SOA record is not modified even though records are updated.
- It commits the transaction with the backend. If this fails, it returns ServFail.
- It returns NoError.
Dynamic DNS update PowerDNS: Update Policy
We can define a Lua script to deal with the DNS UPDATE message authorization. The script has to contain the updatepolicy function, which accepts one parameter. In turn, the parameter is an object that contains all the information for this specific request.
In order to allow change, it returns true, else false. Moreover, the script is called at a time for each record. We can reject or approve any or all. Here are the methods available in the object:
- DNSName getZoneName() – zone name
- DNSName getQName() – name to update
- ComboAddress getLocal() – local socket address
- int getQType() – record type, it can be 255(ANY) for delete.
- ComboAddress getRemote() – remote socket address
- DNSName getTsigName() – TSIG key name
- Netmask getRealRemote() – real remote address (or netmask for EDNS Subnet)
- string getPeerPrincipal() – Return peer principal name (For instance: user@DOMAIN, service/machine.name@DOMAIN, host/MACHINE$@DOMAIN)
Furthermore, resolve(qname, qtype) returns an array of records as seen below:
resolve("www.google.com", pdns.A)
We can use this for DNS lookups. Unfortunately, in case the resolver cannot locate the local records., this function will not help either.
For instance, here is a script example:
function strpos (haystack, needle, offset) local pattern = string.format("(%s)", needle) local i = string.find (haystack, pattern, (offset or 0)) return (i ~= nil and i or false) end function updatepolicy(input) princ = input:getPeerPrincipal() if princ == "" then return false end if princ == "admin@DOMAIN" or input:getRemote():toString() == "192.168.1.1" then return true end if (input:getQType() == pdns.A or input:getQType() == pdns.AAAA) and princ:sub(5,5) == '/' and strpos(princ, "@", 0) ~= false then i = strpos(princ, "@", 0) if princ:sub(i) ~= "@DOMAIN" then return false end hostname = princ:sub(6, i-1) if input:getQName():toString() == hostname .. "." or input:getQName():toString() == hostname .. "." .. input:getZoneName():toString() then return true end end return false end
[Need further assistance? Have no fear! We are just a click away.]
Conclusion
In conclusion, this in-depth tutorial about dynamic DNS update PowerDNS by the proficient Support Engineers at Bobcares makes it easy to understand the process.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
0 Comments