Your FRiTZ!Box maintains a useful list of names of machines in your local network in its pseudo-domain fritz.box, based on DHCP requests and web interface. This information is useful, but adding the pseudo-domain “fritz.box” to your own DNS hierarchy is no longer straightforward in the days of DNSSEC. Here is how to include it into your own ISC BIND9 DNS server.

Note: This post may no longer be accurate or up-to-date. Please verify with other sources.

The naïve way

BIND allows to delegate a zone easily using the a zone by adding a zone to named.conf as follows (assuming 192.168.178.1 is the address of your FRiTZ!Box):

zone "fritz.box" {
  type forward;
  forward only;
  forwarders { 192.168.178.1; };
};

This tells your local BIND named to send all requests within the fritz.box domain to your FRiTZ!Box. With a modern dig and named, this gives problems due to the DNSSEC interaction:

$ dig capacity.fritz.box

; <<>> DiG 9.9.5-3-Ubuntu <<>> capacity.fritz.box
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38726
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;capacity.fritz.box.     IN  A

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 18 21:43:10 CEST 2014
;; MSG SIZE  rcvd: 47

Why it does not work

Please note the SERVFAIL (emphasis mine), i.e., the server complains about a problem. Looking into /var/log/syslog, we can see (emphasis again mine):

Oct 18 21:43:02 capacity named[31015]: error (insecurity proof failed) resolving 'fritz.box/A/IN': 192.168.178.1#53
Oct 18 21:43:10 capacity named[31015]: validating @0x7feb10019180: fritz.box SOA: got insecure response; parent indicates it should be secure
Oct 18 21:43:10 capacity named[31015]: error (no valid RRSIG) resolving 'capacity.fritz.box/DS/IN': 192.168.178.1#53
Oct 18 21:43:10 capacity named[31015]: error (no valid DS) resolving 'capacity.fritz.box/A/IN': 192.168.178.1#53

“Got insecure response” is true, the FRiTZ!Box does not sign its DNS responses. However, what should “parent indicates it should be secure” mean? There is no parent zone, box, there is only fritz.box. However, it believes this zone should be signed because the parent zone does not say the child zone is unsigned.

To understand this, let us look at the “normal” hierarchy: The root zone is signed. To indicate whether a child zone is signed, it includes a valid DS (Delegation Signer) record for the child, which authenticates the key used in the subdomain. To indicate that a child zone is without DNSSEC, there is no DS record.

To prevent an attacker from suppressing this DS record in order to be able to modify any DNS record in the domain and subvert the entire DNSSEC infrastructure, the absence of a DS record needs to be cryptographically signed, typically through an NSEC3 (Next Secure Record, version 3) that explicitly lists the DS as absent.

As the parent zone includes neither, named errs on the side of an attacker doing something malicious.

How to make it work

The way around that misconception is to actually have a parent zone which tells that the child zone is without DNSSEC support. Create a file zone /etc/bind/db.box with the following contents.

$TTL   3600
@      SOA ns1.netfuture.ch. hostmaster.netfuture.ch. (
           2014101800 ; Serial
           1d         ; Refresh
           3h         ; Retry
           4w         ; Expire
           300s )     ; Negative Cache TTL
@      NS  ns1.netfuture.ch.
fritz  NS  fritz.box.
       A   192.168.178.1

(In your setup, you will have to change the bold parts: @ NS should state your real nameserver and 192.168.178.1 has to be replaced with the IP address of your FRiTZ!Box.)

Of course, this file needs to be DNSSEC protected.

To make this database visible, our named.conf zone entry needs to be changed to:

zone "fritz.box" {
  type master;
  file "/etc/bind/db.box";
};