Provided by: nsd3_3.0.7-3_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:, zone:, or key: are allowed. These are
     followed by their attributes or the start of a new server:, 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.

   Server Options
     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 address>
             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 Fl 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 Fl d.

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

     ip6-only: <yes or no>
             If yes, NSD only listens to IPv6 connections. Same as commandline
             option Fl 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 Fl 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 Fl i.

     logfile: <filename>
             Log messages to the logfile. The default is to log to stderr and
             syslog.  Same as commandline option Fl l.

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

     tcp-count: <number>
             The maximum number of concurrent TCP connections by each server.
             Default is 10.  Same as commandline option Fl n.

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

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

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

     chroot: <directory>
             NSD will chroot on startup to the specified directory. Same as
             commandline option Fl 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 Fl u.

     zonesdir: <directory>
             Change the working directory to the specified directory before
             accessing zone files.  Same as commandline option Fl 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.

     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, and then 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] <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.

     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.

   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), nsd-checkconf(8), nsd-notify(8), nsd-patch(8), nsd-xfer(8),
     nsdc(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.