Table des matières
Zone DNS faimaison.net
La zone faimaison.net est administrée sur philmore et servie par nsd.
Pour référence, voici la sortie d'un dig -t SOA
de la zone en fonctionnement normal :
;; QUESTION SECTION: ;faimaison.net. IN SOA ;; ANSWER SECTION: faimaison.net. 3403 IN SOA philmore.faimaison.net. adminsys.faimaison.net. 2020061203 10800 3600 604800 3600 ;; AUTHORITY SECTION: faimaison.net. 1454 IN NS philmore.faimaison.net. faimaison.net. 1454 IN NS bosco.faimaison.net. faimaison.net. 1454 IN NS ns6.gandi.net. ;; ADDITIONAL SECTION: philmore.faimaison.net. 1339 IN A 89.234.177.205 bosco.faimaison.net. 1454 IN A 91.224.149.122 philmore.faimaison.net. 1355 IN AAAA 2a00:5881:1040:100::53 bosco.faimaison.net. 1454 IN AAAA 2a03:7220:8081:7a00::53 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jun 12 08:55:11 CEST 2020 ;; MSG SIZE rcvd: 286
Modification de la zone
Philmore fait office de DNS maître, la configuration se fait donc dessus.
ssh philmore.faimaison.net
- passer en root avec
sudo -i
cd /etc/nsd/master
cp db.faimaison.net db.faimaison.net.orig
# backup avant de faire une modification :)nano db.faimaison.net
- rajouter/supprimer/modifier des entrées
- remplacer le serial par la date courante (tout en haut du fichier)
- vérifier avec adminsys@ # optionnel, si on n'est pas sûr de soit
- Recharger la zone dns avec
service nsd reload
Reverse-DNS
(voir aussi Adresses publiques)
La gestion du reverse-DNS de nos blocs IPv4 et IPv6 nous est déléguée. Elle est donc gérée par nsd, comme les enregistrements DNS, dans un fichier de zone. La seule chose qui peut être déroutante est que seule la fin (dernier octet) de l'adresse est mentionée dans le fichier de zone.
Par exemple, l'enregistrement de reverse-DNS pour 89.234.176.252, s'écrit, dans /etc/nsd/master/db.176.234.89.in-addr.arpa :
252 IN PTR fresk.faimaison.net.
Pour trouver le reserve-DNS d'une ip, par exemple de l'IPv6 2a00:5881:1040:100::53
, on peut utiliser la commande dig
de la façon suivante:
dig -x 2a00:5881:1040:100::53
La réponse DNS affichée sera:
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> -x 2a00:5881:1040:100::53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61996 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.4.0.1.1.8.8.5.0.0.a.2.ip6.arpa. IN PTR ... reste de la réponse ...
La section qui nous intéresse est QUESTION SECTION:
. Ici, question posée par la commande dig
est:
3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.4.0.1.1.8.8.5.0.0.a.2.ip6.arpa. IN PTR
C'est cette ligne qu'il faudra utilisée dans le fichier de zone reverse.
Délégation DNS
Certains membres nous demandent s'il est possible qu'ils gèrent eux-même les reverse DNS liés à leurs IPv4 et leurs IPv6.
C'est possible, la procédure change peu. Il faut que le membre ait au moins deux serveurs DNS qui pourront répondre aux requêtes PTR
pour sa zone.
Exemple en IPv6 pour le sous-réseau 2a00:5881:1044:d300::/56
:
3.d.4.4.0.1.1.8.8.5.0.0.a.2.ip6.arpa. NS ns1.example.org. 3.d.4.4.0.1.1.8.8.5.0.0.a.2.ip6.arpa. NS ns2.example.org.
En IPv4 c'est un poil plus compliqué, on ne souhaite déléguer le reverse que pour une seule IPv4 à la fois. Exemple pour l'adresse 89.234.176.19
:
19 CNAME 19.19/32 19/32 NS ns1.example.org. 19/32 NS ns2.example.org.
Pour plus de détails sur le méchanisme utilisé pour IPv4, voir la RFC2317.
Vérification des modifications
Les commandes suivantes peuvent être utilisées pour vérifier les enregistrements ajoutés, modifiés ou supprimés. Ces commandes envoient une requête DNS au serveur DNS de FAImaison. La configuration doit donc avoir été rechargée après les modifications.
- Pour tester l'enregistrement nom → IPv4:
dig @philmore.faimaison.net A NOM
- Pour tester l'enregistrement nom → IPv6:
dig @philmore.faimaison.net AAAA NOM
- Pour tester l'enregistrement inverse IPv4 ou IPv6 → nom:
dig @philmore.faimaison.net -x IPv4_ou_IPv6
Esclave DNS pour d'autres FAI de la fédération
Pas à jour ? Recette non utilisée depuis sa création.
Il y a une recette ansible nsd-slave.yml
, pour configurer des zones pour lesquelles notre serveur DNS fait office d'esclave, c'est-à-dire qu'il peut répondre aux requêtes de la zone en faisant autorité à la place du maître si on lui demande.
Le serveur esclave prend le contenu de la zone DNS depuis le serveur maître à intervalles réguliers.
La configuration du maître est laissée à la discrétion des adminsys de l'autre FAI Pour l'instant le transfert de zone a été testé avec succès et TSIG depuis un bind et depuis nsd.
Le principe de fonctionnement de la recette ansible est le suivant :
- un fichier de configuration contient les informations de chaque zone : il est lu par ansible pour générer un fichier par zone servie
- ces fichiers de zone sont inclus depuis un fichier
slaves.zones
qui est regénéré à chaque exécution de la recette en même temps que les fichiers de zones en eux même.
Ensuite le fichier de configuration principal inclut le fichier de zone slave (la recette s'assure que c'est toujours le cas).
Configuration des zones
Voici un exemple de fichier de configuration pour la recette :
zones: autre-fai.tld: reverse: 0.168.192.in-addr.arpa ip: 192.168.0.7 tsig: true key_name: faimaison-autreFAI secret: stoi-le-secret
La clé autre-fai.tld
définit la zone pour laquelle on est esclave. ip
est nécessaire pour donner l'adresse IP du serveur maître à contacter, et reverse
donne la zone reverse.
Si l'option tsig
est à true
, la vérification de la clé du master sera activée, sinon ce sera le template de zone sans clé qui sera utilisé.
Avec TSIG, le nom de la clé doit être le même côté serveur maître et côté esclave, sinon la vérification est refusée. Le partage des clé sera de préférence à faire de manière chiffrée entre les adminsys de l'autre et les adminsys d'ici.
Pour référence, voici un exemple de ligne de commande pour générer la clé, côté maître :
dnssec-keygen -a HMAC-SHA1 -b 160 -n HOST ${FAINAME_HOSTNAME}-faimaison