DNS Response Rate Limiting as implemented in NSD.

October 11, 2012 by wouter

(Note 10 Oct 2012: Rate limiting is worked on at this time, and is being tested, it is not available in NSD production code yet).

(Update 10 Dec 2012 : changed title to indicate it is based on Vixie and Schryver’s work)

Rate Limits

Rate limiting is seen as a way to combat reflection attacks, where spoofed UDP packets are bounced off DNS servers to attack a target, and rate limits stop these high volume query streams. BCP38 (source IP checks on originating networks, bcp38) is the real fix, but has not seen sufficient deployment. We would not want to complicate our software needlessly; the rate limiting must not become a target itself. But the knowledge that the DNS server has, makes rate limiting easier to implement. We chose an implementation that should be easy to separate from the DNS server, if desired. Our approach is based on RRL by Vixie and Schryver (RRL) and Tony Finch’s analysis (fanf).

The RRL (response rate limiting) is implemented in the NSD server, for convenience. This makes server operations easier and implementation faster, and it saves time classifying the response. This code is enabled with the –enable-ratelimit option for configure. We plan to implement RRL for NSD4 and NSD3. There is a whitelist option available for allowing higher traffic for some parts.

The approach is meant to be different from others, for code diversity goals, thus we do not use the code from Vixie and Schryver, but we use similar false positive prevention mechanisms. The NSD RRL code uses a fixed-size hashtable, and smoothed averaged qps rates per bucket. If two different source netblocks (/24 ip4, /64 ip6) hash to the same bucket, it is reinitialized, causing a potential false positive to turn into a false negative. Additionally, the SLIP mechanism from Vixie and Schryver is used to give TCP fallback in case of a false positive.

(more…)

NSD4 Features

September 14, 2012 by wouter

NSD 4 is under development. The plan is to improve NSD 3 with a number of new features. The main goals are:

  • More dynamic configuration support
  • High number of zones supported
  • It stays the lean and mean, typical secondary authoritative DNS server that you know it for.

To do this, the implementation includes the following features (available today, from development snapshots):

  • patterns – config file structures that macro-ize the configuration of different zones, so you do not have to repeat configuration for many zones.
  • nsd-control – basically a copy of our BSD-licensed unbound product’s unbound-control, it connects over SSL to the daemon and you can then tell it new configuration without a restart.  Add and remove zones, and other commands.
  • changes to the database, both in memory and on disk to accommodate the goals. This includes incremental NSEC3 precompilation which speeds up the change of very large zones.
  • nsdc and zonec gone. the cronjob is gone – scratch files are kept in /tmp and deleted when no longer needed.

The patterns are a collection of zone options with a name. When you add new zones you can specify the options for the zone with the name of the pattern to apply. It is possible to use included-patterns to create shorthands for options shared by (many) other patterns. In this way you can easily specify the patterns for a large number of zones, and change options for all of them at once.

The zone compiler is part of NSD now, and is forked to read a zone file when needed. The modification times of the file system are used to read changed zone files (on the SIGHUP signal and the reload command). The database on disk is edited in-place, so that no restart is needed.

Further features are worked on to finish the implementation of NSD4.

 

Wed Sep 25 2013

© Stichting NLnet Labs

Science Park 400, 1098 XH Amsterdam, The Netherlands

labs@nlnetlabs.nl, subsidised by NLnet and SIDN.