The Knot DNS server is an authoritative DNS server. We've spoken about it before when I introduced it to you it almost 3 years ago and again when I discussed how Knot does dynamic DNS updates and RRL. A lot of Internet time has elapsed since then, and a lot of code has been added to Knot, so it's high time for me to revisit it.

Knot now supports DNSSEC signing of authoritative zones. However, it doesn't provide the utilities with which we create keys, so we use dnssec-keygen (from BIND) or ldns-keygen (from LDNS) to do so. All keys for a zone must be kept in their individual directory which is configured with dnssec-keydir in Knot. In the following zone stanza of my knot.conf I chose to keep the zone and its keys in their own directory (storage).

k03.aa {
  storage "/usr/local/etc/knot/k03";
  dnssec-keydir ".";
  file "k03.aa";
  dnssec-enable on;
  signature-lifetime 1d;  # default: 30d (1d for experiments!)
  serial-policy increment;  # or unixtime
  update-in local;
}

The serial-policy setting specifies how the SOA serial number will be changed after a dynamic DNS update; I prefer a simple + 1 so I use increment. signature-lifetime specifies how long the DNSSEC signatures (RRSIG) should be valid for, and dnssec-enable obviously enables signing.

After creating keys in my storage directory, I can use knotc to reconfigure Knot, and this is what I see in the logs:

info: [k03.aa] DNSSEC, signing started
info: [k03.aa] DNSSEC, loaded key 32514, file 'Kk03.aa.+012+32514.private', KSK, active, public
info: [k03.aa] DNSSEC, loaded key 16266, file 'Kk03.aa.+012+16266.private', ZSK, active, public
info: [k03.aa] DNSSEC, successfully signed
info: [k03.aa] DNSSEC, next signing on 2015-02-07T15:16:01
info: [k03.aa] loaded, serial 0 -> 12
info: [k03.aa] zone file updated, serial 11 -> 12

The serial number transitions look a bit strange, but I interpret them as zone loaded (0 -> 12, which should be 11 actually) and then signatures and DNSKEY as well as NSEC data added (11 -> 12).

Will it blend?

;; ANSWER SECTION:
k03.aa.                 3600 IN SOA k03.aa. jpmens.gmail.com. (
                                12         ; serial
                                21600      ; refresh (6 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                600        ; minimum (10 minutes)
                                )
k03.aa.                 3600 IN RRSIG SOA 12 2 3600 20150207174001 (
                                20150206174001 16266 k03.aa.
                                gVTOAXQRDrIL+yeJrK5+T7xemET7A3B0BmBxA/CwsD/x
                                jgfTPZKbV+f98yp98UqwGn5gHOXtbeduL88lWvGPXQ== )

The signature was produced by the key with keytab 16266 (the ZSK). so that looks ok. Actually, I then copied the trust anchor (KSK) to an Unbound server, reloaded that, and it validated the data produced by my Knot server. Also, as Knot will thankfully sign dynamic updates on the fly, any changes I make to the zone via dynamic DNS updates are validatable as soon as the TTL expires.

If the keys I give to Knot are NSEC3-capable it will add NSEC3 denial records to the zone; this is also controlled by the NSEC3PARAM record if present in the original unsigned zone file.

It's a pity Knot overwrites the original unsigned zone file with the signed version. Also, it's not possible to sign zones which are slaved in, making a bump-in-the-wire signer impossible.

Knot's "DNS control utility", knotc shows me the signing status of the zones (the zone name is separated from the rest of the line with a TAB and other wite space are spaces)

$ knotc zonestatus
aa.     type=slave | serial=2015020603 | refresh in 0h29m1s | DNSSEC signing disabled
k03.aa. type=master | serial=14 | DNSSEC resign in 21h32m59s | automatic DNSSEC, resigning at: 2015-02-08T04:38:31
p01.aa. type=slave | serial=2015020514 | refresh in 0h29m1s | DNSSEC signing disabled
example.com.    type=master | serial=2010111213 |  idle | DNSSEC signing disabled

Synthetic records

A feature some people want is the ability for an authoritative server to synthesize answers to queries, a bit like BIND's $GENERATE does. Knot has support for this in form of a query module which you enable on a per/zone basis.

Let's assume we wish to provide responses for an address range 10.1.2/24, I can configure the following in a zone stanza:

example.com {
    file "/usr/local/etc/knot/example.com.zone";
    query_module {
        #                     prefix  TTL     CIDR
        synth_record "forward dyn-    180     10.1.2.0/24";
    }
}

Clients which query names such as dyn-10-1-2-89.example.com (address portions separated by dashes) get the following authoritative response:

$ dig dyn-10-1-2-89.example.com

;; ANSWER SECTION:
dyn-10-1-2-89.example.com. 180  IN      A       10.1.2.89

Synthesized responses are possible for reverse zones as well. Note, however, that currently these records are not signed in DNSSEC-enabled zones.

The documentation provided by the Knot DNS project is adequate, and will help you get started with Knot.

Flattr this
DNSSEC and DNS :: 06 Feb 2015 :: e-mail

Comments

blog comments powered by Disqus