25% off on first invoice for all services*

SPRING SALE

Use coupon

*Offer valid for new customers only

25% off on first invoice for all services*

SPRING SALE

Use coupon

*Offer valid for new customers only

Need help?

Our experts have had an average response time of 11.43 minutes in March 2024 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

Dynamic DNS update PowerDNS Tutorial

by | Nov 5, 2021

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

    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:

  1. First, enable Dynamic DNS.
  2. Then, indicate the style to be used.
  3. 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:

  1. The domain to use
  2. The reverse-domain to sue
  3. The location of the primary master for the zones.
  4. 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:

  1. Adding the ‘dhcpdupdate’ key to the PowerDNS installation.
  2. Aligning the domains with the given TSIG key.
  3. Finally restarting PowerDNS.

Dynamic DNS update PowerDNS: How it works

Let’s take a look at how PowerDNS processes DNS update messages:

  1. 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.
  2. It checks to see whether the zone is valid. It returns ServFail if not valid.
  3. The PowerDNS checks the dnsupdate setting.
  4. PowerDNS checks for update policy Lua script. Skip to step 7 if the script is included.
  5. It checks the value of ALLOW-DNSUPDATE-FROM. If values do not match with the ones from the requester, it returns Refused.
  6. It checks if TSIG is signed and then compares it with the TSIG keyname value in domainmetadata.
  7. It queries backends to find the backend of the given domain.
  8. 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.
  9. It checks to ensure all the prerequisites and updates for the given zone are in place. If not, it returns NotZone.
  10. It starts the transaction with the backend.
  11. It starts prerequisite checks as per section 3.2 of RFC 2136. If a check fails, it returns the corresponding RCode and stops processing.
  12. 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.
  13. It updates SOA serial if the SOA record is not modified even though records are updated.
  14. It commits the transaction with the backend. If this fails, it returns ServFail.
  15. 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.

GET STARTED

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF