h1. NSD

"NSD":https://www.nlnetlabs.nl/projects/nsd/ est une alternative à bind pour la gestion d’une zone DNS

h2. Principe général

Un serveur de nom *primaire* pour une zone est un serveur hébergeant la zone déclarée en type « *master* » et étant déclaré en tant que « NS » pour cette zone.

Un serveur de nom *secondaire* pour une zone est un serveur hébergeant la zone déclarée en type « *slave* » et étant déclaré en tant que « NS » pour cette zone.

Du point de vue du client DNS, celui qui interroge le serveur pour résoudre un nom, il n'y a pas de notion de primaire ou secondaire. Tous les serveurs déclarés sur une zone seront interrogés tour à tout avec du round-robin pour répartir la charge.

<pre>

    temps          primaire              secondaire

      |               |                      |

      |    [modification d'une zone]         |

      |               |                      |

      |               |-----notificaiton---->|

      |               |        NOTIFY        |

      |               |                      |

      |               |<---téléchargement----|

      |               |      AXFR/IXFR       |

      |               |                      |

      |               |                      |

      |               |                      |

      |               |              [expiration du TTL]

      |               |                      |

      |               |<---téléchargement----|

      |               |      AXFR/IXFR       |

      |               |                      |

      v               v                      v

</pre>

Le serveur secondaire télécharge la zone depuis le primaire dans deux cas :

* La zone a été modifiée sur le primaire. Celui-ci notifie alors le secondaire de la présence d'une nouvelle version de la zone. Le secondaire initie le téléchargement par une requête AXFR (transfert de la zone complète) ou IXFR (transfert incrémental).

* Le TTL (Time To Live) expire sur le serveur secondaire. Celui-ci récupère une version fraîche de la zone depuis le primaire (idem, AXFR ou IXFR).

Il est possible de forcer l'envoi d'une notification depuis le primaire afin de mettre à jour les zones sur tous les secondaires configurés. Cela est utile dans le cas où le(s) secondaire(s) étaient inaccessibles au moment de la mise à jour d'une zone. Cela permet de ne pas avoir à attendre l'expiration du TTL sur les secondaires.

Dans le cas d'un transfert incrémental (IXFR), le serveur secondaire indique au primaire le numéro de série de la zone qu'il connaît et le serveur primaire retourne uniquement les différences avec la zone active.

h2. Installation de NSD

Ce guide est écrit pour nsd4 et debian jessie, mais ça ne change pas grand chose avec nsd3 et debian wheezy (ou même gentoo ou arch)

<pre>

root@debianjessie:~ # apt-get install nsd

</pre>

h3. Configuration de NSD

<pre>

root@debianjessie:~# vim /etc/nsd/nsd.conf

</pre>

Votre fichier de configuration doit ressembler à un truc du genre :

<pre>

server:

	ip-address:	192.0.2.1

	ip-address:	198.51.100.1

	ip-address:	2001:db8:1::192

	ip-address:	2001:db8:3::198

	port:		53

	# ici ça va jouer sur ce qu’un nmap verra

	hide-version:	no

	identity:	"Mon cher petit poney, voilà qui va éclairer ton nmap"

	# Si l’on veut logguer les requêtes et faire des statistiques 

	logfile:	"/var/log/nsd.log"

	statistics:	3600

	pidfile:	"/var/run/nsd/nsd.pid"

	# nombre de serveurs démarrés

	server-count:	1

	username:	nsd

	zonesdir:	"/etc/nsd/"

	xfrdfile:	"/var/lib/nsd/xfrd.state"

	verbosity:	0

	# Nombre de requêtes par seconde et par IP, voir https://www.nlnetlabs.nl/blog/2012/10/11/nsd-ratelimit/

	rrl-ratelimit:	20

remote-control:

	# Enable remote control with nsd-control(8) here.

	# set up the keys and certificates with nsd-control-setup.

	control-enable: yes

	# what interfaces are listened to for control, default is on localhost.

	control-interface: 127.0.0.1

	control-interface: ::1

	# port number for remote control operations (uses TLS over TCP).

	control-port: 8952

	# nsd server key file for remote control.

	server-key-file: "/etc/nsd/nsd_server.key"

	# nsd server certificate file for remote control.

	server-cert-file: "/etc/nsd/nsd_server.pem"

	# nsd-control key file.

	control-key-file: "/etc/nsd/nsd_control.key"

	# nsd-control certificate file.

	control-cert-file: "/etc/nsd/nsd_control.pem"

key:

	name: tsig-name

	algorithm: hmac-sha256

	secret: "secret"

### masters ###

zone:

	name:		"swordarmor.fr"

	zonefile:	"swordarmor.fr.zone"

	notify:		2a01:6600:8081:c600::1	NOKEY

	provide-xfr:	2a01:6600:8081:c600::1	NOKEY

	notify:		217.70.177.40		NOKEY

	provide-xfr:	217.70.177.40		NOKEY

	notify:		2001:910:1318::1	tsig-name

	provide-xfr:	2001:910:1318::1	tsig-name

### reverses ###

# ttn.swordarmor.fr v4 (délégation sur CNAME)

zone:

	name:		"198/32.149.224.91.in-addr.arpa"

	zonefile:	"ttn.swordarmor.fr.reversev4"

	notify:		2a01:6600:8081:c600::1 NOKEY

	provide-xfr:	2a01:6600:8081:c600::1 NOKEY

# ttn.swordarmor.fr v6

zone:

	name:		"6.c.1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa"

	zonefile:	"ttn.swordarmor.fr.reversev6"

	notify:		2a01:6600:8081:c600::1 NOKEY

	provide-xfr:	2a01:6600:8081:c600::1 NOKEY

### slaves ###

zone:

	name:		"gozmail.net"

	zonefile:	"gozmail.net.zone"

	allow-notify:	2a02:a80:0:2216::2 NOKEY

	request-xfr:	2a02:a80:0:2216::2 NOKEY

	notify-retry:	5

</pre>

h3. Redémarrage

Une fois les modifications faites, il faut redémarrer NSD pour qu’elles soient prises en compte :

<pre>

root@debianjessie:~# service nsd restart 

</pre>

h2. Exemples de zones

h3. Zone principale (master)

Pour savoir comment remplir le SOA, je vous conseille de jeter un œil à "l’artcile wikipédia":https://fr.wikipedia.org/wiki/DNS#SOA_record

Le format des zones est le même qu’avec [[Bind]]

<pre>

$TTL	10800

@	IN	SOA	pokedex.swordarmor.fr. hostmaster.swordarmor.fr. (

			148           ; Serial

			3600          ; Refresh [1h]

			900           ; Retry   [15m]

			604800        ; Expire  [1w]

			600	      ; Negative Cache TTL [10m]

                        )

	IN	NS	pokedex.swordarmor.fr.

	IN	NS	alarig.tetaneutral.net.

	IN	NS	pokedex.glucas.fr.

	IN	MX	1 pokedex.swordarmor.fr.

	IN	MX	5 ttn.swordarmor.fr.

	IN	SPF	"v=spf1 mx -all"

pokedex	10800	IN	A	89.234.140.133

	10800	IN	AAAA	2001:470:1f13:138:715d:2fa0:b591:532f

	10800	IN	AAAA	2a00:5881:4008:400::1

	10800	IN	AAAA	2a01:240:fe00:82af:764f:b47e:d131:85e4

courriel	IN	A	91.224.149.198

			A	89.234.140.133

			AAAA	2a01:6600:8081:c600::1

			AAAA	2001:470:1f13:138:715d:2fa0:b591:532f

			AAAA	2a00:5881:4008:400::1

			AAAA	2a01:240:fe00:82af:764f:b47e:d131:85e4

vote	10800	IN	CNAME	pokedex

$ORIGIN _domainkey.swordarmor.fr.

_adsp	10800	IN	TXT	"all"

default	10800	IN	TXT	"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCfU42VmyfgW7S2Oui8ksSfJwQCfz0jWupl/cJI1Z7wV5o3FNo+DPOz/tpeGtsbYX11xK5AXjzaV4xnI5jGajQvxAYsER0Qbg8LPS9ShPIYrrJHeE30ktWdHr8dQKgrJVw4ZIx2kUpfnLwZkm+MqnVDTzDDhHBEc9vo3P29fQC2RwIDAQAB"

; reste de la zone

</pre>

h3. Zone secondaire (slave)

Dans le cas d’une zone secondaire, c’est le serveur principal et qui envoie la zone, et votre serveur l’écrit tout seul où on lui a demandé

h3. Zone reverse v4

Reverse pour 91.224.149.198 (ancien modèle)

<pre>

$ORIGIN 149.224.91.in-addr.arpa.

198\04732	864000	IN	SOA	ns0.swordarmor.fr. hostmaster.swordarmor.fr. (

		2 3600 900 1209600 43200 )

	864000	IN	NS	ns1.pennvad.eu.

	864000	IN	NS	alarig.tetaneutral.net.

$ORIGIN 198\04732.149.224.91.in-addr.arpa.

198	864000	IN	PTR	ttn.swordarmor.fr.

</pre>

Reverse pour 91.224.149.198 (nouveau modèle)

<pre>

$ORIGIN 149.224.91.in-addr.arpa.

198	864000	IN	SOA	ns0.swordarmor.fr. hostmaster.swordarmor.fr. (

		2 3600 900 1209600 43200 )

;	864000	IN	NS	ns1.pennvad.eu.

	864000	IN	NS	alarig.tetaneutral.net.

198	864000	IN	PTR	ttn.swordarmor.fr.

</pre>

h3. Zone reverse v6

<pre>

$ORIGIN 5.c.3.8.c.b.0.1.0.0.2.ip6.arpa.

6	864000	IN	SOA	ns1.pennvad.eu. hostmaster.swordarmor.fr. (

		5 3600 900 1209600 43200 )

	864000	IN	NS	ns1.pennvad.eu.

	864000	IN	NS	ttn.swordarmor.fr.

$ORIGIN 0.1.0.6.5.c.3.8.c.b.0.1.0.0.2.ip6.arpa.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0	864000	IN	PTR	ginette.swordarmor.fr.

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1	864000	IN	PTR	rodolphe.swordarmor.fr.

3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1	864000	IN	PTR	robert.swordarmor.fr.

</pre>

h2. Commandes principales

* nsd-control reload : recharger une zone après modification, bien penser à incrémenter le SOA avant

Exemples :

<pre>

nsd-control reload swordarmor.fr

nsd-control reload 6.5.c.3.8.c.b.0.1.0.0.2.ip6.arpa

</pre>

* nsd-control force_transfer : Forcer la mise à jour d’une zone vers les escalves

Exemples :

<pre>

nsd-control force_transfer swordarmor.fr # pour swordarmor.fr

nsd-control force_transfer # pour toutes les zones

</pre>

h2. Notes complémentaires

NSD a l’avantage d’être plus léger que bind, en grande partie car il n’est pas récursif, il ne fait que autorité. Si vous voulez installer un serveur récursif, son frère est unbound.

Voir aussi "le blog Bortz":https://www.bortzmeyer.org/nsd4.html