Provided by: nsd3_3.2.2-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/db/nsd/nsd.db"
            username: nsd
            logfile: "/var/log/nsd.log"
            pidfile: "/var/run/nsd.pid"
            difffile: "/var/db/nsd/ixfr.db"
            xfrdfile: "/var/db/nsd/xfrd.state"

       zone:
            name: example.com
            # note that quotes are optional on the value
            zonefile: /etc/nsd/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.

       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>
              NSD  will  bind  to  the listed ip-address. Can be give multiple
              times to bind multiple  ip-addresses.  If  none  are  given  NSD
              listens to all IP addresses. 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/db/nsd/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.

       logfile: <filename>
              Log messages to the logfile. The default is to log to stderr and
              syslog. 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 TCP connections by each server.
              Default is 10. Same as commandline option -n.

       pidfile: <filename>
              Use  the  pid  file  instead  of  the platform specific default,
              usually /var/run/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/db/nsd/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/db/nsd/xfrd.state.

       xrfd-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.

       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.

       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.  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.

       notify: <ip-address> <key-name | NOKEY>
              Access  control  list.  The  listed  address  (a  secondary)  is
              notified  of  updates to this zone. 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).

       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 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.

   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 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 seperately, 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 seperately.

       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/db/nsd/nsd.db
              default NSD database

       /etc/nsd/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.