"Fossies" - the Fresh Open Source Software Archive

Member "nsd-4.3.7/doc/README" (22 Jul 2021, 30699 Bytes) of package /linux/misc/dns/nsd-4.3.7.tar.gz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. See also the latest Fossies "Diffs" side-by-side code changes report for "README": 4.3.6_vs_4.3.7.

    1 1.0 Introduction
    2 1.1 ... Basic theory of operation
    3 1.2 ... Quick build & install
    4 2.0 Building nsd
    5 2.1 ... Unpacking the source
    6 2.2 ... Configuring NSD
    7 2.3 ... Building
    8 2.4 ... Installing
    9 3.0 Running NSD
   10 3.1 ... Logging
   11 3.2 ... AXFR access
   12 3.3 ... Using TSIG
   13 3.4 ... Zone expiry of secondary zones
   14 3.5 ... Diagnosing NSD log entries
   15 3.6 ... Interfaces
   16 3.7 ... Tuning
   17 4.0 Support and Feedback
   18 4.1 ... Your Support
   21 1.0 Introduction
   23 This is NSD Name Server Daemon (NSD) version 4.3.7.
   25 The NLnet Labs Name Server Daemon (NSD) is an authoritative RFC compliant 
   26 DNS nameserver. It was first conceived to allow for more genetic 
   27 diversity for DNS server implementations used by the root-server system 
   28 and it has been developed for operations in environments where speed, 
   29 reliability, stability, and security are of high importance. NSD is 
   30 currently used on root servers such as k.root-servers.net and is also in 
   31 use by several top-level domain registries.
   33 NSD is a complete implementation of an authoritative DNS name server.
   34 For further information about what NSD is and what NSD is not please
   35 consult the REQUIREMENTS document which is a part of this distribution.
   37 If you are a BIND user (the named daemon) consult NSD_FOR_BIND_USERS.
   39 The source code is available for download from:
   41          http://www.nlnetlabs.nl/downloads
   44 1.1 Basic Theory of Operation
   46 NSD consists of two programs: the zone compiler 'zonec' and the name
   47 server 'nsd' itself. The name server works with an intermediate
   48 database prepared by the zone compiler from standard zone files.
   50 For NSD operation this means that zones have to be compiled by zonec
   51 before NSD can use them.
   53 All this can be controlled via rc.d (SIGTERM, SIGHUP) or nsd-control,
   54 and uses a simple configuration file 'nsd.conf'.
   57 1.2 Quick build and install
   59 Step 1: Unpack the source with gtar -xzvf nsd-4.3.7.tar.gz
   61 Step 2: Create user nsd or any other unprivileged user of your
   62         choice. In case of later make sure to use
   63         --with-user=<username> while running configure.
   64 	You can also set "username: <name>" in the nsd.conf file later.
   65 	Install openssl and libevent.
   67 Step 3: ./configure
   69 Step 4: make all	(or simply 'make').
   71 Step 5: make install
   73 Step 6: Create and edit /etc/nsd/nsd.conf file possibly from
   74         nsd.conf.sample template that comes with the distribution.
   75 	(installed by default at /etc/nsd/nsd.conf.sample)
   76 	Here you need to configure the zones you want to serve.
   77 	TSIG keys used for secure zone transfers must be included.
   78 	Also server parameters can be set, see nsd.conf(5) man page.
   80 	If you have a NSD 2 nsd.zones config file take a look at the
   81 	python script contrib/nsd.zones2nsd.conf, it will convert 
   82 	zone and TSIG key settings for you.
   84 Step 7: Copy necessary master zone files into appropriate directories
   85         under /etc/nsd/primary & /etc/nsd/secondary. 
   87 Step 8: Run nsd-control start
   89 Step 9: Test the NSD with dig, drill or host.
   91 Step 10: If you're happy add a rc.d script to start into your OS boot up
   92 	 sequence. The format of the rc.d startup script depends on 
   93 	 the platform.  Also stop it in the shutdown sequence.
   94 	 You can use SIGTERM to stop, or nsd-control stop.
   96 Step 11: If desired add 'nsd-control write' to your superuser crontab to
   97          update the zone files with the content transferred from master
   98 	 servers periodically, such as once per day.
  100          Got any problems or questions with the steps above? Read the
  101          rest of this file.
  105 2.0 Building NSD
  108 2.1 Unpacking the source
  110 Use your favorite combination of tar and gnu zip to unpack the source,
  111 for example
  113 $ gtar -xzvf nsd-4.3.7.tar.gz
  115 will unpack the source into the ./nsd-4.3.7 directory...
  118 2.2 Configuring NSD
  120 NSD can be configured using GNU autoconf's configure script. In
  121 addition to standard configure options, one may use the following:
  123   CC=compiler
  125         Specify the C compiler.  The default is gcc or cc.  The
  126         compiler must support ANSI C89.
  128   CPPFLAGS=flags
  130         Specify the C preprocessor flags.  Such as -I<includedir>.
  132   CFLAGS=flags
  134         Specify the C compiler flags.  These include code generation,
  135         optimization, warning, and debugging flags.  These flags are
  136         also passed to the linker.
  138         The default for gcc is "-g -O2".
  140   LD=linker
  142         Specify the linker (defaults to the C compiler).
  144   LDFLAGS=flags
  146         Specify linker flags.
  148   LIBS=libs
  150         Specify additional libraries to link with.
  152   --enable-root-server
  154         Configure NSD as a root server. Unless this option is
  155         specified, NSD will refuse to serve the ``.'' zone as a
  156         misconfiguration safeguard.
  158   --disable-ipv6
  160         Disables IPv6 support in NSD.
  162   --enable-checking
  164         Enable some internal development checks.  Useful if you want
  165         to modify NSD.  This option enables the standard C "assert" macro
  166 	and compiler warnings.
  168 	This will instruct NSD to be stricter when validating its input. 
  169 	This could lead to a reduced service level.
  171   --enable-bind8-stats
  173         Enables BIND8-like statistics.
  175   --enable-ratelimit
  177 	Enables ratelimiting, based on query name, type and source.
  179    --enable-draft-rrtypes
  181 	Enables draft RRtypes.
  183   --with-configdir=dir
  185         Specified, NSD configuration directory, default /etc/nsd
  187   --with-nsd_conf_file=path
  189 	Pathname to the NSD configuration file, default /etc/nsd/nsd.conf
  191   --with-pidfile=path
  193         Pathname to the NSD pidfile, default is platform specific,
  194         mostly /var/run/nsd.pid
  196   --with-dbfile=path
  198         Pathname to the NSD database, default is /etc/nsd/nsd.db
  200   --with-zonesdir=dir
  202         NSD default location for master zone files, default /etc/nsd/
  204   --with-user=username
  206         User name or ID to answer the queries with, default is nsd
  208   --with-facility=facility
  210         Specify the syslog facility to use.  The default is
  211         LOG_DAEMON.  See the syslog(3) manual page for the available
  212         facilities.
  214   --with-libevent=path
  216   	Specity the location of the libevent library (or libev).
  217 	--with-libevent=no uses a builtin portable implementation (select()).
  219   --with-ssl=path
  221         Specify the location of the OpenSSL libraries.  OpenSSL 0.9.7
  222         or higher is required for TSIG support.
  224   --with-start_priority=number
  226 	Startup priority for NSD. 
  228   --with-kill_priority=number
  230 	Shutdown priority for NSD. 
  232   --with-tcp-timeout=number
  234 	Set the default TCP timeout (in seconds). Default 120 seconds.
  236   --disable-nsec3
  238   	Disable NSEC3 support. With NSEC3 support enabled, very large zones,
  239 	also non-nsec3 zones, use about 20% more memory.
  241   --disable-minimal-responses
  243   	Disable minimal responses. If disabled, responses are more likely
  244 	to get truncated, resulting in TCP fallback.  When enabled (by default)
  245 	NSD will leave out RRsets to make responses fit inside one datagram,
  246 	but for shorter responses the full normal response is carried.
  248   --disable-largefile
  250 	Disable large file support (64 bit file lengths). Makes off_t
  251 	a 32bit length during compilation.
  254 2.3 Building
  256 Use ``make'' to create NSD and support tools.  If you get errors, try to
  257 use ``gmake'' (gnu version of make), especially on old systems. If so,
  258 do a `gmake realclean` first, to remove stuff that the make call messed up.
  261 2.4 Installing
  263 Become a superuser (if necessary) and type ``make install''
  265 This step should install four binaries
  267 nsd               - the daemon itself
  268 nsd-control-setup - a shell script that creates keys for nsd-control.
  269 nsd-control	      - program that connects over SSL to nsd and gives commands.
  270 nsd-checkconf	  - simple C program to check nsd.conf before use.
  272 Plus the manual pages and a sample configuration file.
  275 3.0 Running NSD
  277 Before running NSD you need to create a configuration file for it.
  278 The config file contains server settings, secret keys and zone settings.
  280 The server settings start with a line with the keyword 'server:'.
  281 In the server settings set 'database: <file>' with the filename of the name 
  282 database that NSD will use. Set 'chroot: <dir>' to run nsd in a chroot-jail.
  283 Make sure the zone files, database file, xfrdfile, difffile and pidfile
  284 can be accessed from the chroot-jail.  Set 'username: <user>' to an 
  285 unprivileged user, for security.  
  287 For example:
  288 	# This is a sample configuration
  289 	server:
  290 		database: "/etc/nsd/nsd.db"
  291 		pidfile: "/etc/nsd/nsd.pid"
  292 		chroot: "/etc/nsd/"
  293 		username: nsd
  295 After the global server settings to need to make entries for the
  296 zones that you wish to serve. For each zone you need to list the zone
  297 name, the file name with the zone contents, and access control lists.
  299 	zone:
  300 		name:	"example.com"
  301 		zonefile: "example.com.zone"
  303 The zonefile needs to be filled with the correct zone information
  304 for master zones. For secondary zones an empty file will suffice,
  305 a zone transfer will be initiated to obtain the slave zone contents.
  307 Access control lists are needed for zone transfer and notifications.
  309 For a slave zone list the masters, by IP address. Below is an example
  310 of a slave zone with two master servers. If a master only supports AXFR
  311 transfers and not IXFR transfers (like NSD), specify the master as
  312 "request-xfr: AXFR <ip_address> <key>". By default, all zone transfer requests 
  313 are made over TCP. If you want the IXFR request be transmitted over UDP, use
  314 "request-xfr: UDP <ip address> <key>".
  316 	zone:
  317 		name: "example.com"
  318 		zonefile: "example.com.zone"
  319 		allow-notify: NOKEY
  320 		request-xfr: NOKEY
  321 		allow-notify: NOKEY
  322 		request-xfr: NOKEY
  324 By default, a slave will fallback to AXFR requests if the master told us it does 
  325 not support IXFR. You can configure the slave not to do AXFR fallback with:
  327 		allow-axfr-fallback: "no"
  329 For a master zone, list the slave servers, by IP address or subnet.
  330 Below is an example of a master zone with two slave servers.
  332 	zone:
  333 		name: "example.com"
  334 		zonefile: "example.com.zone"
  335 		notify: NOKEY
  336 		provide-xfr: NOKEY
  337 		notify: NOKEY
  338 		provide-xfr: NOKEY
  340 You also can set the outgoing interface for notifies and zone transfer requests 
  341 to satisfy access control lists at the other end:
  343 		outgoing-interface:
  345 By default, NSD will retry a notify up to 5 times. You can override that
  346 value with: 
  348 		notify-retry: 5
  350 Zone transfers can be secured with TSIG keys, replace NOKEY with
  351 the name of the tsig key to use. See section 3.3.
  353 Since NSD is written to be run on the root name servers, the config file 
  354 can to contain something like:
  356 	zone:
  357 		name: "."
  358 		zonefile: "root.zone"
  359 		provide-xfr: NOKEY # allow axfr for everyone.
  360 		provide-xfr: ::0/0 NOKEY
  362 You should only do that if you're intending to run a root server, NSD
  363 is not suited for running a . cache. Therefore if you choose to serve
  364 the .  zone you have to make sure that the complete root zone is
  365 timely and fully updated.
  367 To prevent misconfiguration, NSD configure has the --enable-root-server
  368 switch, that is by default disabled.
  370 In the config file, you can use patterns.  A pattern can have the
  371 same configuration statements that a zone can have.  And then you can
  372 include-pattern: <name-of-pattern> in a zone (or in another pattern)
  373 to apply those settings.  This can be used to organise the settings.
  375 The nsd-control tool is also controlled from the nsd.conf config file.
  376 It uses SSL encrypted transport to, and if you want to use it
  377 you have to setup the keys and also edit the config file.  You can leave
  378 the remote-control disabled (the secure default), or opt to turn it on:
  380 	# generate keys
  381 	nsd-control-setup
  383 	# edit nsd.conf to add this
  384 	remote-control:
  385 		control-enable: yes
  387 By default nsd-control is limited to localhost, as well as encrypted, but
  388 some people may want to remotely administer their nameserver.  What you
  389 then do is setup nsd-control to listen to the public IP address, with
  390 control-interface: <IP> after the control-enable statement.  Furthermore,
  391 you copy the key files /etc/nsd/nsd_server.pem /etc/nsd/nsd_control.*
  392 to a remote host on the internet; on that host you can run nsd-control
  393 with -c <special config file> which references same IP address
  394 control-interface and references the copies of the key files with
  395 server-cert-file, control-key-file and control-cert-file config lines
  396 after the control-enable statement.  The nsd-server authenticates the
  397 nsd-control client, and also the nsd-control client authenticates the
  398 nsd-server.
  400 When you are done with the configuration file, check the syntax using
  402 	nsd-checkconf <name of configfile>
  404 The zone files are read by the daemon, which builds 'nsd.db' with their
  405 contents.  You can start the daemon with
  407 	nsd
  408 	or with "nsd-control start" (which execs nsd again).
  409 	or with nsd -c <name of configfile>
  411 To check if the daemon is running look with ps, top, or if you enabled
  412 nsd-control,
  414 	nsd-control status
  416 To reload changed zone files after you edited them, without stopping
  417 the daemon, use this to check if files are modified: 
  419 	kill -HUP `cat <name of nsd pidfile>`
  421 If you enabled nsd-control, you can reread with
  423 	nsd-control reload
  425 With nsd-control you can also reread the config file (new zones, ..)
  427 	nsd-control reconfig
  429 To restart the daemon
  431 	/etc/rc.d/nsd restart  # or your system(d) equivalent
  433 To shut it down (for example on the system shutdown) do
  435 	kill -TERM <pid of nsd>
  436 	or nsd-control stop
  438 NSD will automatically keep track of secondary zones and update them
  439 when needed. When primary zones are updated and reloaded notifications
  440 are sent to slave servers.
  442 The zone transfers are applied to nsd.db by the daemon.  To write changed
  443 contents of the zone files for slave zones to disk in the text-based zone
  444 file format, issue nsd-control write.
  446 NSD will send notifications to slave zones if a master zone is updated.
  447 NSD will check for updates at master servers periodically and transfer
  448 the updated zone by AXFR/IXFR and reload the new zone contents. If
  449 you wish exert manual control use nsd-control notify, transfer and
  450 force_transfer commands.  The transfer command will check for new versions
  451 of the secondary zones hosted by this NSD. The notify command will send
  452 notifications to the slave servers configured in 'notify:' statements.
  455 3.1 Logging
  457 NSD doesn't do any logging. We believe that logging is a separate task
  458 and has to be done independently from the core operation.
  460 This consciously is not part of nsd itself in order to keep nsd
  461 focused and minimize its complexity. It is better to leave logging and
  462 tracing to separate dedicated tools. dnsstat can also easily be
  463 configured and/or modified to suit local statistics requirements
  464 without any danger of affecting the name server itself. We have run
  465 dnsstat on the same machine as nsd, we would recommend using a
  466 multiprocessor if performance is an issue. Of course it can also run
  467 on a separate machine that has MAC layer access to the network of the
  468 server.
  470 The nsd-control tool can output some statistics, with nsd-control stats
  471 and nsd-control stats_noreset.  In contrib/nsd_munin_ there is a munin
  472 grapher plugin that uses it.  The output of nsd-control stats is easy
  473 to read (text only) with scripts.  The output values are documented on
  474 the nsd-control man page.
  476 The CAIDA dnsstat tool referenced is recommended to nsd operators as a 
  477 means of keeping statistics and check on abnormal query loads.
  479     http://www.caida.org/tools/utilities/dnsstat/dnsstat-3.5.1a.tar.gz
  481 Another tool is the dnstop, that displays DNS statistics on your network.
  483     http://dns.measurement-factory.com/tools/dnstop/src/dnstop-20060517.tar.gz
  485 A sample invocation of dnsstat:
  487 /usr/local/Coral/bin/crl_dnsstat -D -Ci=60 -Cd=240 -C'filter dst'  -h -u if:fxp1
  489 A sample output of a slightly modified version:
  491 # dnsstat output version: 0.2 "dfk"
  493 # begin trace interval at 1025267664.859043, duration 15.000000
  494 # DNS messages: 74973 (4998.200000/s); DNS queries: 151983 (10132.200000/s)
  495 # print threshold: 30 messages/sec
  497 #src              op type  class queries    msgs      rd notes
  498     - -     -         533     533       0
  499  "                 0 MX    IN          6
  500  "                 0 A     IN        264
  501  "                 0 ANY   IN        263
  502     - -     -         661     661       0
  503  "                 0 A     IN        655
  504  "                 0 MX    IN          6
  505    - -     -         745     745       0
  506  "                 0 A     IN        745
  507    - -     -         477     477       0
  508  "                 0 A     IN        477
  509     - -     -         681     681       0
  510  "                 0 A     IN          3
  511  "                 0 ANY   IN        678
  512     - -     -         685     685       0
  513  "                 0 A     IN        405
  514  "                 0 MX    IN        280
  515       - -     -         742     742       0
  516  "                 0 A     IN        742
  517      - -     -        1375    1375       0
  518  "                 0 A     IN       1375
  519     - -     -         493     493       0
  520  "                 0 A     IN        493
  521   - -     -        5579    5579       0
  522  "                 0 A     IN       3006
  523  "                 0 MX    IN       2573
  524      - -     -         700     700       0
  525  "                 0 A     IN        700
  526 # end trace interval 
  529 3.2 AXFR access
  531 The access list for AXFR should be set with provide-xfr:
  532 in the nsd config file. This is per zone. See nsd.conf(5).
  533 For example to grant zone 'example.com' AXFR right to localhost for
  534 IPv4 and IPv6, use the below config options.
  536 zone:
  537 	name: "example.com"
  538 	provide-xfr: NOKEY
  539 	provide-xfr: ::1 NOKEY
  541 You can use dig @localhost example.com axfr to test this.
  544 3.3 Using TSIG
  546 NSD supports TSIG for any query to the server, for zone transfer
  547 and for notify sending and receiving.
  549 TSIG keys are based on shared secrets. These must be configured
  550 in the config file. To keep the secret in a separate file use 
  551 include: "filename" to include that file.
  553 An example tsig key named sec1_key.
  555 	key:
  556 		name: "sec1_key"
  557 		algorithm: hmac-md5
  558 		secret: "6KM6qiKfwfEpamEq72HQdA=="
  560 This key can then be used for any query to the NSD server. NSD
  561 will check if the signature is valid, and if so, return a signed
  562 answer. Unsigned queries will be given unsigned replies.
  564 The key can be used to restrict the access control lists, for
  565 example to only allow zone transfer with the key, by listing
  566 the key name on the access control line.
  568 	# provides AXFR to the subnet when TSIG is used.
  569 	provide-xfr: sec1_key
  570 	# allow only notifications that are signed
  571 	allow-notify: sec1_key
  573 If the TSIG key name is used in notify or request-xfr lines,
  574 the key is used to sign the request/notification messages.
  577 3.4 Zone expiry of secondary zones
  579 NSD will keep track of the status of secondary zones, according to the 
  580 timing values in the SOA record for the zone.  When the refresh time of a
  581 zone is reached, the serial number is checked and a zone transfer is
  582 started if the zone has changed.  Each master server is tried in turn.
  584 Master zones cannot expire.  They are always served.  Zones are master
  585 zones if they have no 'request-xfr:' statements in the config file.
  587 After the expire timeout (from the SOA record at the zone apex) is reached,
  588 the zone becomes expired. NSD will return SERVFAIL for expired zones,
  589 and will attempt to perform a zone transfer from any of the masters.
  590 After a zone transfer succeeds, or if the master indicates that the SOA 
  591 serial number is still the same, the zone will be OK again.
  593 In contrast with e.g. BIND, the inception time for a slave zone is stored
  594 on disk (in the xfrdfile: "xfrd.state"), together with timeouts.  If a
  595 slave zone acquisition time is recent enough, this means that NSD can start
  596 serving a zone immediately on loading, without querying the master server.
  598 If your slave zone has expired, and no masters can be reached, but you 
  599 still want NSD to serve the zone.  (i.e. ''My network is in shambles, but
  600 serve the zone dangit!'').  You can delete the file 'xfrd.state',
  601 but leave the zonefile for the zone intact.  Make sure to stop nsd before
  602 you delete the file, as NSD writes it on exit.  Upon loading NSD will treat
  603 the zonefile that you as operator have provided as recent and will serve
  604 the zone.  Even though NSD will start to serve the zone immediately,
  605 the zone will expire after the timeout is reached again.  NSD will also
  606 attempt to confirm that you have provided the correct data by polling 
  607 the masters.  So when the master servers come back up, it will transfer
  608 the updated zone within <retry timeout from SOA> seconds.
  610 In general it is possible to provide zone files for both master and
  611 slave zones manually (say from email or rsync). Reload with SIGHUP
  612 or nsd-control reload to read the new zonefile contents into the name
  613 database.  When this is done the new zone will be served. For master
  614 zones, NSD will issue notifications to all configured 'notify:' targets.
  615 For slave zones the above happens; NSD attempts to validate the zone
  616 from the master (checking its SOA serial number).
  619 3.5 Diagnosing NSD log entries
  621 NSD will print log messages to the system log (or 'logfile:' configuration
  622 entry). Some of these messages are discussed below. These messages can
  623 get extra support if errors happen.
  625 - "Reload process <pid> failed with status <s>, continuing with old database"
  627 This log message indicates the reload process of NSD has failed for
  628 some reason.  The reason can be anything from a missing database file
  629 to internal errors.  If this happens often, please let us know, this
  630 error message can be caught in the code, and appropriate action could
  631 be taken.  We are as of yet not sure what action is appropriate, if any.
  633 - "snipping off trailing partial part of <ixfr.db>"
  635 Please let us know if, and how often, this happens.
  637 What happens is the file ixfr.db contains only part of expected data.
  638 The corruption is removed by snipping off the trailing part.
  640 - "memory recyclebin holds <num> bytes"
  642 This is printed for every reload. NSD allocates and deallocates memory
  643 to service IXFR updates. The recyclebin holds deallocated memory ready
  644 for future use. If the number grows too large, a restart resets it.
  646 - "xfrd: max number of tcp connections (32) reached."
  648 This line is printed when more than 32 zones need a zone transfer at the
  649 same time.  The value is a compile constant (xfrd-tcp.h), but if this
  650 happens often for you, we could make this a config option.  NSD will reuse
  651 existing TCP connections to the same master (determined by IP address)
  652 to transfer up to 64k zones from that master.  Thus this error should
  653 only happen with more than 32 masters or more than 64*32=2M zones that
  654 need to be updated at the same time.
  656 If this happens, more zones have to wait until a zone transfer completes
  657 (or is aborted) before they can have a zone transfer too. This waiting
  658 list has no size limit.
  660 - "error: <zone> NSEC3PARAM entry <num> has unknown hash algo <number>"
  662 This error means that the zone has NSEC3 chain(s) with hash algorithms
  663 that are not supported by this version of NSD, and thus cannot be served
  664 by NSD.  If there are also no NSECs or NSEC3 chain(s) with known hash
  665 algorithms, NSD will not be able to serve DNSSEC authenticated denials
  666 for the zone.
  669 3.6 Interfaces
  671 NSD will by default bind itself to the system default interface and
  672 service ip4 and if available also ip6. It is possible to service only ip4
  673 or ip6 using the -4, -6 commandline options, or the ip4-only and ip6-only
  674 config file options.
  676 The commandline option -a and config file option ip-address can be given
  677 to bind to specific interfaces.  Multiple interfaces can be specified.
  678 This is useful for two reasons:
  679 	o The specific interface bound will result in the OS bypassing
  680 	  routing tables for the interface selection.  This results in
  681 	  a small performance gain.  It is not the performance gain that
  682 	  is the problem, sometimes the routing tables can give the
  683 	  wrong answer, see the next point.
  684 	o The answer will be routed via the interface the query came from.
  685 	  This makes sure that the return address on the DNS replies is the
  686 	  same as the query was sent to.  Many resolvers require the source
  687 	  address of the replies to be correct.  The ip-address: option is
  688 	  easier than configuring the OS routing table to return the DNS
  689 	  replies via the correct interface.
  690 The above means that even for systems with multiple interfaces where you
  691 intend to provide DNS service to all interfaces, it is prudent to specify
  692 all the interfaces as ip-address config file options.
  694 With the config file option ip-transparent you can allow NSD to bind to
  695 non local addresses.
  698 3.7 Tuning
  700 NSD is performant by design and most users will have little need for tuning
  701 it. For setups that do require every ounce of performance, NSD offers a number
  702 of configuration options.
  705 cpu-affinity, server-<N>-cpu-affinity and xfrd-cpu-affinity
  707 Modern computer systems have many cores available. By default the operating
  708 system's scheduling-algorithm determines which core a given task is allocated
  709 to. Processors build up state, like keeping frequently accessed data in cache
  710 memory, for the task (process/thread) that it is currently running. Whenever,
  711 a task switches cores, performance is degraded because the core it switched
  712 to has yet to build up said state. The cpu-affinity configuration options can
  713 be used to bind NSD to one or more cores.
  715 cpu-affinity can be used to designate a set of cores onto which NSD processes
  716 are scheduled. server-<N>-cpu-affinity and xfrd-cpu-affinity can be used to
  717 designate a specific core to each individual process. This improves L1/L2
  718 cache hits and reduces pipeline stalls/flushes.
  720 For example, a name server configured to fork two NSD servers that must run on
  721 dedicated cores 0 and 2, while the transfer daemon (xfrd) must run on core 1,
  722 the configuration becomes.
  724 	server:
  725 		server-count: 2
  726 		cpu-affinity: 0 1 2
  727 		server-1-cpu-affinity: 0
  728 		server-2-cpu-affinity: 2
  729 		xfrd-cpu-affinity: 1
  732 ip-address: x.x.x.x  servers=<N>
  734 ip-address options can be configured per (set of) server(s). Sockets that are
  735 configured for a specific server are closed by other servers on startup. This
  736 improves select/poll performance and avoids waking up multiple servers when a
  737 packet comes in.
  740 ip-address: x.x.x.x  bindtodevice=yes
  741 ip-address: x.x.x.x  setfib=<N>
  743 The bindtodevice attribute on Linux and the setfib ip-address attribute on
  744 FreeBSD can be used to skip the interface selection process in the kernel. This
  745 improves performance, and ensures responses written to the socket are pushed
  746 out the same interface the corresponding query came in on when multiple
  747 interfaces are configured to listen on the same subnet.
  749 The aforementioned options all complement eachother and best performance is
  750 achieved by assigning a socket to a single server that runs on a dedicated
  751 core and line that up with a dedicated network interface. Network interface
  752 interrupts are best handled by a core not designated to any NSD servers.
  754 	server:
  755 		server-count: 3
  756 		cpu-affinity: 0 1 2 4
  757 		server-1-cpu-affinity: 0
  758 		server-2-cpu-affinity: 1
  759 		server-3-cpu-affinity: 2
  760 		xfrd-cpu-affinity: 4
  761 		ip-address:  servers=1 setfib=1 bindtodevice=yes
  762 		ip-address:  servers=2 setfib=2 bindtodevice=yes
  763 		ip-address:  servers=3 setfib=3 bindtodevice=yes
  765 The number of NSD servers to fork and which cores are best used depends
  766 entirely on the hardware. cpu-affinity options are supported on Linux and
  767 FreeBSD.
  770 4.0 Support and Feedback
  772 NLnet Labs is committed to support NSD and its other software products on 
  773 a best effort basis, free of charge. This form of community support is 
  774 offered through a mailing lists and the 'bugzilla' web interface. 
  776 	http://www.nlnetlabs.nl/bugs/
  778 If for any reason NLnet Labs would stop community support of NSD such 
  779 would be announced on our web pages at least two years in advance.
  781 The community mailing list nsd-users@nlnetlabs.nl can be used to discuss 
  782 issues with other users of NSD. Subscribe here
  784 	http://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
  786 NLnet Labs recognizes that in some corporate environments this commitment to
  787 community support is not sufficient and that support needs to be codified. 
  788 We therefore offer paid support contracts that come in 3 varieties. 
  790 More information about these support varieties can be found at 
  791 	<url on support varieties on www.nlnetlabs.nl>
  793 Alternatively you can contact mailto:nsd-support@nlnetlabs.nl .
  795 Support goes two ways.  By acquiring one of the support contracts you
  796 also support NLnet Labs to continue to participate in the development
  797 of the Internet architecture. We do this through our participation in
  798 the (IETF) standards process and by developing and maintaining
  799 reference implementations of standards and tools to support operation
  800 and deployment of new and existing Internet technology. 
  802 We are interested in our users and in the environment you use NSD. Please 
  803 drop us a mail when you use NSD. Indicate in what kind of operation you 
  804 deploy NSD and let us know what your positive and negative experiences are.
  805 http://www.nlnetlabs.nl/nsd  and  mailto:nsd-info@nlnetlabs.nl
  808 4.1 Your Support
  810 NLnet Labs offers all of its software products as open source, most are
  811 published under a BSD license. You can download them, not only from the
  812 NLnet Labs website but also through the various OS distributions for
  813 which NSD, ldns, and Unbound are packaged. We therefore have little idea
  814 who uses our software in production environments and have no direct ties
  815 with 'our customers'.
  817 Therefore, we ask you to contact us at users@NLnetLabs.nl and tell us
  818 whether you use one of our products in your production environment,
  819 what that environment looks like, and maybe even share some praise.
  820 We would like to refer to the fact that your organization is using our
  821 products. We will only do that if you explicitly allow us. In all other
  822 cases we will keep the information you share with us to ourselves.
  824 In addition to the moral support you can also support us
  825 financially. NLnet Labs is a recognized not-for-profit charity foundation
  826 that is chartered to develop open-source software and open-standards
  827 for the Internet. If you use our software to satisfaction please express
  828 that by giving us a donation. For small donations PayPal can be used. For
  829 larger and regular donations please contact us at users@NLnetLabs.nl. Also
  830 see http://www.nlnetlabs.nl/labs/contributors/.
  833 $Id$