Provided by: nsd3_3.2.5-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.

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

       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. Default is yes.

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

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

   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.