You are here: Home > Publications > RIPE Labs > Matthijs Mekking > Making IXFR Small Again

Making IXFR Small Again

Matthijs Mekking — 28 Mar 2018
At the recent IETF 101 hackathon, we worked on a project to reduce the size of incremental zone transfers (IXFRs) with some very interesting results.

 

For the sixth time, the Internet Engineering Task Force (IETF) organised a Hackathon where developers can collaborate on implementations of IETF drafts and standards. It was a wildly successful edition with the most participants ever.

My work place at the IETF 101 hackathon

About 25 DNS developers signed up, most of them worked on implementing DNS-over-HTTPS (doh). There were some other small projects, including work on ANAME and Root KSK Sentinel. Together with Shane Kerr, I worked on Minimal Incremental Zone Transfer in DNS (MIXFR).

MIXFR is described in a ( now expired) Internet draft that reduces the size of incremental zone transfers (IXFRs). It mostly deals with DNSSEC cases, such as zone resign and NSEC3 resalt, but also has some generic improvements over IXFR.

For the Hackathon we focused on implementing "Implicit RRSIG Deletion". This says that a MIXFR client must remove all existing RRSIG records on a changed RRset. This means that a MIXFR server no longer needs to include those deleted RRSIG records in its zone transfer.

We decided to hack this code into the Knot DNS authoritative name server. We have considered other open-source name server implementations, but NSD and PowerDNS do not do IXFR as a master, and the other one is BIND. During the meeting, I have learned that NSD has plans to add IXFR serving and PowerDNS has a separate IXFR daemon, ixfrdist.

We forked the code from CZ.NIC labs Gitlab and got off to a good start. Already on the first day we were ready to test our code. And of course we found some issues:

When we triggered a MIXFR, the transfer still included all the signatures that we try to delete implicitly, but not the other records. After some debugging I found out this was also true for IXFR, so did I hit a bug in the Knot code?

It is important to know that Knot DNS uses a generic storage directory that is used to store the zone database. If you are running a primary and secondary name server on the same machine, unexpected things can happen. In these cases it is advised to run with the default template and set the storage directory to different paths. Also, zone changes should be made with the knotc zone-* commands. If you want to edit the zonefile directly and depend on IXFR, you should set zonefile-load: difference. Both issues were reported to CZ.NIC Labs.

Of course there were also bugs in our MIXFR code and we resolved them on the second day of the Hackathon. We have set up a simple test zone, a primary and secondary name server, and start triggering zone transfers. Our DNSSEC policy signs the zone with the RSASHA256 algorithm. A simple MX record and A record change resulted in a stunning 888 bytes savings on the wire: The packet size was reduced from 2,105 bytes to 1,217 bytes. Three RRSIG records were implicitly deleted, for MX, A and SOA, and each signature was 296 bytes in size.

A MIXFR response captured in Wireshark

We also tried out the more favorable ECDSAP256SHA256 algorithm, which is much shorter, and for our zone reduces the size with 104 bytes per saved RRSIG record.

Where MIXFR will really shine is in a zone resign, think of all those removed RRSIG records that you don't have to transmit. You could easily reduce the zone transfer to half its size. However, this is something we did not get to and is left for the next Hackathon.

Our work at the Hackathon in London resulted in 33 commits, 9 changed files, 695 additions (mainly because we copied two files), 50 deletions, and 2 issues. The MIXFR draft will be revived. It also sparked the discussion whether we should put resources in improving the in-band zone transfer protocol, or whether we should focus on a new protocol on a different port.

0 Comments

Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.