PowerDNS end of year post: Thank you!

Greetings!

2017 has been a great year for PowerDNS and Open-Xchange. In this post, we want to thank everyone that contributed, and highlight some specific things we are happy about.

HackerOne bug bounty program

After some initial problems with over-reporting of non-issues, our experience with HackerOne is awesome right now. We are very happy we have a clean process for receiving and rewarding security bugs. Various PowerDNS security releases this year have originated as HackerOne reports.

Our community

PowerDNS continues to be a vibrant community. Our IRC channel has around 240 members, our mailing lists have 1225 subscribers. Even though we are now tougher in enforcing our ‘support, out in the open‘ policies, we continue to see many user queries being resolved every day, often leading to improvements in PowerDNS.

As in earlier years, 2017 has seen huge contributions from the community, not only in terms of small patches or constructive bug reports, but also in the revamping of whole subsystems. Specifically Kees Monshouwer was so important for Authoritative Server 4.1 that we would not have been able to do it without him. We hope to continue as a healthy community in 2018!

Facebook bug bounty program

Image result

PowerDNS is an active participant in keeping the internet secure. As part of our work we found a potential security problem in an important Facebook product which we reported to the their bug bounty program.  The bug was fixed quickly, and led to an award of $1500, with the option to turn that into a $3000 charitable donation. We have done so and supported Doctors without Borders in their work.

Our Open Source DNS friends

The DNS community is tight, and it has to be: all our software has to interoperate. New standards are developed cooperatively and problems are discussed together. We love the friendly competition that we have with our friends of CZNIC (Knot, Knot Resolver), ISC (BIND), NLNetLabs (NSD, Unbound, libraries) and others.

To a huge extent, DNS is exclusively Open Source software, sometimes repackaged and rebadged by commercial companies that close down that Open Source software again.

PowerDNS is proud to be part of the open DNS community, and we are grateful for the smooth & fun cooperation we experienced in 2017!

 

Open-Xchange

Since 2015, PowerDNS has been part of Open-Xchange, previously mostly known for the OX AppSuite email platform. The famous Dovecot IMAP project also joined Open-Xchange in 2015. The goal of these mergers was to allow us to focus on technology, while getting the legal, sales and marketing support to get our software out there.

In 2017 we have truly started to harvest the fruits of the merger, by simultaneously delivering important software releases as well as satisfying the needs of some very large new deployments.

We are very happy that PowerDNS not only survived the merger, but is now an important part of Open-Xchange, where we contribute to the mission of keeping the internet open.

Our users

Even without or before contributing code, operators can improve PowerDNS through great bug reports. We specifically want to thank Quad9 (a collaboration of Packet Clearing House, IBM and the Global Cyber Alliance) for taking a year long journey with us with dnsdist and Recursor “straight from GitHub”. Deployments sharing their experiences and problems with the PowerDNS community are vital to creating quality reliable software. Thanks!

Mattermost, the Open Source private Slack Alternative

As PowerDNS grows, we could no longer rely solely on IRC as our communication channel with developers, users and customers. Instead of moving to a third party cloud service that admits to datamining communications, we are very happy to host our own Mattermost instance. And because of PowerDNS user & contributor @42Wim, we can continue our IRC habit with matterircd.

4.1 evolution, dnsdist

In 2016 we released the 4.0 versions of the PowerDNS Authoritative Server and Recursor. As you may recall, the 4.0 releases represented a giant cleanup from the decade old frameworks found in 3.x. The 4.0 versions were a step ahead in functionality and sometimes performance, but the true gains of the new fresher codebase have now been realized in the 4.1 releases.

4.1 represents a big overhaul in caching (both Recursor and Authoritative) and DNSSEC processing (mostly Recursor). Both of these overhauls have been tested over the year by large PowerDNS deployments, and the huge amount of feedback has delivered a near flawless “battle tested” 4.1 release.

Specifically xs4all and two huge European incumbent operators have been instrumental in maturing dnsdist and our 4.1-era DNSSEC and EDNS Client Subnet implementations.

On to 2018!

In 2018 we hope to continue to improve our software and the state of the internet. See you there!

 

PowerDNS Authoritative: Lua Records

Hi everyone,

We are happy to share a new development with you, one that we hinted at over a year ago: Lua resource records. In this post, we ask for your help: did we get the feature right? Are we missing important things? The goal is to release Lua records in January 2018, but we can only make that with your testing and feedback! At the end of this post you will find exact instructions how to test the new LUA records.

Note: The fine authors of the Lua programming language insist that it is Lua and not LUA. Lua means ‘moon’ in Portuguese, and it is not an abbreviation. Sadly, it is DNS convention for record types to be all uppercase. Sorry.

While PowerDNS ships with a powerful geographical backend (geoip), there was a demand for more broader solutions that include uptime monitoring, which in addition could run from existing zones.

After several trials, we have settled on “LUA” resource records, which look like this:

 @   IN   LUA   A   "ifportup(443, {'52.48.64.3', '45.55.10.200'})"

When inserted in a zone with LUA records enabled, any lookups for your domain name will now return one of the listed IP addresses that listens on port 443. If one is down, only the other gets returned. If both are down, both get returned.

But if both are up, wouldn’t it be great if we could return the ‘best’ IP address for that client? Say no more:

@    IN   LUA A ( "ifportup(443, {'52.48.64.3', '45.55.10.200'}, "
                  "{selector='closest'})                          ")

This will pick the IP address closest to that of the client, according to the MaxMind database as loaded in the geoip backend. This of course also takes the EDNS Client Subnet option into account if present.

But why stop there? Merely checking if a port is open may not be enough, so how about:

@ IN LUA A ( "ifurlup('https://powerdns.com/' ,                    "
             "{'52.48.64.3', '45.55.10.200'}, {selector='closest', "
             "stringmatch='founded in the late 1990s'})            ")

This will check if the IP addresses listed actually want to serve the powerdns.com website for us, and if the content served lists a string that should be there.

The ‘closest’ selector relies on third party data, and if you are a large access provider, you may have more precise ideas where your users should go. There are various ways of doing that. One way goes like this:

www IN LUA CNAME (";if(netmask('130.161.0.0/16', '213.244.0.0/24')" 
                  "then return 'local.powerdns.com' else          "
                  "return 'generic.powerdns.com' end              ")
local IN LUA A    "ifportup(443, {'192.0.2.1', '192.0.2.2'}       "
generic IN LUA A ("ifportup(443, {'192.0.2.1', '192.0.2.2',       " 
                  "'198.51.100.1'}, {selector='closest'}          ")

Note: the starting semicolon tells the Lua record that this is a multi-statement record that does not directly return record content. More specifically, PowerDNS will prepend “return ” to your statement normally.

Another way which works without CNAMEs, and thus at the apex, goes like this:

@ IN LUA A (";if(netmask('130.161.0.0/16', '213.244.0.0/24')      " 
            "then return ifportup(443, {'192.0.2.1', '192.0.2.2'})"
            "else return ifportup(443, {'192.0.2.1', '192.0.2.2'},"
            "'198.51.100.1'}, {selector='closest'}                ")

Doing dynamic responses at apex level is a common problem of other GSLB solutions.

To steer based on AS numbers, use if(asnum{286,1136}), for example. Countries can be selected based on their two-letter ISO code using if(country{‘BE’,’NL’,’LU’}).

In the examples above we have been typing the same IP addresses a lot. To make this easier, other records can be included to define variables:

config    IN    LUA    LUA (";settings={stringmatch='Programming in Lua'} "
                            "EUips={'192.0.2.1', '192.0.2.2'}             "
                            "USAips={'198.51.100.1'}                      ")

www       IN    LUA    CNAME ( ";if(continent('EU')) then return 'west.powerdns.org' "
                               "else return 'usa.powerdns.org' end" )

usa       IN    LUA    A    ( ";include('config')                              "
                              "return ifurlup('https://www.lua.org/',        "
                              "{USAips, EUips}, settings)                    " )

west      IN    LUA    A    ( ";include('config')                              "
                              "return ifurlup('https://www.lua.org/',        "
                              "{EUips, USAips}, settings)                    " )

This shows off another feature of ifurlup, it knows about IP groups, where it prefers to give an answer from the first set of IP addresses, and if all of those are down, it tries the second set etc etc. In this example, the ‘local’ set of IP addresses is listed first for both regions.

More possibilities

We use LUA records to power our ‘lua.powerdns.org’, ‘v4.powerdns.org’ and ‘v6.powerdns.org’ zones:

$ dig -t aaaa whoami.v6.powerdns.org +short
2a02:a440:b085:1:20d:b9ff:fe3f:8018
$ dig -t txt whoami-ecs.v6.powerdns.org +short @8.8.8.8
"ip: 2a00:1450:4013:c02::10a, netmask: 86.82.68.0/24"
$ dig -t loc latlon.v4.powerdns.org +short
51 37 15.236 N 5 26 31.920 E 0.00m 1m 10000m 10m
$ dig -t txt whoami.lua.powerdns.org +short
"2a02:a440:b085:1:20d:b9ff:fe3f:8018"

These queries deliver, respectively:

  • IPv6 address of your resolver (will not resolve without IPv6)
  • Any EDNS Client Subnet details over IPv6 (also works on v4.powerdns.org)
  • LOC record of where Maxmind thinks your resolver (or ECS address) is
  • A ‘pick your protocol’ equivalent of the v4 or v6 specific whoami queries

The actual records look like this:

whoami.lua     IN LUA TXT  "who:toString()"
whoami-ecs.lua IN LUA TXT  "'ip: '..who:toString()..', netmask: '..(ecswho and ecswho:toString() or 'no ECS')"
latlon.lua     IN LUA LOC  "latlonloc()"
whoami.v6      IN LUA AAAA "who:toString()"
whoami.v4      IN LUA A    "who:toString()"

Further details

Full documentation for this feature can be found here. To test, packages can be found on:

Install the main PowerDNS package, the gsqlite3 (for example) and geoip backends.

For Ubuntu/Debian: After installing the packages, you may need to run ‘apt-get install -f’ to get the dependencies. In addition, to benefit from Maxmind, you may have to install a package with a name like geoip-database-contrib or geoipupdate.

For CentOS/RHEL:

# yum install epel-release yum-plugin-priorities
# tar xf pdns*luarec*bz2

Then cd into the newly created directory and ‘yum install’ the packages mentioned above.

Setting up PowerDNS & Lua

Setup gsqlite3 as described here (or gmysql, gpgsql), then edit the pdns.conf to include:

launch=gsqlite3,geoip
gsqlite3-database=/location/of/powerdns.sqlite
local-address=0.0.0.0
local-ipv6=::
edns-subnet-processing
log-dns-queries
loglevel=9
geoip-database-files=/usr/share/GeoIP/GeoIPCity.dat,/usr/share/GeoIP/GeoIPASNum.dat
enable-lua-record

Most of this is generic to PowerDNS. Specific for our use is loading the geoip backend and its database files, enabling the LUA record, EDNS Client Subnet processing, and some debug logging so you see what is happening. The geoip-database-files path may be different depending on your operating system.

Next up, generate a test zone, and edit it:

$ pdnsutil create-zone geo.example.com ns1.example.com
Creating empty zone 'geo.example.com'
Also adding one NS record
$ pdnsutil edit-zone geo.example.com

This will fire up an editor, and allows you to insert your first LUA record. For fun, try:

geo.example.com 3600 IN LUA TXT "os.date()"

Save, and pdnsutil will ask you if you want to apply this change. Do so, and then query your PowerDNS:

$ dig -t txt geo.example.com @127.0.0.1 +short
"Thu Dec 14 21:49:00 2017"

After this you can try the zonefiles listed above, or paste from the ‘lua.powerdns.org’, ‘v4.powerdns.org’ and ‘v6.powerdns.org’ zones.

If this does not work for you (even after reading the documentation), please find us through our Open Source page. In addition, if it does work for you but you have feedback or features you need, please also let us know through powerdns.ideas@powerdns.com.

Thanks & enjoy!

PowerDNS Recursor 4.0.8 Released

Today we announce the release of the PowerDNS Recursor 4.0.8 which contains a fix for the following security advisory:

The full changelog looks like this:

Bug fixes

  • #5930: Don’t assume TXT record is first record for secpoll
  • #6082: Don’t add non-IN records to the cache

The tarball is available on downloads.powerdns.com (signature) and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Artful, Trusty, Xenial and Zesty are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailinglist, or in case of a bug, via GitHub.

 

PowerDNS Recursor 4.1

This is a major release containing significant speedups (both in throughput and latency), enhanced capabilities and a highly conformant and robust DNSSEC validation implementation that is ready for heavy production use. In addition, our EDNS Client Subnet implementation now scales effortlessly to networks needing very fine grained scopes (as used by some ‘country sized’ service providers).

4.1 reflects over a year of improvements, cleanups and enhancements – both visible and invisible. Some of the smaller improvements have been backported to 4.0 releases, but most are new.

We are particularly grateful for the help of XS4ALL and Packet Clearing House (Quad9) for their help maturing this release to production readiness. In addition, various very large RFP requirements documents have also been stimulating. Finally, we’d like to thank Akamai for quickly resolving a single bit issue in their DNS responses which led the stricter 4.1-era resolving logic to not cache certain data which caused user noticeable slowdowns.

We have tried to list everyone else in the full changelog, and we are very grateful for all the work and testing PowerDNS has received from the community!

4.1 has seen an astounding amount of pre-release testing and even full production use, and from this data we know this release is rock solid and represents a significant speedup not only in benchmarks but also in real life.

2

DNSSEC

DNSSEC is a complicated protocol, yet operators (rightfully) expect rapid performance that resolves even rare or outlandish signing scenarios, all while not impacting non-DNSSEC enabled domain resolution speed. While Recursor 4.0.7 is suitable for DNSSEC validation, operators have noted that 4.1 delivers superior performance, with no observable errors that are not caused by configuration mistakes by domain owners. In addition, 4.1 works around more issues triggered by non-conforming nameservers and load balancers. Anyone doing DNSSEC validation with 4.0.7 is urged to upgrade.

As part of this DNSSEC work, the central DNS resolving logic of PowerDNS was fully cleaned up and made unit-testable. Large volumes of such unit tests have been added, next to similar large amounts of new regression tests.

After extensive measurements, we are now sure that enabling DNSSEC validation has a negligible impact on user experienced performance.

Improved documentation

Our Pieter Lexis invested a ton of time improving not only the contents but also the appearance and search of our documentation. Take a look at https://doc.powerdns.com/recursor/ and know you can easily edit our documentation via GitHub’s built in editor.

RPZ

RPZ is a standard for retrieving policy through zonefiles, possibly transferred incrementally (IXFR). PowerDNS 4.0 brought support for RPZ, but it was not quite complete and had performance deficiencies on very large RPZ datasets. Some of the 4.1 improvements in this area have already been backported to the 4.0 series. Notable changes in 4.1 are the addition of support for wildcard records, improvements in RPZ reloading & update processing and new debugging facilities (logging of changes and serialization of current RPZ state).

EDNS Client Subnet

EDNS Client Subnet is utilized to transmit (part of) the client IP address to authoritative servers, in the hope that they can provide more relevant answers. ECS is used by large Content Distribution Networks, and can be required to offer good streaming performance for clients within very large operator networks. The 4.0 ECS implementation is running in production in a number of such places, but the 4.1 implementation has been improved to use less CPU cycles and deal better with smaller subnets. In addition, metrics have been added to monitor ECS query loads.

Miscellaneous

SNMP support was added. The built-in authoritative server (which is more important since Authoritative Server 4.1 removed the ‘recursor=’ bypass) gained the ability to serve wildcard CNAMEs. The Lua engine gained a lot of access to relevant data from more places (EDNS Client Subnet details, MAC address, TCP or UDP). CPU affinity can now be specified. Support was added for TCP Fast Open.

There are new performance metrics which track the amount of CPU time used per query, which is useful to study performance isolated from network latencies.

The full changelog can be read here.

The tarball is available on downloads.powerdns.com (signature) and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Artful, Trusty, Xenial and Zesty are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailinglist, or in case of a bug, via GitHub.

PowerDNS Authoritative Server 4.1

Version 4.1 is a major upgrade for the Authoritative Server, delivering improvements and speedups developed and tested over the past 12 months. Many large scale deployments have already migrated to this release because even unreleased, it was a better nameserver than 4.0.x (although the recently released 4.0.5 has fixed a number of relevant issues).

1

This release features prominent contributions from our community. We’d like to highlight the tireless work of Kees Monshouwer in improving the Authoritative Server based on his huge experience scaling PowerDNS to millions of DNSSEC production zones. Christian Hofstaedtler and Jan-Piet Mens contributed massively as well in many different places. Also a round of thanks to Grégory Oestreicher for revamping and reviving the LDAP backend. Wolfgang Studier, “#MrM0nkey”, Tudor Soroceanu and Benjamin Zengin delivered the DNSSEC management API, as part of their studies at TU Berlin.

We have tried to list everyone else in the full changelog, and we are very grateful for all the work and testing PowerDNS has received from the community!

Improved performance: 4x speedup in some scenarios

More than a year ago, the RIPE NCC benchmarked several nameserver implementations, and found PowerDNS was not a performant root-server. Although PowerDNS is great at serving millions of zones, we’d like to be fast on smaller zones as well. Results of this optimization spree are described here, and also in this longer article “Optimizing optimizing: some insights that led to a 400% speedup of PowerDNS”. Kees Monshouwer’s cache (re)work has been vital to attaining this performance improvement.

Crypto API: DNSSEC fully configurable via RESTful API

Our RESTful HTTP API has gained support for DNSSEC & key management. This API is “richer than most” since it is aware of DNSSEC semantics, and therefore allows you to manipulate zones without having to think about DNSSEC details. The API will do the right thing. This work was contributed by Wolfgang Studier, #MrM0nkey, Tudor Soroceanu and Benjamin Zengin as part of their work over at TU Berlin.

Database related: reconnection and 64 bit id fields

Database servers sometimes disconnect after shorter or longer idle periods. This could confuse both PowerDNS and database client libraries under some quiet conditions. 4.1 contains enhanced reconnection logic that we believe solves all associated problems. In a pleasing development, one PowerDNS user has a database so large they exceeded a 32 bit id counter, which has now been made 64 bit.

Improved documentation

Our Pieter Lexis invested a ton of time improving not only the contents but also the appearance and search of our documentation. Take a look at https://doc.powerdns.com/authoritative/ and know you can easily edit our documentation via GitHub’s built in editor.

Recursor passthrough removal

This will impact many installations, and we realize this may be painful, but it is necessary. Previously, the PowerDNS Authoritative Server contained a facility for sending recursion desired queries to a resolving backend, possibly after first consulting its local cache. This feature (‘recursor=’) was frequently confusing and also delivered inconsistent results, for example when a query ended up referring to a CNAME that was outside of the Authoritative Server’s knowledge. To migrate from a 3.0 or 4.0 era PowerDNS Authoritative Server with a ‘recursor’ statement in the configuration file, please see Migrating from using recursion on the Authoritative Server to using a Recursor.

Miscellaneous

Support was added for TCP Fast Open. Non-local bind is now supported. pdnsutil check-zone will now warn about more errors or unlikely configurations. Our packages now ship with PKCS #11 support (which previously required a recompilation). Improved integration with systemd logging (timestamp removal).

The full changelog can be read here.

The tarball is available on downloads.powerdns.com (signature) and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Artful, Trusty, Xenial and Zesty are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailinglist, or in case of a bug, via GitHub.

PowerDNS Authoritative Server 4.0.5 and Recursor 4.0.7 Released

Today we announce the release of both the PowerDNS Authoritative Server 4.0.5 and Recursor 4.0.7 which contain a lot of backports from the 4.1.x branch.
These releases also drop support for Botan 1.10 in favor of Botan 2.x.
More importantly there are fixes for the following security advisories.

Authoritative Server

Recursor

(We thank Nixu for their discoveries of CVE-2017-15092, CVE-2017-15093 and CVE-2017-15094.)

 Changelog: PowerDNS Authoritative Server 4.0.5

The full changelog looks like this:

Bug fixes

  • #4650: Bindbackend: do not corrupt data supplied by other backends in getAllDomains (Christian Hofstaedtler)
  • #4751: API: prevent sending nameservers list and zone-level NS in rrsets (Christian Hofstaedtler)
  • #4929: gpgsql: make statement names actually unique (Christian Hofstaedtler)
  • #4997: Fix remotebackend params (Aki Tuomi)
  • #5051: Fix godbc query logging
  • #5125: For create-slave-zone, actually add all slaves, and not only first n times
  • #5161: Fix a regression in axfr-rectify + test (Arthur Gautier)
  • #5408: When making a netmask from a comboaddress, we neglected to zero the port
  • #5599: Fix libatomic detection on ppc64
  • #5641: Catch DNSName exception in the Zoneparser
  • #5722: Publish inactive KSK/CSK as CDNSKEY/CDS
  • #5730: Handle AFSDB record separately due to record structure. Fixes #4703 (Johan Jatko)
  • #5678: Treat requestor’s payload size lower than 512 as equal to 512
  • #5766: Correctly purge entries from the caches after a transfer
  • #5777: Handle a signing pipe worker dying with work still pending
  • #5815: Ignore SOA-EDIT for PRESIGNED zones. Fixes #5814
  • #5933: Check return value for all getTSIGKey calls. Fixes #5931

Improvements

  • #4922: Fix ldap-strict autoptr feature, including a test
  • #5043: mydnsbackend: Add getAllDomains (Aki Tuomi)
  • #5112: Stubresolver: Use only recursor setting if given
  • #5147: LuaWrapper: Allow embedded NULs in strings received from Lua
  • #5277: sdig: Clarify that the ednssubnet option takes “subnet/mask”
  • #5309: Tests: Ensure all required tools are available (Arthur Gautier)
  • #5320: PowerDNS sdig does not truncate trailing bits of EDNS Client Subnet mask
  • #5349: LuaJIT 2.1: Lua fallback functionality no longer uses Lua namespace
  • #5498: Add support for Botan 2.x
  • #5509: Ship ldapbackend schema files in tarball (Christian Hofstaedtler)
  • #5518: Collection of schema changes (Kees Monshouwer)
  • #5523: Fix typo in two log messages (Ruben Kerkhof)
  • #5598: Add help text on autodetecting systemd support
  • #5723: Use a unique pointer for bind backend’s d_of
  • #5826: Fix some of the issues found by @jpmens

The tarball is available on downloads.powerdns.com (signature) and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Artful, Trusty, Xenial and Zesty are available from repo.powerdns.com.

Changelog: PowerDNS Recursor 4.0.7

The full changelog looks like this:

Bug fixes

  • #4561: Update rec_control manpage (Winfried Angele)
  • #4824: Check in the detected OpenSSL/libcrypto for ECDSA
  • #5406: Make more specific Netmasks < to less specific ones
  • #5525: Fix validation at the exact RRSIG inception or expiration time
  • #5740: Lowercase all outgoing qnames when lowercase-outgoing is set
  • #5599: Fix libatomic detection on ppc64
  • #5961: Edit configname definition to include the ‘config-name’ argument (Jake Reynolds)

Improvements

  • #4646: Extract nested exception from Luawrapper
  • #4960: Use explicit yes for default-enabled settings (Christian Hofstaedtler)
  • #5078: Throw an error when lua-conf-file can’t be loaded
  • #5261: get-remote-ring’s “other” report should only have two items. (Patrick Cloke)
  • #5320: PowerDNS sdig does not truncate trailing bits of EDNS Client Subnet mask
  • #5488: Only increase no-packet-error on the first read
  • #5498: Add support for Botan 2.x
  • #5511: Add more information to recursor cache dumps
  • #5523: Fix typo in two log messages (Ruben Kerkhof)
  • #5598: Add help text on autodetecting systemd support
  • #5726: Be more resilient with broken auths
  • #5739: Remove pdns.PASS and pdns.TRUNCATE
  • #5755: Improve dnsbulktest experience in travis for more robustness
  • #5762: Create socket-dir from init-script
  • #5843: b.root renumbering, effective 2017-10-24
  • #5921: Don’t retry security polling too often when it fails

The tarball is available on downloads.powerdns.com (signature) and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Artful, Trusty, Xenial and Zesty are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailinglist, or in case of a bug, via GitHub.

FOSDEM 2018 DNS devroom CfP!

Hello DNS-enthusiasts and other developers,

After two successful BoF sessions at FOSDEM 2016 and 2017, FOSDEM 2018 will see a real DNS devroom! We hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding or system administrators responsible for DNS infrastructure.

We have been allotted half a day on Sunday 4 February 2018. We expect to schedule 30 minutes per talk, including questions, but this is open to discussion.

If you have something you’d like to share with your fellow developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM18. Examples of topics are measuring, monitoring, DNS libraries, and anecdotes on how you’ve (ab)used the DNS.

The deadline for submission is December 8th. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to dns-devroom-manager@fosdem.org if you run into any trouble.

We are also looking for volunteers to help with cameras etc. Please drop us an email at dns-devroom-manager@fosdem.org if you’re interested in helping out.

See you there!

Cheers,
Peter van Dijk, Shane Kerr, Pieter Lexis