PowerDNS Authoritative Server 3.4.8

Hi everybody,

We’re pleased to announce version 3.4.8 of our Authoritative Server.

This is a small bugfix release to 3.4.7. Additionally, the deb/RPM packages on downloads.powerdns.com (those with -static in the name) for 3.4.8 have been built against Botan 1.10.11 instead of Botan 1.10.3 like previous packages. Please see the Botan Security page for more information on the fixes in Botan 1.10.11. As a PowerDNS user, these issues only affect you if you ran our -static packages *and* allowed your users to upload private keys to your configuration.

Tar.gz and packages are available on:

Warning: Version 3.4.8 of the PowerDNS Authoritative Server is a major upgrade if you are coming from 2.9.x. Additionally, if you are coming from any 3.x version (including 3.3.1), there is a mandatory SQL schema upgrade. Please refer to the Upgrade documentation for important information on correct and stable operation, as well as notes on performance and memory use.

Find the downloads on our download page, https://www.powerdns.com/downloads.html

Changes since 3.4.7:

  • commit edfa60a: Use AC_SEARCH_LIBS (Ruben Kerkhof)
  • commit 7b7a3af: Check for inet_aton in libresolv (Ruben Kerkhof)
  • commit 9322aee: Remove hardcoded -lresolv, -lnsl and -lsocket (Ruben Kerkhof)
  • commit 23d26d8: pdnssec: don’t check disabled records (Pieter Lexis)
  • commit ce92ff1: pdnssec: check all records (including disabled ones) only in verbose mode (Kees Monshouwer)
  • commit f745312: traling dot in DNAME content (Kees Monshouwer)
  • commit ed02761: Fix luabackend compilation on FreeBSD i386 (RvdE)
  • commit 07ea6ac: silence g++ 6.0 warnings and error (Kees Monshouwer)
  • commit c6077b1: add gcc 5.3 and 6.0 support to boost.m4 (Kees Monshouwer)

PowerDNS Authoritative: the new old way to manage domains

This is the third post in a series that highlights interesting new features of the PowerDNS 4.x.x and dnsdist 1.x.x releases.

I (Bert) have to admit something. Even though I set out to write a database driven nameserver 16 years ago.. I have never actually liked maintaining domains in a database. Of course, most large scale PowerDNS users have web-interfaces and scripts to provision the database. But out of the box, you could either use the pretty cool ‘BIND’ backend in PowerDNS.. or edit SQL.

Today I’m proud to announce that for the first time I personally enjoy editing my domains with PowerDNS. For completeness, this post will outline the full process of setting up a redundant PowerDNS server setup.

Basic setup (master)

First, install a 4.x.x version of PowerDNS, most easily obtained as packages from our repositories as found on https://repo.powerdns.com/. For this demo, install packages ‘pdns-server’ (‘pdns’ on RHEL/CentOS) and ‘pdns-backend-sqlite3’ (although these examples work just as well for the MySQL, PostgreSQL and ODBC backends).

Next, we need to create a database, in this case sqlite3 :

Then we configure PowerDNS to listen on all IP addresses, and to run with the database we just generated. This file goes in /etc/powerdns/pdns.conf:

We can now start PowerDNS, for example with: service pdns start.

To verify that everything works, run: dig chaos txt version.bind @127.0.0.1 +short

If everything is ok, it will tell you the exact version of PowerDNS you are running (this can of course be disabled).

Up to here, this is how installing PowerDNS Authoritative Server has worked for years.

The new command-line based zone editing features

To create a new domain name, operators typically copy some known good zone file from somewhere, and load that up. We’ve automated this process like this:

These few commands create a well configured zone, and add a new record to it. Finally, the ‘dig’ line verifies that all is good.

We can further edit the zone with pdnsutil edit-zone:

Note how this command actually runs a check on your changes to see if your zone still makes sense, and prompts you to edit some more or start over if it doesn’t look right. This uses the built-in DNS knowledge of PowerDNS, something which was frequently lacking in earlier scripts to update zone contents.

The pdnsutil commands ‘create-zone’, ‘edit-zone’, ‘list-zone’, ‘add-record’, ‘replace-rrset’, ‘remove-rrset’ thus form a complete way to edit a zone safely – since PowerDNS actually checks if what you entered makes DNS sense before committing it to the database.

But wait, there’s more

In the ‘pdnsutil edit-zone’ session above, we added an A record for ns2.powerdns.com, but we did not add an NS record to the zone yet. To do this, execute: pdnsutil add-record example.com @ NS ns2.example.com'.

When that is done, we tell the PowerDNS master server to allow that slave to actually transfer the zone by executing: pdnsutil set-meta example.com ALLOW-AXFR-FROM AUTO-NS. This tells PowerDNS: allow any IP address listed as a nameserver for this domain to transfer it.

Finally, we tell PowerDNS this is a ‘master’ zone for which we should send out out notifications by executing: pdnsutil set-kind example.com master

To verify that it all worked, we use pdnsutil show-zone:

Now we need to install PowerDNS on the slave server, and this is just like for our master, but we add the word ‘slave’ to pdns.conf. Please see above.

Once PowerDNS is installed and setup, we run: pdnsutil create-slave-zone example.com 192.168.1.2, where 192.168.1.2 is the IP address of our master server ns1.powerdns.com.

PowerDNS periodically checks the database for new slave zones, and within a minute it will pick up the new zone:

If you are in a hurry, execute pdns_control retrieve example.com and the zone will be slaved immediately.

Making further changes on the master server

Meanwhile, if we make a change on the master server, we need to bump the SOA serial number to make the DNS master/slave ritual aware of it. Do so either in ‘edit-zone’, or like this: pdnsutil increase-serial example.com. And again, PowerDNS will pick this up shortly and send out notifies. And like on the slave, if you are in a hurry, execute: pdns_control notify example.com.

What about DNSSEC?

All of the above works just as well with DNSSEC. Simply issue pdnsutil secure-zone example.com on the master server, bump the serial number, and inform your registrar of your new DS record (as shown by pdnsutil show-zone example.com).

Takeaway

PowerDNS has always offered classic zonefiles for your editing delight. Most large deployments have used various (web)tools to fill out the database with DNS details. But if like me you like a solid set of command line tools, PowerDNS Authoritative Server 4.x now has you covered!

Per device DNS settings: selective parental control

This is the second post in a series that highlights interesting new features of the PowerDNS 4.x.x and dnsdist 1.x.x releases.

As noted previously, in some organizations it is desirable to filter access to some domains (malware, advertising, ‘adult’ etc) for some users or subscribers. In our previous post we showed how to use common DNS blocking lists to offer adblocking for users of your resolver.

A problemacm however for other kinds of filtering is that subscribers typically share a single IP address among all their devices. This makes it hard to provide ‘parental control’ to the kids’ tablets, but not to other computers in the household.

Now, it would be great if we could do selective filtering based on the device’s MAC address, but this MAC address is not visible from the nameserver. All we see is the MAC address of our router, not that of your devices.

It turns out however that various home routers and cable modems (‘CPEs’) have the option to embed requestor MAC addresses into DNS queries themselves. This allows a service provider to conditionally filter DNS based on this MAC address.

A quick survey discovered that different vendors embed the MAC address or other ‘user identifiers’ differently, and for this reason PowerDNS support for this feature is dynamic.

First, we’ll use dnsdist to embed the MAC address in queries. The natural and universally chosen mechanism for this is an EDNS option, and we can configure dnsdist to add the MAC address like this:

This makes dnsdist listen on port 53 and forward all queries to 127.0.0.1:5300. With the last line, we add the MAC address of the requestor to all queries using EDNS option code point 5 (65001 is also used). We could restrict this to certain IP addresses if we wanted. In a typical setup, this is how dnsdist would run on a subscriber’s CPE.

Next up we need to configure the PowerDNS Recursor with our filtering instructions:

These lines implement a set of bad domains, in this case everything within the TLD “xxx”. Secondly, for two IP addresses we list some MAC addresses that desire filtering. 127.0.0.1 is in this case for the dnsdist configuration listed above.

Now to make use of these filters:

This first defines macPrint() to pretty print the binary encoded MAC address. Secondly, we use the PowerDNS Recursor Lua hook ‘preresolve’ to intercept incoming queries. First we see if there is an embedded MAC address in EDNS option 5, and if there is, we look up if for that IP address, we have that MAC address listed.

 

If so, and the query is part of our ‘baddomains’ list, we return a CNAME to a server which would then inform the user their request got blocked:

The last two lines are from a host with a different MAC address which is not filtered.

Takeaway

With the configuration outlined above, it is easily possible to provide per-device DNS filtering instructions. As shown, this configuration is not very dynamic. PowerDNS however has multiple ways to retrieve such filtering instructions, either from remote servers or from local indexed files.

And please do not hesitate to contact us if you need help integrating PowerDNS with your existing customer database or CPE deployed base!

Enjoy!

Efficient & optional filtering of domains in Recursor 4.0.0

As we gear up for the release of PowerDNS Recursor 4.0.0, we are doing a series of posts describing new cool features which you can try out today. Many deployments are already running with 4.x alphas or snapshots, and now is a great time to familiarize yourself with the new and upcoming possibilities.

In this post, we’ll explain how to efficiently use the PowerDNS Recursor to optionally block certain domains for some or all of your users. This could be to stop users being tracked, to block advertisements or to protect against malware. The simple scripts below scale to millions of domain names and millions of users, all with acceptable startup times (seconds).

It starts with getting a good data set, and the good people from Mozilla have us covered here. The Mozilla Focus project through their partner Disconnect have a list of trackers and advertising servers which we can retrieve like this:

(Note, the actual Focus project performs blocking more cleverly than can be achieved purely with DNS. Focus also takes into account the URL of the page containing the advertisement).

To make these lists usable by PowerDNS, we need a little bit of conversion using the most excellent ‘jq’ tool:

This delivers a file which looks like ‘return{“a.com”, “b.com”, “c.com”}’, which is how to rapidly import data into Lua. To also block trackers, rerun this script for ‘disconnect-analytics.json’ and store as ‘trackers.lua’.

Next up, we use a small script ‘adblock.lua’ to tell PowerDNS to use this list to deny the existence of the filtered domains:

Finally, put ‘lua-dns-script=adblock.lua’ in recursor.conf to tell PowerDNS to load this list. And for the basic functionality, we are done! A few words about the script. With ‘newDS()’ we defined a new Domain Set.  In the second line, we load the list of advertisement related domain names.

Next we define the function preresolve() which gets called by PowerDNS to determine what to do with a domain. If we see that a query name is not part of one of the advertisement domains, or the query is not for an IP(v6) address, we return false and the normal resolution process continues.

Otherwise if it is a domain to be blocked, we insert a SOA record that says “this domain name exists, but the type you queried for doesn’t”.

Making it optional

Not everyone will want their advertisements filtered like this. And some people just want to be tracked online. To make this optional, first we make a list of IP addresses that want their DNS to be filtered:

This delivers a file with around 650000 IP addresses, which we can import in under a second in our Lua script like this:

New line number 13 informs PowerDNS that this domain name will have variable responses depending on who asks. The following new lines check if this user wants to be filtered or not.

This script can easily be expanded to have different lists for users that want advertising or perhaps only trackers to be blocked.

Finally, to reload the script with new data, issue ‘rec_control reload-lua-script’.

Take away

Using the elementary scripts shown above, we can optionally provide very large userbases with optional advertisement or tracker filtering. To learn more about the PowerDNS Recursor dynamic abilities, head to the documentation, where you can also find how to retrieve user and domain status in real time from external servers.

Open Source Support: out in the open

As an Open Source project, PowerDNS works hard to support its users and customers. We also love to work with our collaborators, our community, on projects inside and outside of PowerDNS. This way we’ve contributed to the development of ExaBGP, Luawrapper, Botan, incbin, MbedTLS, Unbound, NSD, BIND, OSX Homebrew, Ansible, buildbot and many other projects we depend on or interoperate with. We also work closely with our downstream distributors (such as Debian and Fedora) to make sure their needs are covered.

If you are a PowerDNS user and you have a question or a problem we’ll gladly help you with that. If there is a bug in PowerDNS, or a ‘surprising feature’, we’ll fix it for you, thus improving the product. In this way, the community contributes to QA and product management of PowerDNS. For this we are grateful.

Meanwhile, we also get a lot of people that simply need help with PowerDNS. There likely is no bug, the features work as intended, the documentation is there. But still PowerDNS does not do what the user wants it to do.

In such cases too, we and the PowerDNS community provide support for our products. And in fact, we should not forget how special that is. Free software with free support!

One thing we don’t offer however: free private support. By providing support in the open, other people can learn, search engines pick up our answers, the community can pitch in with solutions or suggestions. Doing free support this way provides a true public benefit.

Another reason is that PowerDNS needs to live and thrive. As noted before, it takes money to develop quality products. PowerDNS and the PowerDNS Certified Consultants can also help you privately as part of a PowerDNS support agreement, and this is how we pay the rent & our employees.

If you want to be part of the PowerDNS community and get free support from us and that community.. with only a few exceptions everything we need to know to help you needs to be out and in the open.

If you have a domain that does not resolve, we need the actual name of that domain. Not ‘example.com’. If we cannot query your nameservers because you won’t tell us their IP address, we can’t help you. If you wrote a custom script that does not do what you want, but you can’t post that script to the mailing list because it is proprietary, we cannot help you. And in fact we do not want to help you for the reasons outlined above.

(By the way, if you can’t get PowerDNS to compile, or can’t find out which package to install, there is of course no need to tell us your domain name or IP address etc. This post is about the things we need to know to solve your issue).

Here are three things you can do if you or your organization can’t post sufficient details of the issue on our mailing lists or on IRC or on our ticketing system:

Reproduce your problem using details you CAN share

Reproduce your issue with things you CAN publish online. So for example, minimize your problematic script so it still displays your issue, but you feel comfortable posting it to the mailing list. On Stack Overflow, this is known as a “Minimal, Complete, and Verifiable example” and helps us (and others) to quickly determine the cause of the issue.

If your issue affects ‘bigbank.com’ and you want to keep that secret, see if you can reproduce it with ‘mytestdomain.com’. Similarly, if you can’t post the IP address of your servers, rent a small VPS, reproduce the issue there and share that.

Be a contributing member of the PowerDNS community

We realize such reproduction as required above is a burden. So let’s say you or your company have contributed patches, worked on issues, helped improve the documentation etc, work on a project we depend on, we are likely to treat you as a customer and provide support even though you supplied some details privately.

Become a customer

As noted above, we are an actual company in the business of providing support for our software. If your company has a policy of not posting to mailing lists, know that many of the largest telecommunications companies and hosters in the world are already among our customers. More information is on https://www.powerdns.com/support.html.

Take away

PowerDNS provides free support for its free products.. out in the open. If you cannot share sufficient detail of your issue on our mailing lists, IRC or ticketing system, you will need to reproduce the problem using data you can share. If you’ve worked on PowerDNS in some way, we can help you more privately. Alternatively, consider becoming a customer.

Thanks!

2015 in numbers

While the close of 2015 nears, we want to share some geeky stats over the past year.

Let’s start with the company: number of new employees: 2. And the number of companies PowerDNS merged with: 1!

As for the software itself, there were a total of 15 releases made this year for both the Authoritative Server and the Recursor. We published 3 security announcements (sorry about those) and were issued 4 CVE numbers. Sorry for that.

When looking at the code in our master branch, there were a total of 47 code contributors that contributed, excluding merges, 1957 commits (almost 5.5 commits per day) for a total diffstat of 1691 files changed, 151221 insertions(+), 121397 deletions(-). These numbers don’t tell the whole story, if we take the cumulative changes for all non-merge commits, 794,505 lines were inserted and 711,244 were deleted.

The top code contributors from non-employees, also (gratefully) known as “the usual suspects” :

  • Aki Tuomi (309 commits / 7,104 ++ / 3,302 –)
  • Kees Monshouwer (144 commits / 126,954 ++ / 124,314 –)
  • Ruben Kerkhof (99 commits / 90,287 ++ / 89,844 –)
  • Christian Hofstaedtler (75 commits / 1,750 ++ / 1,277 –)

Aki by the way joins our sister-company Dovecot at the start of the new year!

It also appears that all PowerDNS contributors hardly sleep, here are the hours of the day where no code was commited:

  • Sunday 3:00-6:00
  • Monday 2:00-3:00
  • Tuesday 3:00-5:00
  • Wednesday None
  • Thursday 2:00 4:00
  • Friday None
  • Saturday 3:00 – 5:00

All of us at PowerDNS wish you a good 2016!

Technical Preview Releases of Authoritative Server, Recursor and dnsdist

Hi everybody!

As recently announced, we have finished the great PowerDNS 4.x Spring Cleaning. And it was indeed kind of grand. We consciously set out to fix many things that had been waiting for years to be addressed. We took the liberty to change many things that we could not change (break) within 3.x.  However, it was breaking for the better.

As noted in our previous post, we are very grateful to our community, users, developers and customers that we were able to devote significant time to cleaning up past mistakes. This is very rare in the world of software. Additionally, as usual a specific shout-out to Aki Tuomi (these days working for our sister-company Dovecot), our certified consultants Kees Monshouwer, Christian Hofstaedtler and Jan-Piet Mens, our independent code-contributors Ruben Kerkhof, Ruben d’Arco, Mark Zealey, Pavel Boldin, Mark Schouten and all the others who contributed ideas, code and GitHub issues.

With this message, we bring good news and bad news just in time for our holidays. We promised 4.0 releases of PowerDNS Recursor, PowerDNS Authoritative and even a 1.0 release of dnsdist, in “December 2015”. The bad news is that we did not make it. The good news however is that we do have a set of Technology Preview releases that contain everything that 4.0 will.

In other words: the features are done, but we can’t yet sign off on the quality. However! Since most people won’t be deploying x.0 releases in December anyhow, we felt it was worthwhile to launch the 4.x series now with a strong technology preview. This preview will allow you to test our features, both to see if they work and to see if they actually fit in with your needs. And please do test, since that will speed up the advent of the actual 4.x release date!

In terms of roadmap, we consulted PowerDNS customers, community and developers, and out came a plan for 4.x. A few months into the development, various users and customers suddenly chimed in on absolutely mandatory features we had somehow missed. Because of that, 4.x both under- and overdelivers.

In addition to the huge internal cleanup, here are visible changes that did make it:

dnsdist

  • Fully-featured load balancer with a number of DNS-relevant load balancing policies. The default policy favours servers with the least amount of queries in flight and the fastest response times. This turns out to deliver tangible user experience improvements
  • Comes with a host of rules to block, change, or redirect traffic based on your needs. For example, use dnsdist to implement ‘views’, or what has been called ‘Advanced DNS Protection’ by some closed source resellers of open source.
  • dnscrypt, EDNS Client Subnet adding (for CG-NAT traversal, for example)
  • Realtime insights via HTTP/JSON/RESTful API & built-in live graphing website
  • For more about this new product, please see http://dnsdist.org/

Authoritative

  • GeoIP backend has gained many features, and can now run based on explicit netmasks not present in the GeoIP databases
  • Caches are now fully canonically ordered, which means entries can be wiped on suffix in all places
  • Old geobackend has been deprecated and is no longer part of PowerDNS
  • Newly revived ODBC backend for talking to Microsoft SQL Server & Azure, and with some tweaking, any other ODBC-database we do not support natively.
  • pdnssec tool does far more than DNSSEC, and has thus been renamed into ‘pdnsutil’.
  • ECDSA signing is now supported without external dependencies, and a single combined ECDSA signing key is the new default for securing zones.
  • Experimental ed25519 signing support based on draft-sury-dnskey-ed25519-03.

Recursor

  • DNSSEC processing: if you ask for DNSSEC records, you will get them
  • DNSSEC validation: if so configured, PowerDNS will attempt to perform DNSSEC validation of your answers
  • Completely revamped Lua scripting API that is “DNSName” native and therefore far less error prone, and likely faster for most commonly used scenarios. Loads and indexes a 1 million domain custom policy list in a few seconds
  • New asynchronous per-domain, per-ip address, query engine. This allows PowerDNS to consult an external service in realtime to determine client or domain status. This could for example mean looking up actual customer identity from a DHCP server based on IP address (option 82 for example).
  • RPZ (from file, over AXFR or IXFR) support. This loads the largest Spamhaus zone in 5 seconds on our hardware, containing around 2 million instructions.
  • All caches can now be wiped on suffixes, because of canonical ordering
  • Many many more relevant performance metrics, including upstream authoritative performance measurements (‘is it me or the network that is slow’)
  • EDNS Client Subnet support, including cache awareness of subnet-varying answers

More technical details are available in the changelog.

Finally – the big question is of course: when will the actual 4.0.0 releases (and 1.0 for dnsdist) happen. The answer is that all this depends on what you find out during testing. We may be closer or further from the goal. As of now we can’t tell. We will report back to you in January to let you know when we expect to be able to do a release that meets our standards. But the more you test, the sooner this will be!

You can download tarballs:

Packages for several distributions are available from our repositories.

Once again, thank you everyone for working with us on this release. Happy holidays and a splendid new year!

The PowerDNS development & automation team:  Peter, PieterRemi (and Bert, who spent this release week on a sunny island, and not helping much!).