• Serveurs

  • [Discussion] Mettre en place un serveur DNS avec Bind9 et DNSSEC

Bonjour,

J'ai récemment fait l’acquisition d'in nom de domaine chez Gandi en partie pour m'essayer sur ce magnifique tuto. j'ai pris une extension .com et pourtant le service DNSSEC n'est pas actif.
bonjour,
Je viens de terminer le tuto avec succès. Toute ma gratitude pour ce travail mis à la disposition de toute la communauté.
Je voudrais poser une question concernant les enregistrements DMARC et DKIM
Dans ce syntaxe: 
mail._domainkey     IN                TXT                  "k=rsa; p=CLE PUBLIQUE DKIM"
_dmarc              IN                TXT                  "v=DMARC1; p=reject; rua=mailto:postmaster@domain.tld; ruf=mailto:admin@domain.tld; fo=0; adkim=s; aspf=s; pct=100; rf=afrf; sp=reject"
dans "mail._domainkey" qu'est ce qu'il faut mettre concretement? remplacer domain par mon nom de domaine???
aussi avec P=CLE PUBLIQUE DKIM est à laisser tel ou on doit fournir la clé et où la trouver au cas où???

J'ai remarqué aussi que mon enregistrement dmarc n'a pas été pris en compte non plus. Que faire????
6 jours plus tard
Salut Hard,

J'aimerai faire mon DNS chez moi, mais je n'ai aucune possibilité d'éditer le dns secondaire de mon serveur.
J'ai remarqué le même problème sur mon VPS scaleway, aucune possibilité d'éditer ceci.

A tu une solution dans ce cas ?

Merci par avance
C'est pas grave, tu peux utiliser les serveurs secondaires de ton registrar ou d'un service tiers comme ceux de http://puck.nether.net/ (voir d'autres sur http://www.frankb.us/dns/). Le mieux c'est d'avoir les deux NS sur un réseau et un AS complètement différent pour éviter d'éventuelles indisponibilités en cas de panne réseau.
Merci pour ta réponse,
Pour mon test mon domaine est chez ovh (xataz.ovh très original), et mon serveur chez scaleway.

J'ai configurer, sur ovh dans zone dns, que je ne peux enlevé de toute façon :
xataz.ovh. NS dns15.ovh.net.
xataz.ovh. NS ns15.ovh.net.

et dans gestion DNS :
ns1.xataz.ovh XX.XX.XX.XX
ns15.ovh.net
dns15.ovh.net


Sur mon serveur j'ai configurer comme sur ton tuto.

Les pings de mes sous-domaine passe niquel. Mais même après 24h, les sites de test de dns, n'arrive pas a résoudre ou alors avec les erreurs.

Pour le moment j'ai tous remis par défaut, mais je reteste ce soir pour voir.
23 jours plus tard
bonjour,

j'ai une erreur dans l'interface OVH quand j'essaye d'ajouter une delegation sécurisée pour le support du DNSSEC


no modification ds requested : same ds data are registred

le problème c'est que j'en ai pas d'enregistré dans la liste

Edit:

j'ai un souci en ajoutant un sous domaine qui pointe sur une utre IP , j'ai mis ca :

www IN CNAME XXX.ovh
patate IN CNAME IP du serveur cible

le problème est sur patate.


sinon à part ca j'ai suivi le tuto , bon au début je n'étais pas réveillé mais en faisant comme expliqué c'est nickel , merci pour le tuto
gutter wrote:bonjour,

j'ai une erreur dans l'interface OVH quand j'essaye d'ajouter une delegation sécurisée pour le support du DNSSEC


no modification ds requested : same ds data are registred

le problème c'est que j'en ai pas d'enregistré dans la liste

Edit:

j'ai un souci en ajoutant un sous domaine qui pointe sur une utre IP , j'ai mis ca :

www IN CNAME XXX.ovh
patate IN CNAME IP du serveur cible

le problème est sur patate.


sinon à part ca j'ai suivi le tuto , bon au début je n'étais pas réveillé mais en faisant comme expliqué c'est nickel , merci pour le tuto
Il te suffit de lire les 3 pages précédentes et t auras la réponse...
A = IP
CNAME = hostname

Change ton CNAME par A sur la ligne patate et c'est good
17 jours plus tard
Bonsoir,

Je souhaiterais mettre en place un serveur DNS sous Bind9 pour mon "laboratoire" de tests.
Je compte louer un nom de domaine chez Gandi, mon serveur DNS serait hébergé chez moi.

Est-ce envisageable de l'auto-héberger ou non ?

Merci
Si pas une IP fixe ça va foutre la merde je pense
arckosfr wrote:Si pas une IP fixe ça va foutre la merde je pense
J'ai une IP fixe.
18 jours plus tard
Petit souci de mon côté avec la mise en place de DNSSEC.
J'ai installé le paquet rng-tools comme indiqué sur le tuto, ajouter dans /etc/default/rng-tools les 2 lignes suivantes: 
HRNGDEVICE=/dev/urandom
RNGDOPTIONS="-W 80% -t 20"
puis un petit start du service: /etc/init.d/rng-tools start
mais lors du lancement du service, j'ai droit à un beau "failed". Il n'est ok que si je laisse la configuration du fichier 
/etc/default/rng-tools
par défaut
Dès que je rentre ces 2 lignes, échec....

Une idée, merci par avance
2 mois plus tard
Je pense qu'on peut très fortement recommender NSD (pour Name Server Daemon) pour de l'usage authoritative-only.
Il y a aussi KnotDNS, mais NSD est encore plus léger et ne fait que ce qu'on lui demande. Il supporte bien entendu DNSSEC.

NSD est plus performant, et... tant mieux, car il se concentre essentiellement sur sa tâche de serveur autoritaire, alors que BIND, bien plus complet, est un vrai couteau-suisse. BIND est "bon partout, mais excellent en rien".
https://www.nlnetlabs.nl/blog/2013/07/05/nsd4-performance-measurements/

Performant, oui, mais plus sûr également. Le code source de NSD est bien plus facile à maintenir (beaucoup moins long) que celui de BIND, même si cette comparaison est injuste, c'est un fait que NSD soit beaucoup plus facile à maintenir. On ne compte plus les 0-day sur BIND (j'exagère, mais il y a quand même pas mal de risques potentiels) ; et si des failles encore plus critiques sont découvertes, il est toujours bon d'avoir à sa portée une alternative. En fait, NSD a été développé à la base pour être une alternative.

Mieux encore, NSD est simple de configuration. Je fais tourner mon DNS autoritaire avec ce fichier de conf, unique :
server:
   server-count: 1
   do-ip4 : yes
   do-ip6 : yes
   hide-version: yes
   identity: "Anonymous DNS."
   zonesdir: "/etc/zones"
zone:
   name: domain.tld
   zonefile: db.domain.tld.signed
   notify:  217.70.177.40 NOKEY
   provide-xfr: 217.70.177.40 NOKEY
Alors, qu'en pensez-vous ? Qu'en penses-tu Hardware ? Je pense que ça peut s'ajouter très vite fait à ton tuto, en complément de BIND : libre à quelqu'un de choisir. Pour le récursif, on peut utiliser Unbound qui est né un peu de la même façon que NSD (pour ça qu'on voit souvent le couple NSD/Unbound).
2 mois plus tard
famillebundy wrote:Petit souci de mon côté avec la mise en place de DNSSEC.
J'ai installé le paquet rng-tools comme indiqué sur le tuto, ajouter dans /etc/default/rng-tools les 2 lignes suivantes: 
HRNGDEVICE=/dev/urandom
RNGDOPTIONS="-W 80% -t 20"
puis un petit start du service: /etc/init.d/rng-tools start
mais lors du lancement du service, j'ai droit à un beau "failed". Il n'est ok que si je laisse la configuration du fichier 
/etc/default/rng-tools
par défaut
Dès que je rentre ces 2 lignes, échec....

Une idée, merci par avance 😉
Je viens de remettre sur l'aspect sécurité de mon serveur DNS et toujours le même type d'erreur dès l'ajout de ces 2 lignes après installation du paquet rng-tools...

d'avance merci
Finalement, problème résolu sans rien avoir modifié dans le fichier /etc/default/rng-tools
La clé a pu quand même se générer donc on laisse comme ça
un mois plus tard
Bonsoir,

J'ai le même message d'erreur que mon collègue au dessus et je n'ai pas vu de réponse à son problème.
Quand je fais la commande service bind9 status, j'ai les messages d'erreurs suivant 
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/AAAA/IN': 2001:500:3::42#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving './NS/IN': 2001:7fd::1#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/A/IN': 2001:7fe::53#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/AAAA/IN': 2001:7fe::53#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/A/IN': 2001:7fd::1#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/AAAA/IN': 2001:7fd::1#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/A/IN': 2001:41d0:1:1986::1#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/A/IN': 2001:41d0:1:4a83::1#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/A/IN': 2001:41d0:1:1984::1#53
Apr 01 22:34:58 named[18851]: error (network unreachable) resolving 'sdns2.ovh.net/A/IN': 2001:41d0:1:4a81::1#53
En regardant sur internet, il me semblait que c'était du à une recherche en ipv6 impossible. Du coup j'ai suivi les indications suivantes :
https://ubuntu-tutorials.com/2009/03/21/configure-bind-9-for-ipv4-or-ipv6-only/

Mais je me retrouve toujours à avoir les messages. Est-ce que quelqu'un aurait une réponse concernant ce problème ?
Est-ce que cela a une incidence sur la propagation des nouveaux sous domaines ?

Merci d'avance
un mois plus tard

Yop,

J'aurais besoin de ton aide Hard :

Je me retrouve coincé avec mon registrar godaddy pour entrer mon enregistrement dnssec.

Selon leur site, mon domaine étant en .net, on a :

https://img.gillesliard.net/V0RN5vYw/4jalgFch.png[/img]

Je t'avoue que je ne n'arrive pas à établir les correspondances avec le tutoriel. Sur leur interface, je ne peux que renseigner les champs ci-dessus :

Soit :

* Key tag

  • Algorithm
  • Digest type
  • Digest[/b]

Tu aurais une idée ? Autant chez gandi c'était simple, qu'ici je suis paumé.

Merci Hard.

Oui parce que Gandi détecte les paramètres automatiquement. Pour le tag et le digest type (SHA1/SHA-256) c'est dans le fichier où se trouve ta clé publique KSK, l'algo c'est celui utilisé avec la commande dnssec-keygen (RSASHA256) et le digest c'est le condensât de la clé publique KSK.
Merci ^^ Je vais regarder ça une énième fois. Je te ferai un screen des menus "algorithm" et "digest type" parce qu'on ne peut pas entrer les valeurs que tu cites, et c'est pour ça que je coince...
Le fichier : 
/etc/bind/domain.tld/dsset-domain.tld.
contenait les valeurs à indiquer.

Merci du conseil Hard.
Tu peux faire un petit screen pour Go-daddy stp ? Je vais le mettre dans le tuto

On affiche la valeur du fichier ci-dessous :

cat /etc/bind/domain.tld/dsset-domain.tld.
domain.tld.	IN DS 59704 8 1 EB6646E2A2F95A29895CDC3AE69BB8B62AD3B4D6
domain.tld.      IN DS 59704 8 2 285C224DAA6B145334DE4E7F3D78CE877142ACD344BC6DA6F03D55AD B7838219

On renseigne en conséquence les champs chez godaddy :

Nickel merci, je vais rajouter ça.
J'ai dû modifier Hard, tu dois reprendre l'ajout dans ton tutoriel. Ce n'était pas la première ligne qu'il fallait renseigner mais bien la seconde.
Bon, je galère cette fois-ci :

1°) L'analyse n'est pas probante : http://dnssec-debugger.verisignlabs.com/equiferus.net et ici aussi : http://dnsviz.net/d/equiferus.net/dnssec/
2°) Je me retrouve avec des réponses dig de ce genre : 
root@opch:~➜ dig wiki.equiferus.net +short
opch.equiferus.net.equiferus.net.
root@opch:~➜ dig wiki.equiferus.net +short @208.67.220.220
opch.equiferus.net.
31.7.56.100
La première réponse renvoyée me semble si incompréhensible, pourquoi cette réponse ? fqdn.domain.tld ?

Serait-ce possible que cela soit lié au fait que chez godaddy, je possède un whois "privacy" et qu'en conséquence, deux serveurs DNS me soient inévitablement liés ?
root@opch:~➜ dig NS equiferus.net +short
ns52.domaincontrol.com.
ns1.equiferus.net.
ns51.domaincontrol.com.
Si je regarde cette section : http://dnsviz.net/d/equiferus.net/responses/ , on dirait que c'est bien le cas, non ?

Si vous avez des idées
ça me rappel le problème d'un célèbre tracker privé FR hehe ^^

Ils avaient le même soucis avec les NS secondaires de GoDaddy, il suffit juste de les supprimer depuis l'interface de ton registrar. Tu obtiens ces erreurs DNSSEC puisque sur les deux secondaires la zone n'est pas signée, donc y a pas d'enregistrement DNSKEY.
No DNSKEY records found
The A RRset was not signed by any keys in the chain-of-trust
Ou sinon plus propre, tu autorises le transfert AXFR de la zone aux deux NS secondaires avec la directive allow-transfer :
allow-transfer { IP_NS51; IP_NS52; };
Sinon pour ton message plus haut, j'ai pas besoin de modifier le tuto, le second enregistrement est équivalent au premier, seul le type de digest change (1 = SHA1 / 2 = SHA256). En théorie, il est conseillé de mettre deux enregistrements DS dans la zone parent, donc tu peux mettre les deux si tu veux.
Merci pour toutes ces explications Hard ^^

Cela dit, quand on souscrit à la protection du whois chez godaddy, on ne peut pas supprimer les NS estampillés "domaincontrol". Il me faut donc ajouter la directive au fichier de configuration ?

C'est bien dans :

/etc/bind/named.conf.local
[/s]

Si oui, elle est déjà présente. Je remplacerais donc ceci :

 allow-transfer { IP_NS51; IP_NS52; 127.0.0.1; ::1; };
[/s]

par:

 allow-transfer { IP_NS51; IP_NS52; };
[/s]

?

Je pencherai plutôt pour le fichier :

/etc/bind/named.conf.options
[/color]

yabon ?!?

Et pour la réponse dig, la forme tu l'expliquerais comment ?
J'ai pas précisé mais c'est dans /etc/bind/named.conf.local entre les accolades de ton domaine, c'est important que ça soit ici sinon tu risques d'autoriser le transfert pour d'autres domaines. Pense à changer le serial de ta zone aussi.

Sinon pour :
opch.equiferus.net.equiferus.net.
Corrige le problème avec DNSSEC déjà, avec les résolveurs de Google ça plante (SERVFAIL). Sinon vérifie que tu as pas préfixé en double l'enregistrement avec ton domaine.
Dans ce cas cette directive est déjà présente dans le fichier de configuration que tu as donné au départ. Tu l'as redouble alors ?
cat /etc/bind/named.conf.local

zone "equiferus.net" IN {

        # Zone de type maître
        type master;

        # Fichier de zone
        file "/etc/bind/equiferus.net/db.equiferus.net.signed";

        # On autorise le transfert de la zone aux serveurs DNS secondaires
        allow-transfer { 216.69.185.26; 208.109.255.26; 127.0.0.1; ::1; };

        # On autorise tout le monde à envoyer des requêtes vers cette zone
        allow-query { any; };

        # Prévenir les serveurs DNS secondaires qu'un changement a été effectué dans la zone maître
        notify yes;
};
?
Ah bah si c'est déjà le cas, c'est bon alors. Incrémente le sérial de la zone puis redémarre bind et vérifie qu'il notifie bien les 2 NS secondaires.
# journalctl -u bind9

named[xxxx]: zone domain.tld/IN: sending notifies (serial 2016xxxxxx)
Et ton problème devrait être résolu, enfin en théorie. Ça me semble bizarre que tu puisses pas supprimer ces 2 NS, ils devraient pas les rendre obligatoires.

Je pense que c'était bon depuis le début dans ce cas :

May 03 08:52:32 opch named[18699]: command channel listening on 127.0.0.1#953
May 03 08:52:32 opch named[18699]: command channel listening on ::1#953
May 03 08:52:32 opch named[18699]: managed-keys-zone: loaded serial 4
May 03 08:52:32 opch named[18699]: zone 0.in-addr.arpa/IN: loaded serial 1
May 03 08:52:32 opch named[18699]: zone 127.in-addr.arpa/IN: loaded serial 1
May 03 08:52:32 opch named[18699]: zone localhost/IN: loaded serial 2
May 03 08:52:32 opch named[18699]: zone 255.in-addr.arpa/IN: loaded serial 1
May 03 08:52:32 opch named[18699]: zone equiferus.net/IN: loaded serial 2016050203 (DNSSEC signed)
May 03 08:52:32 opch named[18699]: all zones loaded
May 03 08:52:32 opch named[18699]: running
May 03 08:52:32 opch named[18699]: zone equiferus.net/IN: sending notifies (serial 2016050203)

Je vais voir, sinon je penserais à transférer mon domaine ailleurs.

Oui, ils sont bien indissociables, tu n'as aucune action possible.

Merci Hard !

Sinon tu peux demander à leur support, tu leur demandes pourquoi les secondaires ne sont pas mis à jour avec la zone signée avec DNSSEC.
J'abdique ! Rien n'y change, les DNS secondaires ne sont pas mis à jour. Je vais transférer mon domaine chez Gandi ou ailleurs.

J'aurais pû/dû les contacter, comme tu me le préconises Hard, mais après avoir lu les déboires d'autres personnes à propos du même sujet, je préfère transférer,

4 jours plus tard
Bonjour à tous,

J'ai suivi le tutoriel et ça fonctionne parfaitement, d'ailleurs merci beaucoup.

J'ai juste un petit souci quand je fais un test avec zonemaster...

Après le test, dans l'onglet "connectivity" j'ai un triangle pour faire comprendre qu'il faut faire attention à un détail, le voici :
Toutes les adresses IPv6 des serveurs de noms se trouvent dans le même AS (16276).
Que dois-je donc comprendre ? Est-ce un problème qui n'est pas réglable ?

Merci
Cordialement
Rathorian wrote:Bonjour à tous,

J'ai suivi le tutoriel et ça fonctionne parfaitement, d'ailleurs merci beaucoup.

J'ai juste un petit souci quand je fais un test avec zonemaster...

Après le test, dans l'onglet "connectivity" j'ai un triangle pour faire comprendre qu'il faut faire attention à un détail, le voici :
Toutes les adresses IPv6 des serveurs de noms se trouvent dans le même AS (16276).
Que dois-je donc comprendre ? Est-ce un problème qui n'est pas réglable ?

Merci
Cordialement
En gros ca veux dire qu'en IPv6 l'ensemble de tes serveurs DNS (principale + secondaire) sont sur le même réseaux, donc dans le cas d'une hypothétique coupure plus aucun serveur DNS ne seras accessible.
arckosfr wrote:
Rathorian wrote:Bonjour à tous,

J'ai suivi le tutoriel et ça fonctionne parfaitement, d'ailleurs merci beaucoup.

J'ai juste un petit souci quand je fais un test avec zonemaster...

Après le test, dans l'onglet "connectivity" j'ai un triangle pour faire comprendre qu'il faut faire attention à un détail, le voici :
Toutes les adresses IPv6 des serveurs de noms se trouvent dans le même AS (16276).
Que dois-je donc comprendre ? Est-ce un problème qui n'est pas réglable ?

Merci
Cordialement
En gros ca veux dire qu'en IPv6 l'ensemble de tes serveurs DNS (principale + secondaire) sont sur le même réseaux, donc dans le cas d'une hypothétique coupure plus aucun serveur DNS ne seras accessible.
Merci pour cette information.
Donc au final rien de méchant.
11 jours plus tard
Suite :

Migration réalisée chez Gandi, et c'est parfait !

Sinon :

Je vois que BXT a sollicité Bortzmeyer a propos de DNS-over-TLS et je trouve ça également intéressant, même indispensable à vrai dire. Il a d'ailleurs publié un article à propos. Suite à cela, ne serait-il pas intéressant de remplacer BIND9 par UNBOUND ? Le premier ne supportant pas encore ce protocole alors que le second pleinement.

J'attends impatiemment ton retour Hard
Salut Solinvictus, ce n'est pas possible, ce tuto décrit l'installation d'un serveur DNS autoritaire (faisant autorité sur un NDD) et pas un serveur DNS récursif comme peut l'être Unbound, éventuellement je pourrais remplacer Bind9 par NSD (voir l'article sur mon blog), mais en aucun cas je peux remplacer Bind9 par Unbound pour ce genre d'usage, ce n'est pas son rôle.
D'accord, c'est ce point qui m'échappait, les rôles différents de bind9 et d'unbound. Je vais regarder du côté de NSD, que je ne connais pas.

Merci o/
7 jours plus tard
Je ne parviens pas à accéder à certains site, i.e vmware.com :
tail -f daemon.log | grep "error"
[26553]: error (broken trust chain) resolving 'www.vmware.com/A/IN': 208.91.0.24#53
[26553]: error (broken trust chain) resolving 'www.vmware.com/AAAA/IN': 208.91.2.146#53
[26553]: error (broken trust chain) resolving 'www.vmware.com/A/IN': 208.91.2.146#53
[26553]: error (broken trust chain) resolving 'www.vmware.com/A/IN': 208.91.2.59#53
Il faut que je désactive dnssec dans :
/etc/bind/named.conf/options
pour que cela soit résolu... C'est emmerdant.

Une idée ?
Demander au hostmaster gérant la zone DNS de vmware.com de réparer le problème DNSSEC apporte une couche de sécurité supplémentaire mais demande une surveillance régulière de la zone.