il semble qu'il n'y ai à ce jour pas de groupes pour échanger à propos
des systèmes de résolution de noms de domaines (DNS).
Il semblerait donc que le lieu le plus appropriés serait fr.comp.mail*
ce qui n'est pas très intuitif.
Je propose donc la création de :
fr.comp.reseaux.dns (sur le Big8 c'est comp.protocols.bind).
J'aurais bien proposé fr.comp.protocoles.dns, mais nous avons créé
fr.comp.reseaux.jntp alors…
Ça pourrait être aussi fr.comp.reseaux.protocoles.dns
Je vous laisse martyriser les insectes pour savoir
1) s'il est pertinent de créer ce groupe
2) vous étriper sur le nomage.
De toutes façons, comme ne manquerons certainement pas de souligner
certains, le résultat est plié d'avance puisque c'est "fufa" qui
propose… Ce qui évidement, est faux. Mais bon, faut bien s'occuper.
C'est juste que aller causer DNSSEC, gestion des trousseaux… dans la
langue de Shakespeare quand on ne la maitrise pas vraiment c'est pas
super pratique.
Bonne journée.
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
DNSSEC ! Donc première étape en la matière, bien vérifier que le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à la commercialisation des services de registrar pour le top domain ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
Doug713705 <doug.letough@free.fr> wrote:
DNSSEC ! Donc première étape en la matière, bien vérifier que
le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le
faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses
avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à
la commercialisation des services de registrar pour le top domain
ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru
particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière
des clés.
DNSSEC ! Donc première étape en la matière, bien vérifier que le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à la commercialisation des services de registrar pour le top domain ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
Benoit Izac
Bonjour, Le 25/10/2016 à 20:33, Marc SCHAEFER a écrit dans le message <nuo8hi$sg9$ :
DNSSEC ! Donc première étape en la matière, bien vérifier que le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à la commercialisation des services de registrar pour le top domain ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
Pour en avoir fait les frais récemment, je confirme. Du coup j'ai laissé tombé DNSSEC pour le moment et j'ai bien galéré pour le désactiver sur l'interface OVH (si on supprime la dernière clé, on ne peut plus valider...). -- Benoit Izac
Bonjour,
Le 25/10/2016 à 20:33, Marc SCHAEFER a écrit dans le message
<nuo8hi$sg9$1@shakotay.alphanet.ch> :
DNSSEC ! Donc première étape en la matière, bien vérifier que
le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le
faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses
avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à
la commercialisation des services de registrar pour le top domain
ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru
particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière
des clés.
Pour en avoir fait les frais récemment, je confirme. Du coup j'ai laissé
tombé DNSSEC pour le moment et j'ai bien galéré pour le désactiver sur
l'interface OVH (si on supprime la dernière clé, on ne peut plus
valider...).
Bonjour, Le 25/10/2016 à 20:33, Marc SCHAEFER a écrit dans le message <nuo8hi$sg9$ :
DNSSEC ! Donc première étape en la matière, bien vérifier que le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à la commercialisation des services de registrar pour le top domain ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
Pour en avoir fait les frais récemment, je confirme. Du coup j'ai laissé tombé DNSSEC pour le moment et j'ai bien galéré pour le désactiver sur l'interface OVH (si on supprime la dernière clé, on ne peut plus valider...). -- Benoit Izac
Erwan David
Benoit Izac écrivait :
Bonjour, Le 25/10/2016 à 20:33, Marc SCHAEFER a écrit dans le message <nuo8hi$sg9$ :
DNSSEC ! Donc première étape en la matière, bien vérifier que le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à la commercialisation des services de registrar pour le top domain ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
Pour en avoir fait les frais récemment, je confirme. Du coup j'ai laissé tombé DNSSEC pour le moment et j'ai bien galéré pour le désactiver sur l'interface OVH (si on supprime la dernière clé, on ne peut plus valider...).
Faut automatiser le renouvellement. Perso j'utilise opendnssec. -- Les simplifications c'est trop compliqué
Le 25/10/2016 à 20:33, Marc SCHAEFER a écrit dans le message
<nuo8hi$sg9$1@shakotay.alphanet.ch> :
DNSSEC ! Donc première étape en la matière, bien vérifier que
le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le
faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses
avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à
la commercialisation des services de registrar pour le top domain
ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru
particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière
des clés.
Pour en avoir fait les frais récemment, je confirme. Du coup j'ai laissé
tombé DNSSEC pour le moment et j'ai bien galéré pour le désactiver sur
l'interface OVH (si on supprime la dernière clé, on ne peut plus
valider...).
Faut automatiser le renouvellement. Perso j'utilise opendnssec.
Bonjour, Le 25/10/2016 à 20:33, Marc SCHAEFER a écrit dans le message <nuo8hi$sg9$ :
DNSSEC ! Donc première étape en la matière, bien vérifier que le registrar gère DNSSEC et apparemment ils ne seraient pas nombreux à le faire.
OVH le fait, ou du moins ça marche pour un de mes domaines suisses avec DNSSEC (oui, j'ai dû demander l'asile car au départ, suite à la commercialisation des services de registrar pour le top domain ch., aucun des nouveaux ne le supportait officiellement).
Mis à part ça la mise en place de DNSSEC ne m'a pas paru particulièrement complexe.
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
Pour en avoir fait les frais récemment, je confirme. Du coup j'ai laissé tombé DNSSEC pour le moment et j'ai bien galéré pour le désactiver sur l'interface OVH (si on supprime la dernière clé, on ne peut plus valider...).
Faut automatiser le renouvellement. Perso j'utilise opendnssec. -- Les simplifications c'est trop compliqué
Le Mardi 25 octobre 2016 à 19:37 UTC, Erwan David écrivait sur fr.comp.reseaux.ip :
Faut automatiser le renouvellement. Perso j'utilise opendnssec.
Suis preneur d'une ou deux petites doc pour ça. ;) Parce que justement, je n'ai pas encore bien saisi comment gérer le renouvellement des clefs. @+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
Le Mardi 25 octobre 2016 à 19:37 UTC, Erwan David écrivait sur
fr.comp.reseaux.ip :
Faut automatiser le renouvellement. Perso j'utilise opendnssec.
Suis preneur d'une ou deux petites doc pour ça. ;)
Parce que justement, je n'ai pas encore bien saisi comment gérer le
renouvellement des clefs.
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
Le Mardi 25 octobre 2016 à 19:37 UTC, Erwan David écrivait sur fr.comp.reseaux.ip :
Faut automatiser le renouvellement. Perso j'utilise opendnssec.
Suis preneur d'une ou deux petites doc pour ça. ;) Parce que justement, je n'ai pas encore bien saisi comment gérer le renouvellement des clefs. @+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
Gérald Niel
Bonjour, Le Mardi 25 octobre 2016 à 18:33 UTC, Marc SCHAEFER écrivait sur fr.comp.reseaux.ip :
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
À ce sujet, qu'elle soit automatisé ou manuelle, quelle est la bonne méthode ? Je dois avouez que j'expérimente DNSSEC un peu de façons empirique (même si j'ai RTFM un peu quand même). On génère la nouvelle paire de clefs, on signe et met à jour la zone et en même temps on envoit les enregistrement DS au niveau du dessus ? Dans le cas de Gandi il faut renseigner la clef, et il se charge des entrées DS, qui je suppose remonte au niveau du premier niveau ? Et on conserve les anciens enregistrements le temps de la mise à jour ? Ceci dit ça semble aller assez vite pour la prise en compte après soumission dans l'interface de Gandi. Les récursifs de mon FAI l'ont été en moins d'une heure après la première manip. Idem pour mes deux unbound. C'est allé assez vite. En parlant de ces entrée NS, faut il aussi les inclure dans la zone ? Je ne l'ai pas fait pour les NS, juste les DNSKEY avant de signer la zone. Perso j'ai utilisé les outils dnssec-* fournit par le port bind-tools de FreeBSD. Je génère la paire (ZSK puis KSK) avec dnssec-keygen (options par défaut pour l'instant) puis je signe avec dnssec-signzone. Le serveur (non récursif) est NSD. Et j'ai quand même quelques domaines. Donc automatiser le machin ça serait bien. ;) Je suis allé vérifier que j'avais bien configuré ici https://www.zonemaster.net/nojs et : DNSSEC Found DS records with tags 14520:27712. There are both DS and DNSKEY records with key tags 14520:27712. DS record with keytag 14520 and digest type 2 matches the DNSKEY with the same tag. DS record with keytag 27712 and digest type 2 matches the DNSKEY with the same tag. At least one DS record with a matching DNSKEY record was found. RRSIG with keytag 14520 and covering type(s) DNSKEY expires at : Wed Nov 23 18:44:12 2016. RRSIG with keytag 27712 and covering type(s) DNSKEY expires at : Wed Nov 23 18:44:12 2016. RRSIG with keytag 14520 and covering type(s) SOA expires at : Wed Nov 23 18:44:12 2016. The DNSKEY with tag 14520 uses algorithm number 5/(RSA/SHA1) [OK]. The DNSKEY with tag 27712 uses algorithm number 5/(RSA/SHA1) [OK]. The zone has NSEC records. Delegation from parent to child is properly signed. Est-ce à dire que passé le 23/11, ça va passer en insecure puisque les clefs auront expirées (pas pris garde à ça moi…). @+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
Bonjour,
Le Mardi 25 octobre 2016 à 18:33 UTC, Marc SCHAEFER écrivait sur
fr.comp.reseaux.ip :
C'est surtout la maintenance: ne pas oublier la mise à jour régulière
des clés.
À ce sujet, qu'elle soit automatisé ou manuelle, quelle est la bonne
méthode ?
Je dois avouez que j'expérimente DNSSEC un peu de façons empirique
(même si j'ai RTFM un peu quand même).
On génère la nouvelle paire de clefs, on signe et met à jour la zone
et en même temps on envoit les enregistrement DS au niveau du dessus ?
Dans le cas de Gandi il faut renseigner la clef, et il se charge des
entrées DS, qui je suppose remonte au niveau du premier niveau ?
Et on conserve les anciens enregistrements le temps de la mise à jour ?
Ceci dit ça semble aller assez vite pour la prise en compte après
soumission dans l'interface de Gandi.
Les récursifs de mon FAI l'ont été en moins d'une heure après la
première manip.
Idem pour mes deux unbound. C'est allé assez vite.
En parlant de ces entrée NS, faut il aussi les inclure dans la zone ?
Je ne l'ai pas fait pour les NS, juste les DNSKEY avant de signer la
zone.
Perso j'ai utilisé les outils dnssec-* fournit par le port bind-tools
de FreeBSD. Je génère la paire (ZSK puis KSK) avec dnssec-keygen
(options par défaut pour l'instant) puis je signe avec
dnssec-signzone. Le serveur (non récursif) est NSD.
Et j'ai quand même quelques domaines. Donc automatiser le machin ça
serait bien. ;)
Je suis allé vérifier que j'avais bien configuré ici
https://www.zonemaster.net/nojs
et :
DNSSEC
Found DS records with tags 14520:27712.
There are both DS and DNSKEY records with key tags 14520:27712.
DS record with keytag 14520 and digest type 2 matches the DNSKEY with
the same tag.
DS record with keytag 27712 and digest type 2 matches the DNSKEY with
the same tag.
At least one DS record with a matching DNSKEY record was found.
RRSIG with keytag 14520 and covering type(s) DNSKEY expires at : Wed
Nov 23 18:44:12 2016.
RRSIG with keytag 27712 and covering type(s) DNSKEY expires at : Wed
Nov 23 18:44:12 2016.
RRSIG with keytag 14520 and covering type(s) SOA expires at : Wed Nov
23 18:44:12 2016.
The DNSKEY with tag 14520 uses algorithm number 5/(RSA/SHA1) [OK].
The DNSKEY with tag 27712 uses algorithm number 5/(RSA/SHA1) [OK].
The zone has NSEC records.
Delegation from parent to child is properly signed.
Est-ce à dire que passé le 23/11, ça va passer en insecure puisque les
clefs auront expirées (pas pris garde à ça moi…).
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
Bonjour, Le Mardi 25 octobre 2016 à 18:33 UTC, Marc SCHAEFER écrivait sur fr.comp.reseaux.ip :
C'est surtout la maintenance: ne pas oublier la mise à jour régulière des clés.
À ce sujet, qu'elle soit automatisé ou manuelle, quelle est la bonne méthode ? Je dois avouez que j'expérimente DNSSEC un peu de façons empirique (même si j'ai RTFM un peu quand même). On génère la nouvelle paire de clefs, on signe et met à jour la zone et en même temps on envoit les enregistrement DS au niveau du dessus ? Dans le cas de Gandi il faut renseigner la clef, et il se charge des entrées DS, qui je suppose remonte au niveau du premier niveau ? Et on conserve les anciens enregistrements le temps de la mise à jour ? Ceci dit ça semble aller assez vite pour la prise en compte après soumission dans l'interface de Gandi. Les récursifs de mon FAI l'ont été en moins d'une heure après la première manip. Idem pour mes deux unbound. C'est allé assez vite. En parlant de ces entrée NS, faut il aussi les inclure dans la zone ? Je ne l'ai pas fait pour les NS, juste les DNSKEY avant de signer la zone. Perso j'ai utilisé les outils dnssec-* fournit par le port bind-tools de FreeBSD. Je génère la paire (ZSK puis KSK) avec dnssec-keygen (options par défaut pour l'instant) puis je signe avec dnssec-signzone. Le serveur (non récursif) est NSD. Et j'ai quand même quelques domaines. Donc automatiser le machin ça serait bien. ;) Je suis allé vérifier que j'avais bien configuré ici https://www.zonemaster.net/nojs et : DNSSEC Found DS records with tags 14520:27712. There are both DS and DNSKEY records with key tags 14520:27712. DS record with keytag 14520 and digest type 2 matches the DNSKEY with the same tag. DS record with keytag 27712 and digest type 2 matches the DNSKEY with the same tag. At least one DS record with a matching DNSKEY record was found. RRSIG with keytag 14520 and covering type(s) DNSKEY expires at : Wed Nov 23 18:44:12 2016. RRSIG with keytag 27712 and covering type(s) DNSKEY expires at : Wed Nov 23 18:44:12 2016. RRSIG with keytag 14520 and covering type(s) SOA expires at : Wed Nov 23 18:44:12 2016. The DNSKEY with tag 14520 uses algorithm number 5/(RSA/SHA1) [OK]. The DNSKEY with tag 27712 uses algorithm number 5/(RSA/SHA1) [OK]. The zone has NSEC records. Delegation from parent to child is properly signed. Est-ce à dire que passé le 23/11, ça va passer en insecure puisque les clefs auront expirées (pas pris garde à ça moi…). @+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
Erwan David
Gérald Niel <gerald.niel+ écrivait :
Le Mardi 25 octobre 2016 à 19:37 UTC, Erwan David écrivait sur fr.comp.reseaux.ip :
Faut automatiser le renouvellement. Perso j'utilise opendnssec.
Suis preneur d'une ou deux petites doc pour ça. ;) Parce que justement, je n'ai pas encore bien saisi comment gérer le renouvellement des clefs. @+
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html Par exemple. -- Les simplifications c'est trop compliqué
Le Mardi 25 octobre 2016 à 19:37 UTC, Erwan David écrivait sur fr.comp.reseaux.ip :
Faut automatiser le renouvellement. Perso j'utilise opendnssec.
Suis preneur d'une ou deux petites doc pour ça. ;) Parce que justement, je n'ai pas encore bien saisi comment gérer le renouvellement des clefs. @+
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html Par exemple. -- Les simplifications c'est trop compliqué
Eric Masson
Erwan David writes: 'Lut,
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html Par exemple.
Quelqu'un a regardé du côté de KnotDNS ? Il me semble que la gestion des clés est automatisée. -- TP> (niark niark) C quoi ce niark niark ? -+- FM in GNU : Bien faire bisquer le neuneu -+-
Erwan David <erwan@rail.eu.org> writes:
'Lut,
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html
Par exemple.
Quelqu'un a regardé du côté de KnotDNS ?
Il me semble que la gestion des clés est automatisée.
--
TP> (niark niark)
C quoi ce niark niark ?
-+- FM in GNU : Bien faire bisquer le neuneu -+-
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html Par exemple.
Quelqu'un a regardé du côté de KnotDNS ? Il me semble que la gestion des clés est automatisée. -- TP> (niark niark) C quoi ce niark niark ? -+- FM in GNU : Bien faire bisquer le neuneu -+-
Je suis tombé sur une page en français sur le sujet quand je cherchais de la doc sur DNSSEC. Mais pas encore essayé de jouer avec. C'est installé sur mon FreeBSD par contre. Ça remplace NSD ou Bind, ou comme opendnssec ça vient en complément ? -- Gérald Niel
Le 26/10/2016 à 17:14, Eric Masson a écrit :
Quelqu'un a regardé du côté de KnotDNS ?
Je suis tombé sur une page en français sur le sujet quand je cherchais
de la doc sur DNSSEC.
Mais pas encore essayé de jouer avec. C'est installé sur mon FreeBSD par
contre.
Ça remplace NSD ou Bind, ou comme opendnssec ça vient en complément ?
Je suis tombé sur une page en français sur le sujet quand je cherchais de la doc sur DNSSEC. Mais pas encore essayé de jouer avec. C'est installé sur mon FreeBSD par contre. Ça remplace NSD ou Bind, ou comme opendnssec ça vient en complément ? -- Gérald Niel
Eric Masson
Gérald Niel <gerald.niel+ writes: 'Lut,
Ça remplace NSD ou Bind, ou comme opendnssec ça vient en complément ?
Dans mes souvenirs, c'est un "authoritative server" qui ne se préoccupe pas de résolution récursive, comme NSD. -- Salut, Je ne reçoit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
Ça remplace NSD ou Bind, ou comme opendnssec ça vient en complément ?
Dans mes souvenirs, c'est un "authoritative server" qui ne se préoccupe pas de résolution récursive, comme NSD. -- Salut, Je ne reçoit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
Le Mercredi 26 octobre 2016 à 14:46 UTC, Erwan David écrivait sur fr.comp.reseaux.ip :
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html Par exemple.
Merci. Je suis aussi tombé là dessus (entre autres) : <https://www.afnic.fr/medias/documents/DNSSEC/Afnic-dnssec-howto-fr-v3.pdf> Et ça <https://www.oostergo.net/node/50> Et me suis appuyé sur ces différentes doc pour signer les zones (la seconde en pratique) : <http://www.kaba1ah.org/2014/08/27/nsd-and-opendnssec-under-freebsd-10-part-1/> <http://ensiwiki.ensimag.fr/index.php/DNSSEC_par_la_pratique_(tutoriel_Bind9/FreeBSD)> Mais il y a toujours un truc (concept) qui m'échappe, c'est la durée de vie des clefs. Chose à laquelle j'ai complètement fait abstraction ! Donc en pratique, qu'est ce qui est le mieux, regénérer une nouvelle paire de clef afin d'anticiper ? Sachant que les TTL de la zone sont : $TTL 2h Refresh : 8H Retry : 2H Expire : 1W Min TTL : 1D Et que visiblement j'ai généré des clefs (KSK et ZSK) d'une validité de 30 jours (un mois). Ou est-ce seulement la ZSK, et dans ce cas suffit-il de simplement re-signer la zone et notifier les DNS secondaire ? Puisque ici il <https://www.oostergo.net/node/50> est écrit : « Although the KSK and ZSK don't expire, it's recommended to rotate the ZSK every 30 days and the KSK once per year. The ZSK can be rotated without interaction with the domain registrar, but for KSK rotation the DS records at your registrar needs to be updated » Ça expire, ou ça expire pas ? ;) @+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
Le Mercredi 26 octobre 2016 à 14:46 UTC, Erwan David écrivait sur
fr.comp.reseaux.ip :
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html
Par exemple.
Merci.
Je suis aussi tombé là dessus (entre autres) :
<https://www.afnic.fr/medias/documents/DNSSEC/Afnic-dnssec-howto-fr-v3.pdf>
Et ça
<https://www.oostergo.net/node/50>
Et me suis appuyé sur ces différentes doc pour signer les zones (la
seconde en pratique) :
<http://www.kaba1ah.org/2014/08/27/nsd-and-opendnssec-under-freebsd-10-part-1/>
<http://ensiwiki.ensimag.fr/index.php/DNSSEC_par_la_pratique_(tutoriel_Bind9/FreeBSD)>
Mais il y a toujours un truc (concept) qui m'échappe, c'est la durée
de vie des clefs. Chose à laquelle j'ai complètement fait abstraction !
Donc en pratique, qu'est ce qui est le mieux, regénérer une nouvelle
paire de clef afin d'anticiper ?
Sachant que les TTL de la zone sont :
$TTL 2h
Refresh : 8H
Retry : 2H
Expire : 1W
Min TTL : 1D
Et que visiblement j'ai généré des clefs (KSK et ZSK) d'une validité
de 30 jours (un mois).
Ou est-ce seulement la ZSK, et dans ce cas suffit-il de simplement
re-signer la zone et notifier les DNS secondaire ?
Puisque ici il <https://www.oostergo.net/node/50> est écrit :
« Although the KSK and ZSK don't expire, it's recommended to rotate
the ZSK every 30 days and the KSK once per year. The ZSK can be
rotated without interaction with the domain registrar, but for KSK
rotation the DS records at your registrar needs to be updated »
Ça expire, ou ça expire pas ? ;)
@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
précisément de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-
Le Mercredi 26 octobre 2016 à 14:46 UTC, Erwan David écrivait sur fr.comp.reseaux.ip :
https://billets.rail.eu.org/unix-reseau/opendnssec-debian.html Par exemple.
Merci. Je suis aussi tombé là dessus (entre autres) : <https://www.afnic.fr/medias/documents/DNSSEC/Afnic-dnssec-howto-fr-v3.pdf> Et ça <https://www.oostergo.net/node/50> Et me suis appuyé sur ces différentes doc pour signer les zones (la seconde en pratique) : <http://www.kaba1ah.org/2014/08/27/nsd-and-opendnssec-under-freebsd-10-part-1/> <http://ensiwiki.ensimag.fr/index.php/DNSSEC_par_la_pratique_(tutoriel_Bind9/FreeBSD)> Mais il y a toujours un truc (concept) qui m'échappe, c'est la durée de vie des clefs. Chose à laquelle j'ai complètement fait abstraction ! Donc en pratique, qu'est ce qui est le mieux, regénérer une nouvelle paire de clef afin d'anticiper ? Sachant que les TTL de la zone sont : $TTL 2h Refresh : 8H Retry : 2H Expire : 1W Min TTL : 1D Et que visiblement j'ai généré des clefs (KSK et ZSK) d'une validité de 30 jours (un mois). Ou est-ce seulement la ZSK, et dans ce cas suffit-il de simplement re-signer la zone et notifier les DNS secondaire ? Puisque ici il <https://www.oostergo.net/node/50> est écrit : « Although the KSK and ZSK don't expire, it's recommended to rotate the ZSK every 30 days and the KSK once per year. The ZSK can be rotated without interaction with the domain registrar, but for KSK rotation the DS records at your registrar needs to be updated » Ça expire, ou ça expire pas ? ;) @+ -- On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le gouvernement ; c'est la paix sans la violence. C'est le contraire précisément de tout ce qu'on lui reproche, soit par ignorance, soit par mauvaise foi. -+- Hem Day -+-
