Provided by: nsd3_3.2.9-1_i386 bug

NAME

       nsd.conf - NSD configuration file

SYNOPSIS

       nsd.conf

DESCRIPTION

       Nsd.conf  is  used  to configure nsd(8). The file format has attributes
       and values. Some attributes have attributes inside them.  The  notation
       is: attribute: value.

       Comments  start  with  #  and  last to the end of line. Empty lines are
       ignored as is whitespace at the beginning of a line.

       Nsd.conf specifies options for the nsd server,  zone  files,  primaries
       and secondaries.

EXAMPLE

       An example of a short nsd.conf file is below.

       # Example.com nsd.conf file
       # This is a comment.

       server:
            database: "/var/lib/nsd3/nsd.db"
            username: nsd
            logfile: "/var/log/nsd.log"
            pidfile: "/var/run/nsd3/nsd.pid"
            difffile: "/var/lib/nsd3/ixfr.db"
            xfrdfile: "/var/lib/nsd3/xfrd.state"

       zone:
            name: example.com
            # note that quotes are optional on the value
            zonefile: /etc/nsd3/example.com.zone

FILE FORMAT

       There  must be whitespace between keywords. Attribute keywords end with
       a colon ':'. An attribute is followed by its containing attributes,  or
       a value.

       At  the  top level only server: or zone: or key: are allowed. These are
       followed by their attributes or the start of a new server: or zone:  or
       key:  clause.  The  zone:  attribute  is  followed by zone options. The
       server: attribute is followed by global options for the NSD  server.  A
       key: attribute is used to define keys for authentication.

       Files  can  be  included  using  the  include: directive. It can appear
       anywhere, and takes  a  single  filename  as  an  argument.  Processing
       continues  as  if  the  text from the included file was copied into the
       config file at that point.  .LP The global options (if  not  overridden
       from  the NSD commandline) are taken from the server: clause. There may
       only be one server: clause.

       ip-address: <ip4 or ip6>[@port]
              NSD will bind to the listed ip-address.  Can  be  give  multiple
              times  to  bind multiple ip-addresses. Optionally, a port number
              can be given.  If none are given NSD  listens  to  the  wildcard
              interface. Same as commandline option -a.

       debug-mode: <yes or no>
              Turns on debugging mode for nsd, does not fork a daemon process.
              Default is no. Same as commandline option -d.

       ip4-only: <yes or no>
              If  yes,  NSD  only  listens  to  IPv4  connections.   Same   as
              commandline option -4.

       ip6-only: <yes or no>
              If   yes,   NSD  only  listens  to  IPv6  connections.  Same  as
              commandline option -6.

       database: <filename>
              By default /var/lib/nsd3/nsd.db is used. The specified  file  is
              used to store the compiled zone information. Same as commandline
              option -f.

       identity: <string>
              Returns the specified identity when asked for CH TXT  ID.SERVER.
              Default  is  the  name  as  returned  by gethostname(3). Same as
              commandline option -i.

       nsid: <string>
              Add the specified nsid to the EDNS section of  the  answer  when
              queried  with  an  NSID EDNS enabled packet. Same as commandline
              option -I.

       logfile: <filename>
              Log messages to the logfile. The default is to log to stderr and
              syslog  (with  facility  LOG_DAEMON). Same as commandline option
              -l.

       server-count: <number>
              Start this many NSD servers. Default is 1. Same  as  commandline
              option -N.

       tcp-count: <number>
              The maximum number of concurrent, active TCP connections by each
              server.  Default is 10. This option should have  a  value  below
              1000.  Same as commandline option -n.

       tcp-query-count: <number>
              The maximum number of queries served on a single TCP connection.
              Default is 0, meaning there is no maximum.

       tcp-timeout: <number>
              Overrides the  default  TCP  timeout.  This  also  affects  zone
              transfers over TCP.

       ipv4-edns-size: <number>
              Preferred EDNS buffer size for IPv4.

       ipv6-edns-size: <number>
              Preferred EDNS buffer size for IPv6.

       pidfile: <filename>
              Use  the  pid  file  instead  of  the platform specific default,
              usually /var/run/nsd3/nsd.pid.  Same as commandline option -P.

       port: <number>
              Answer queries on the specified port. Default  is  53.  Same  as
              commandline option -p.

       statistics: <number>
              If not present no statistics are dumped. Statistics are produced
              every number seconds. Same as commandline option -s.

       chroot: <directory>
              NSD will chroot on startup to the specified directory.  Same  as
              commandline option -t.

       username: <username>
              After  binding  the  socket, drop user privileges and assume the
              username. Can be username, id or  id.gid.  Same  as  commandline
              option -u.

       zonesdir: <directory>
              Change  the  working directory to the specified directory before
              accessing  zone  files.  Same  as  commandline  option  -d   for
              zonec(8).  Also  nsd(8)  will  access  files (pid file, database
              file, log file) relative to this directory. Set the value to  ""
              (the empty string) to disable the change of working directory.

       difffile: <filename>
              When  NSD receives IXFR updates it will store them in this file.
              This file contains the differences between the database file and
              the latest zone version. Default is /var/lib/nsd3/ixfr.db.

       xfrdfile: <filename>
              The  soa  timeout  and zone transfer daemon in NSD will save its
              state to this file. State is read  back  after  a  restart.  The
              state  file can be deleted without too much harm, but timestamps
              of zones will be gone. For more details see the section on  zone
              expiry behavior of NSD. Default is /var/lib/nsd3/xfrd.state.

       xfrd-reload-timeout: <number>
              If this value is -1, xfrd will not trigger a reload after a zone
              transfer. If positive xfrd will trigger a reload  after  a  zone
              transfer,  then it will wait for the number of seconds before it
              will trigger a new reload.  Setting  this  value  throttles  the
              reloads  to  once  per  the number of seconds. The default is 10
              seconds.

       verbosity: <level>
              This  value  specifies  the  verbosity  level  for   (non-debug)
              logging.   Default is 0. 1 gives more information about incoming
              notifies and zone transfers. 2  lists  soft  warnings  that  are
              encountered.

       hide-version: <yes or no>
              Prevent NSD from replying with the version string on CHAOS class
              queries.

   Zone Options
       For every zone the options need to be specified in  one  zone:  clause.
       The  access  control  list  elements can be given multiple times to add
       multiple servers. These elements need to be added explicitly.

       name: <string>
              The name of the zone. This is the domain name of the apex of the
              zone.  May  end  with  a  '.'  (in  FQDN  notation). For example
              "example.com",  "sub.example.net.".  This  attribute   must   be
              present in each zone.

       zonefile: <filename>
              The  file  containing the zone information. This file is used by
              zonec(8). This attribute must be present in each zone.

       allow-notify: <ip-spec> <key-name | NOKEY | BLOCKED>
              Access control list. The listed (primary) address is allowed  to
              send notifies to this (secondary) server. Notifies from unlisted
              or specifically BLOCKED addresses are  discarded.  If  NOKEY  is
              given no TSIG signature is required.

              The  ip-spec is either a plain IP address (IPv4 or IPv6), or can
              be  a  subnet  of  the   form   1.2.3.4/24,   or   masked   like
              1.2.3.4&255.255.255.0  or  a range of the form 1.2.3.4-1.2.3.25.
              A port number can be  added  using  a  suffix  of  @number,  for
              example 1.2.3.4@5300 or 1.2.3.4/24@5300 for port 5300.  Note the
              ip-spec ranges do not use spaces  around  the  /,  &,  @  and  -
              symbols.

       request-xfr: [AXFR|UDP] <ip-address> <key-name | NOKEY>
              Access  control list. The listed address (the master) is queried
              for AXFR/IXFR on update. A port number  can  be  added  using  a
              suffix  of  @number, for example 1.2.3.4@5300. The specified key
              is used during AXFR/IXFR.

              If the AXFR option is given, the server will  not  be  contacted
              with  IXFR  queries  but  only AXFR requests will be made to the
              server. This allows an NSD secondary to  have  a  master  server
              that runs NSD. If the AXFR option is left out then both IXFR and
              AXFR requests are made to the master server.

              If the UDP option is  given,  the  secondary  will  use  UDP  to
              transmit the IXFR requests. You should deploy TSIG when allowing
              UDP transport, to  authenticate  notifies  and  zone  transfers.
              Otherwise, NSD is more vulnerable for Kaminsky-style attacks. If
              the UDP option is left out then IXFR will be  transmitted  using
              TCP.

       allow-axfr-fallback: <yes or no>
              This option should be accompanied by request-xfr. It (dis)allows
              NSD (as secondary) to fallback  to  AXFR  if  the  primary  name
              server does not support IXFR. Default is yes.

       notify: <ip-address> <key-name | NOKEY>
              Access  control  list.  The  listed  address  (a  secondary)  is
              notified of updates to this zone. A port  number  can  be  added
              using  a  suffix  of  @number,  for  example  1.2.3.4@5300.  The
              specified key is used to sign  the  notify.  Only  on  secondary
              configurations  will  NSD  be able to detect zone updates (as it
              gets notified itself, or refreshes after a time).

       notify-retry: <number>
              This option should be accompanied by notify. It sets the  number
              of retries when sending notifies.

       provide-xfr: <ip-spec> <key-name | NOKEY | BLOCKED>
              Access control list. The listed address (a secondary) is allowed
              to request AXFR from this server. Zone data will be provided  to
              the address. The specified key is used during AXFR. For unlisted
              or  BLOCKED  addresses  no  data  is  provided,   requests   are
              discarded.

              The  ip-spec is either a plain IP address (IPv4 or IPv6), or can
              be  a  subnet  of  the   form   1.2.3.4/24,   or   masked   like
              1.2.3.4&255.255.255.0  or  a range of the form 1.2.3.4-1.2.3.25.
              A port number can be  added  using  a  suffix  of  @number,  for
              example  1.2.3.4@5300 or 1.2.3.4/24@5300 for port 5300. Note the
              ip-spec ranges do not use spaces  around  the  /,  &,  @  and  -
              symbols.

       outgoing-interface: <ip-address>
              Access  control  list.  The  listed  address  is used to request
              AXFR|IXFR (in case of a secondary) or used to send notifies  (in
              case of a primary).

              The  ip-address  is  a  plain IP address (IPv4 or IPv6).  A port
              number can be added using  a  suffix  of  @number,  for  example
              1.2.3.4@5300.

   Key Declarations
       The  key:  clause establishes a key for use in access control lists. It
       has the following attributes.

       name: <string>
              The key name. Used to refer to this key in  the  access  control
              list.

       algorithm: <string>
              Authentication algorithm for this key.

       secret: <base64 blob>
              The  base64  encoded  shared  secret.  It is possible to put the
              secret: declaration (and base64 blob) into a different file, and
              then  to  include: that file. In this way the key secret and the
              rest  of  the  configuration  file,  which  may  have  different
              security policies, can be split apart.

NSD CONFIGURATION FOR BIND9 HACKERS

       BIND9  is  a name server implementation with its own configuration file
       format, named.conf(5). BIND9 types zones as 'Master' or 'Slave'.

   Slave zones
       For a slave zone, the master servers are listed. The master servers are
       queried  for  zone  data, and are listened to for update notifications.
       In NSD these two  properties  need  to  be  configured  separately,  by
       listing the master address in allow-notify and request-xfr statements.

       In  BIND9  you only need to provide allow-notify elements for any extra
       sources of notifications  (i.e.  the  operators),  NSD  needs  to  have
       allow-notify  for  both  masters and operators. BIND9 allows additional
       transfer sources, in NSD you list those as request-xfr.

       Here is an example of a slave zone in BIND9 syntax.

       # Config file for example.org options {
            dnssec-enable yes;
       };

       key tsig.example.org. {
            algorithm hmac-md5;
            secret "aaaaaabbbbbbccccccdddddd";
       };

       server 162.0.4.49 {
            keys { tsig.example.org. ; };
       };

       zone "example.org" {
            type slave;
            file "secondary/example.org.signed";
            masters { 162.0.4.49; };
       };

       For NSD, DNSSEC is enabled automatically for zones that are signed. The
       dnssec-enable  statement  in  the  options clause is not needed. In NSD
       keys are associated with an IP  address  in  the  access  control  list
       statement, therefore the server{} statement is not needed. Below is the
       same example in an NSD config file.

       # Config file for example.org
       key:
            name: tsig.example.org.
            algorithm: hmac-md5
            secret: "aaaaaabbbbbbccccccdddddd"

       zone:
            name: "example.org"
            zonefile: "secondary/example.org.signed"
            # the master is allowed to notify and will provide zone data.
            allow-notify: 162.0.4.49 NOKEY
            request-xfr: 162.0.4.49 tsig.example.org.

       Notice that the master is listed  twice,  once  to  allow  it  to  send
       notifies  to  this slave server and once to tell the slave server where
       to look for updates zone data. More allow-notify and request-xfr  lines
       can be added to specify more masters.

       It  is  possible to specify extra allow-notify lines for addresses that
       are also allowed to send notifications to this slave server.

   Master zones
       For a master zone in BIND9, the slave servers are listed.  These  slave
       servers  are  sent  notifications of updated and are allowed to request
       transfer of the zone data. In NSD  these  two  properties  need  to  be
       configured separately.

       Here is an example of a master zone in BIND9 syntax.

       zone "example.nl" {
            type master;
            file "example.nl";
       };

       In NSD syntax this becomes:

       zone:
            name: "example.nl"
            zonefile: "example.nl"
            # allow anybody to request xfr.
            provide-xfr: 0.0.0.0/0 NOKEY
            provide-xfr: ::0/0 NOKEY

            # to list a slave server you would in general give
            # provide-xfr: 1.2.3.4 tsig-key.name.
            # notify: 1.2.3.4 NOKEY

   Other
       NSD is an authoritative only DNS server. This means that it is meant as
       a primary or secondary server for zones,  providing  DNS  data  to  DNS
       resolvers  and  caches.  BIND9  can  function  as  an authoritative DNS
       server, the configuration options for that are compared with those  for
       NSD  in this section. However, BIND9 can also function as a resolver or
       cache. The configuration options that BIND9 has  for  the  resolver  or
       caching thus have no equivalents for NSD.

FILES

       /var/lib/nsd3/nsd.db
              default NSD database

       /etc/nsd3/nsd.conf
              default NSD configuration file

SEE ALSO

       nsd(8),  nsdc(8),  nsd-checkconf(8),  nsd-notify(8), nsd-patch(8), nsd-
       xfer(8), zonec(8)

AUTHORS

       NSD was written by NLnet Labs and  RIPE  NCC  joint  team.  Please  see
       CREDITS file in the distribution for further details.

BUGS

       nsd.conf  is parsed by a primitive parser, error messages may not be to
       the point.