Next: , Previous: , Up: Knot DNS Configuration   [Contents][Index]


4.2 Slave configuration

Knot DNS doesn’t strictly differ between master and slave zones. The only requirement is to have xfr-in zones statement set for given zone, thus allowing both incoming XFR from that remote and using it as the zone master. If update-in is set and zone has a master, any accepted DNS UPDATE will be forwarded to master. Also note that you need to explicitly allow incoming NOTIFY, otherwise the daemon would reject them. Also, you can specify paths, relative to the storage directory. See zones and storage. If the zone file doesn’t exist and xfr-in is set, it will be bootstrapped over AXFR.

remotes {
  master { address 127.0.0.1@53; }
  subnet1 { address 192.168.1.0/24; }
}
zones {
  example.com {
    file "example.com"; # relative to 'storage'
    xfr-in master;      # define 'master' for this zone
    notify-in master;   # also allow NOTIFY from 'master'
    update-in subnet1;  # accept UPDATE msgs from subnet1 and forward
                        # to master
  }
}

You can also use TSIG for access control. For this, you need to configure a TSIG key and assign it to a remote. Supported algorithms for TSIG key are:
hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512
Key secret is written in a base64 encoded format. See keys.

keys {
  key0 hmac-md5 "Wg=="; # keyname algorithm secret
}
remotes {
  master { address 127.0.0.1@53; key key0; }
}
zones {
  example.com {
    file "example.com"; # relative to 'storage'
    xfr-in master;      # define 'master' for this zone
    notify-in master;   # also allow NOTIFY from 'master'
  }
}

As of now it is not possible to associate multiple keys with a remote.