Je suis actuellement en train de migrer mon serveur DNS (master) vers
une autre machine (@IP différente) et comme d'habitude j'ai un soucis
pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit
accepter les transferts de zone de la part du *nouveau* serveur maitre
et de refuser les transfert de la part de l'ancien.
Le nouveau serveur:
- FQDN: golgoth99.redatomik.org
- @IP: 163.172.215.184
Chacun des reverses DNS est configuré pour matcher le FQDN de la machine
correspondante.
Sur le nouveau serveur le numéro de série de la zone et de la zone
inverse sont supérieurs à ceux de l'ancien.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et
dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
;
; BIND data file for local loopback interface
;
$TTL 3600
@ IN SOA golgoth99.redatomik.org. root.redatomik.org. (
2016080860 ; Serial
3600 ; Refresh
600 ; Retry
3600 ; Expire
600 ) ; Negative Cache TTL
@ IN NS golgoth99.redatomik.org.
@ IN NS nssec.online.net.
@ IN MX 10 mail.redatomik.org.
redatomik.org. IN A 163.172.215.184
mail.redatomik.org. IN A 195.154.70.45
www.redatomik.org. IN A 163.172.215.184
golgoth98.redatomik.org. IN A 195.154.70.45
golgoth99.redatomik.org. IN A 163.172.215.184
cloud.redatomik.org. IN A 195.154.70.45
news.redatomik.org. IN A 195.154.70.45
usenet-fr.redatomik.org. IN A 163.172.215.184
gopher.redatomik.org. IN A 195.154.70.45
De son coté la zone inverse ressemble à ça:
;
; BIND reverse data file for local loopback interface
;
$TTL 3600
@ IN SOA golgoth98.redatomik.org. root.redatomik.org. (
2016080860 ; Serial
3600 ; Refresh
600 ; Retry
3600 ; Expire
600 ) ; Negative Cache TTL
@ IN NS golgoth98.redatomik.org.
45 IN PTR golgoth98.redatomik.org.
le fichier de configuration locale ressemble à ceci:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "redatomik.org" {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
allow-query { any; };
notify yes;
file "/etc/bind/db.redatomik.org";
};
zone "215.172.163.in-addr.arpa" IN {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
allow-query { any; };
notify yes;
file "/etc/bind/db.redatomik.org.inv";
};
Le registrar est online.net et son interface de gestion des DNS est
plutôt sommaire mais, de mon point de vue, correctement renseignée
avec:
DNS Primaire: golgoth99.redatomik.org (le nouveau serveur)
DNS secondaire: nssec.online.net
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer
la zone redatomik.org vers nssec.online.net:
Sur l'ancien serveur le /var/mog/daemon.log est explicite:
Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started
Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended
Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative
de transfert ce qui pose des problèmes de cohérence si je modifie la
zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas
mis à jour et suivant lequel des deux est interrogé, le résultat peut
s'avérer différent).
J'ai beau vérifier, revérifier, il doit y avoir encore un détails ou
douze qui m'échappent.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la
zone au dns secondaire auquel cas j'en aurais eu une trace dans les
logs, au moins un message/code d'erreur.
J'ai malheureusement systématiquement eu des problèmes lors des
différentes migrations du serveur DNS maitre lorsque le regisrar est
online.net et visiblement je n'ai toujours pas compris ce qui
cloche dans ma façon de procéder.
Merci d'avance pour vos conseils et éclaircissements.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut, Le 13/08/2016 à 11:59, Doug713705 a écrit :
Je suis actuellement en train de migrer mon serveur DNS (master) vers une autre machine (@IP différente) et comme d'habitude j'ai un soucis pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit accepter les transferts de zone de la part du *nouveau* serveur maitre et de refuser les transfert de la part de l'ancien.
Un grand classique avec les NS secondaires des registrars, hébergeurs ou FAI.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
Aucune importance, le champ master du SOA n'est qu'informatif.
De son coté la zone inverse ressemble à ça: ; BIND reverse data file for local loopback interface
loopback ?
zone "redatomik.org" { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; }; allow-query { any; }; notify yes; file "/etc/bind/db.redatomik.org"; }; zone "215.172.163.in-addr.arpa" IN { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; };
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le fichier de zone.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ? Au passage, c'est le préfixe IP de golgoth99, mais le fichier de zone est visiblement construit pour golgoth98.
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue. Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer la zone redatomik.org vers nssec.online.net: Sur l'ancien serveur le /var/mog/daemon.log est explicite: Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative de transfert ce qui pose des problèmes de cohérence si je modifie la zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas mis à jour et suivant lequel des deux est interrogé, le résultat peut s'avérer différent).
Si c'est juste ça qui te chagrine, tu peux reconfigurer l'ancien serveur en esclave du nouveau serveur primaire en attendant que le secondaire d'Online soit configuré pour se synchroniser sur le nouveau primaire.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la zone au dns secondaire
A ma connaissance un transfert de zone est toujours à l'initiative de l'esclave, jamais du maître. Tout ce que le maître peut faire, c'est envoyer un NOTIFY à l'esclave pour déclencher un transfert de zone, si l'esclave est configuré correctement. Même sans cela, l'esclave est censé vérifier régulièrement avec une requête SOA si le numéro de série de la zone maître a changé et faire un transfert de zone le cas échéant.
J'ai malheureusement systématiquement eu des problèmes lors des différentes migrations du serveur DNS maitre lorsque le regisrar est online.net et visiblement je n'ai toujours pas compris ce qui cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça chez Gandi.
Salut,
Le 13/08/2016 à 11:59, Doug713705 a écrit :
Je suis actuellement en train de migrer mon serveur DNS (master) vers
une autre machine (@IP différente) et comme d'habitude j'ai un soucis
pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit
accepter les transferts de zone de la part du *nouveau* serveur maitre
et de refuser les transfert de la part de l'ancien.
Un grand classique avec les NS secondaires des registrars, hébergeurs ou
FAI.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et
dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
Aucune importance, le champ master du SOA n'est qu'informatif.
De son coté la zone inverse ressemble à ça:
; BIND reverse data file for local loopback interface
loopback ?
zone "redatomik.org" {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
allow-query { any; };
notify yes;
file "/etc/bind/db.redatomik.org";
};
zone "215.172.163.in-addr.arpa" IN {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le
fichier de zone.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc
163.172.215.0/24 ?
Au passage, c'est le préfixe IP de golgoth99, mais le fichier de zone
est visiblement construit pour golgoth98.
Le registrar est online.net et son interface de gestion des DNS est
plutôt sommaire mais, de mon point de vue, correctement renseignée
avec:
DNS Primaire: golgoth99.redatomik.org (le nouveau serveur)
DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se
synchronise sur le nouveau primaire, si l'interface est bien foutue.
Parfois il faut un peu de temps pour que le changement se propage à la
configuration du NS secondaire.
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer
la zone redatomik.org vers nssec.online.net:
Sur l'ancien serveur le /var/mog/daemon.log est explicite:
Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started
Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended
Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative
de transfert ce qui pose des problèmes de cohérence si je modifie la
zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas
mis à jour et suivant lequel des deux est interrogé, le résultat peut
s'avérer différent).
Si c'est juste ça qui te chagrine, tu peux reconfigurer l'ancien serveur
en esclave du nouveau serveur primaire en attendant que le secondaire
d'Online soit configuré pour se synchroniser sur le nouveau primaire.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la
zone au dns secondaire
A ma connaissance un transfert de zone est toujours à l'initiative de
l'esclave, jamais du maître. Tout ce que le maître peut faire, c'est
envoyer un NOTIFY à l'esclave pour déclencher un transfert de zone, si
l'esclave est configuré correctement. Même sans cela, l'esclave est
censé vérifier régulièrement avec une requête SOA si le numéro de série
de la zone maître a changé et faire un transfert de zone le cas échéant.
J'ai malheureusement systématiquement eu des problèmes lors des
différentes migrations du serveur DNS maitre lorsque le regisrar est
online.net et visiblement je n'ai toujours pas compris ce qui
cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça
chez Gandi.
Salut, Le 13/08/2016 à 11:59, Doug713705 a écrit :
Je suis actuellement en train de migrer mon serveur DNS (master) vers une autre machine (@IP différente) et comme d'habitude j'ai un soucis pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit accepter les transferts de zone de la part du *nouveau* serveur maitre et de refuser les transfert de la part de l'ancien.
Un grand classique avec les NS secondaires des registrars, hébergeurs ou FAI.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
Aucune importance, le champ master du SOA n'est qu'informatif.
De son coté la zone inverse ressemble à ça: ; BIND reverse data file for local loopback interface
loopback ?
zone "redatomik.org" { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; }; allow-query { any; }; notify yes; file "/etc/bind/db.redatomik.org"; }; zone "215.172.163.in-addr.arpa" IN { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; };
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le fichier de zone.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ? Au passage, c'est le préfixe IP de golgoth99, mais le fichier de zone est visiblement construit pour golgoth98.
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue. Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer la zone redatomik.org vers nssec.online.net: Sur l'ancien serveur le /var/mog/daemon.log est explicite: Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative de transfert ce qui pose des problèmes de cohérence si je modifie la zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas mis à jour et suivant lequel des deux est interrogé, le résultat peut s'avérer différent).
Si c'est juste ça qui te chagrine, tu peux reconfigurer l'ancien serveur en esclave du nouveau serveur primaire en attendant que le secondaire d'Online soit configuré pour se synchroniser sur le nouveau primaire.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la zone au dns secondaire
A ma connaissance un transfert de zone est toujours à l'initiative de l'esclave, jamais du maître. Tout ce que le maître peut faire, c'est envoyer un NOTIFY à l'esclave pour déclencher un transfert de zone, si l'esclave est configuré correctement. Même sans cela, l'esclave est censé vérifier régulièrement avec une requête SOA si le numéro de série de la zone maître a changé et faire un transfert de zone le cas échéant.
J'ai malheureusement systématiquement eu des problèmes lors des différentes migrations du serveur DNS maitre lorsque le regisrar est online.net et visiblement je n'ai toujours pas compris ce qui cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça chez Gandi.
Doug713705
Le 13-08-2016, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<nomv9t$16n8$) :
Salut,
Salut,
Le 13/08/2016 à 11:59, Doug713705 a écrit :
Je suis actuellement en train de migrer mon serveur DNS (master) vers une autre machine (@IP différente) et comme d'habitude j'ai un soucis pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit accepter les transferts de zone de la part du *nouveau* serveur maitre et de refuser les transfert de la part de l'ancien.
Un grand classique avec les NS secondaires des registrars, hébergeurs ou FAI.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
Aucune importance, le champ master du SOA n'est qu'informatif.
De son coté la zone inverse ressemble à ça: ; BIND reverse data file for local loopback interface
loopback ?
Aucune idée de la provenance de ce commentaire. Mauvais copier/coller, commentaire par défaut, va savoir...
zone "redatomik.org" { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; }; allow-query { any; }; notify yes; file "/etc/bind/db.redatomik.org"; }; zone "215.172.163.in-addr.arpa" IN { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; };
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le fichier de zone.
Il me semble qu'il est défini ici: @ IN NS nssec.online.net.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ? Au passage, c'est le préfixe IP de golgoth99, mais le fichier de zone est visiblement construit pour golgoth98.
Probablement pas le /24 ;-) Leur interface d'administration de la dedibox permet de modifier le reverse (ici golgoth99.redatomik.org). Au pire la zone reverse diffusée par mon serveur est ignorée.
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire était de 1W, je l'ai modifiée depuis à 1 heure.
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer la zone redatomik.org vers nssec.online.net: Sur l'ancien serveur le /var/mog/daemon.log est explicite: Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative de transfert ce qui pose des problèmes de cohérence si je modifie la zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas mis à jour et suivant lequel des deux est interrogé, le résultat peut s'avérer différent).
Si c'est juste ça qui te chagrine, tu peux reconfigurer l'ancien serveur en esclave du nouveau serveur primaire en attendant que le secondaire d'Online soit configuré pour se synchroniser sur le nouveau primaire.
C'est ce que j'ai fait mais golgoth98 (l'ancien serveur) est sensé être désactivé à la fin de la migration. Il faudra donc que tout tombe en marche à un moment ou un autre.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la zone au dns secondaire
A ma connaissance un transfert de zone est toujours à l'initiative de l'esclave, jamais du maître. Tout ce que le maître peut faire, c'est envoyer un NOTIFY à l'esclave pour déclencher un transfert de zone, si l'esclave est configuré correctement. Même sans cela, l'esclave est censé vérifier régulièrement avec une requête SOA si le numéro de série de la zone maître a changé et faire un transfert de zone le cas échéant.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais seul l'ancien serveur enchaine sur un transfert de zone. Impossible de comprendre pourquoi, et je suis du genre à préfèrer comprendre pourquoi cela ne fonctionne pas plutôt que ne pas comprendre pourquoi cela fonctione !
J'ai malheureusement systématiquement eu des problèmes lors des différentes migrations du serveur DNS maitre lorsque le regisrar est online.net et visiblement je n'ai toujours pas compris ce qui cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça chez Gandi.
Ce n'est pas fait pour me rassurer :-/ Merci de ton aide. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 13-08-2016, Pascal Hambourg nous expliquait dans
fr.comp.reseaux.ip
(<nomv9t$16n8$1@saria.nerim.net>) :
Salut,
Salut,
Le 13/08/2016 à 11:59, Doug713705 a écrit :
Je suis actuellement en train de migrer mon serveur DNS (master) vers
une autre machine (@IP différente) et comme d'habitude j'ai un soucis
pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit
accepter les transferts de zone de la part du *nouveau* serveur maitre
et de refuser les transfert de la part de l'ancien.
Un grand classique avec les NS secondaires des registrars, hébergeurs ou
FAI.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et
dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
Aucune importance, le champ master du SOA n'est qu'informatif.
De son coté la zone inverse ressemble à ça:
; BIND reverse data file for local loopback interface
loopback ?
Aucune idée de la provenance de ce commentaire.
Mauvais copier/coller, commentaire par défaut, va savoir...
zone "redatomik.org" {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
allow-query { any; };
notify yes;
file "/etc/bind/db.redatomik.org";
};
zone "215.172.163.in-addr.arpa" IN {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le
fichier de zone.
Il me semble qu'il est défini ici:
@ IN NS nssec.online.net.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc
163.172.215.0/24 ?
Au passage, c'est le préfixe IP de golgoth99, mais le fichier de zone
est visiblement construit pour golgoth98.
Probablement pas le /24 ;-)
Leur interface d'administration de la dedibox permet de modifier le
reverse (ici golgoth99.redatomik.org).
Au pire la zone reverse diffusée par mon serveur est ignorée.
Le registrar est online.net et son interface de gestion des DNS est
plutôt sommaire mais, de mon point de vue, correctement renseignée
avec:
DNS Primaire: golgoth99.redatomik.org (le nouveau serveur)
DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se
synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la
configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire
était de 1W, je l'ai modifiée depuis à 1 heure.
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer
la zone redatomik.org vers nssec.online.net:
Sur l'ancien serveur le /var/mog/daemon.log est explicite:
Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started
Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended
Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative
de transfert ce qui pose des problèmes de cohérence si je modifie la
zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas
mis à jour et suivant lequel des deux est interrogé, le résultat peut
s'avérer différent).
Si c'est juste ça qui te chagrine, tu peux reconfigurer l'ancien serveur
en esclave du nouveau serveur primaire en attendant que le secondaire
d'Online soit configuré pour se synchroniser sur le nouveau primaire.
C'est ce que j'ai fait mais golgoth98 (l'ancien serveur) est sensé être
désactivé à la fin de la migration. Il faudra donc que tout tombe en
marche à un moment ou un autre.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la
zone au dns secondaire
A ma connaissance un transfert de zone est toujours à l'initiative de
l'esclave, jamais du maître. Tout ce que le maître peut faire, c'est
envoyer un NOTIFY à l'esclave pour déclencher un transfert de zone, si
l'esclave est configuré correctement. Même sans cela, l'esclave est
censé vérifier régulièrement avec une requête SOA si le numéro de série
de la zone maître a changé et faire un transfert de zone le cas échéant.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais
seul l'ancien serveur enchaine sur un transfert de zone.
Impossible de comprendre pourquoi, et je suis du genre à préfèrer
comprendre pourquoi cela ne fonctionne pas plutôt que ne pas comprendre
pourquoi cela fonctione !
J'ai malheureusement systématiquement eu des problèmes lors des
différentes migrations du serveur DNS maitre lorsque le regisrar est
online.net et visiblement je n'ai toujours pas compris ce qui
cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça
chez Gandi.
Ce n'est pas fait pour me rassurer :-/
Merci de ton aide.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 13-08-2016, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<nomv9t$16n8$) :
Salut,
Salut,
Le 13/08/2016 à 11:59, Doug713705 a écrit :
Je suis actuellement en train de migrer mon serveur DNS (master) vers une autre machine (@IP différente) et comme d'habitude j'ai un soucis pour faire comprendre au dns secondaire (nssec.online.net) qu'il doit accepter les transferts de zone de la part du *nouveau* serveur maitre et de refuser les transfert de la part de l'ancien.
Un grand classique avec les NS secondaires des registrars, hébergeurs ou FAI.
La zone ressemble à ça (elle est similaire sur les deux serveurs) et dans les deux cas le SOA indique bien le FQDN du nouveau serveur.
Aucune importance, le champ master du SOA n'est qu'informatif.
De son coté la zone inverse ressemble à ça: ; BIND reverse data file for local loopback interface
loopback ?
Aucune idée de la provenance de ce commentaire. Mauvais copier/coller, commentaire par défaut, va savoir...
zone "redatomik.org" { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; }; allow-query { any; }; notify yes; file "/etc/bind/db.redatomik.org"; }; zone "215.172.163.in-addr.arpa" IN { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; };
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le fichier de zone.
Il me semble qu'il est défini ici: @ IN NS nssec.online.net.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ? Au passage, c'est le préfixe IP de golgoth99, mais le fichier de zone est visiblement construit pour golgoth98.
Probablement pas le /24 ;-) Leur interface d'administration de la dedibox permet de modifier le reverse (ici golgoth99.redatomik.org). Au pire la zone reverse diffusée par mon serveur est ignorée.
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire était de 1W, je l'ai modifiée depuis à 1 heure.
Pourtant, seul l'ancin serveur (golgoth98) semble capable de transférer la zone redatomik.org vers nssec.online.net: Sur l'ancien serveur le /var/mog/daemon.log est explicite: Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR started Aug 13 11:01:30 golgoth98 named[5354]: client 62.210.16.8#6718: transfer of 'redatomik.org/IN': AXFR-style IXFR ended Évidemment sur le nouveau serveur je n'ai aucune trace d'une tentative de transfert ce qui pose des problèmes de cohérence si je modifie la zone depuis le nouveau serveur auquel cas le dns secondaire n'est pas mis à jour et suivant lequel des deux est interrogé, le résultat peut s'avérer différent).
Si c'est juste ça qui te chagrine, tu peux reconfigurer l'ancien serveur en esclave du nouveau serveur primaire en attendant que le secondaire d'Online soit configuré pour se synchroniser sur le nouveau primaire.
C'est ce que j'ai fait mais golgoth98 (l'ancien serveur) est sensé être désactivé à la fin de la migration. Il faudra donc que tout tombe en marche à un moment ou un autre.
Je ne comprends pas que le nouveau serveur n'essaie pas de tranférer la zone au dns secondaire
A ma connaissance un transfert de zone est toujours à l'initiative de l'esclave, jamais du maître. Tout ce que le maître peut faire, c'est envoyer un NOTIFY à l'esclave pour déclencher un transfert de zone, si l'esclave est configuré correctement. Même sans cela, l'esclave est censé vérifier régulièrement avec une requête SOA si le numéro de série de la zone maître a changé et faire un transfert de zone le cas échéant.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais seul l'ancien serveur enchaine sur un transfert de zone. Impossible de comprendre pourquoi, et je suis du genre à préfèrer comprendre pourquoi cela ne fonctionne pas plutôt que ne pas comprendre pourquoi cela fonctione !
J'ai malheureusement systématiquement eu des problèmes lors des différentes migrations du serveur DNS maitre lorsque le regisrar est online.net et visiblement je n'ai toujours pas compris ce qui cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça chez Gandi.
Ce n'est pas fait pour me rassurer :-/ Merci de ton aide. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Pascal Hambourg
(renvoi dans le groupe, désolé pour l'envoi en mail privé) Le 13/08/2016 à 14:41, Doug713705 a écrit :
Le 13-08-2016, Pascal Hambourg nous expliquait dans
Le 13/08/2016 à 11:59, Doug713705 a écrit :
zone "215.172.163.in-addr.arpa" IN { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; };
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le fichier de zone.
Il me semble qu'il est défini ici: @ IN NS nssec.online.net.
Je n'ai vu cette ligne que dans le fichier de la zone redatomik.org, pas dans le fichier de la zone inverse.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ?
Probablement pas le /24 ;-) Leur interface d'administration de la dedibox permet de modifier le reverse (ici golgoth99.redatomik.org).
Donc pas de délégation du tout, sinon tu n'aurais pas besoin de passer par l'interface d'administration.
Au pire la zone reverse diffusée par mon serveur est ignorée.
Non, au pire la résolution DNS inverse de ton serveur est faussée pour tout ce sous-réseau et cela peut causer divers dysfonctionnements si le système l'utilise comme serveur cache récursif. Par exemple une machine dans cette plage veut transférer du courrier au MTA qui tourne sur ce serveur, ce dernier vérifie le reverse DNS et reçoit une réponse erronée qui peut lui faire refuser la communication.
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire était de 1W, je l'ai modifiée depuis à 1 heure.
La valeur de l'expire n'a rien à voir. C'est l'équivalent de l'option "masters" dans la définition de la zone qui compte.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais seul l'ancien serveur enchaine sur un transfert de zone.
Donc nssec.online.net est encore configuré avec l'ancien serveur comme master. La modification dans l'interface n'a été prise en compte que pour mettre à jour la délégation amont dans .org. Bug dans l'interface. Tu peux trafiquer tes propres configs dans tous les sens, ça n'y changera rien. Puisque tu as tes deux DNS opérationnels, tu peux essayer de supprimer nssec.online.net de la liste des NS pour ton domaine dans l'interface d'Online, puis le réintégrer un peu plus tard. Cela déclenchera peut-êtr une reconfiguration du serveur.
(renvoi dans le groupe, désolé pour l'envoi en mail privé)
Le 13/08/2016 à 14:41, Doug713705 a écrit :
Le 13-08-2016, Pascal Hambourg nous expliquait dans
Le 13/08/2016 à 11:59, Doug713705 a écrit :
zone "215.172.163.in-addr.arpa" IN {
type master;
//autoriser le dns secondaire à copier la zone
allow-transfer
{
62.210.16.8;
};
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le
fichier de zone.
Il me semble qu'il est défini ici:
@ IN NS nssec.online.net.
Je n'ai vu cette ligne que dans le fichier de la zone redatomik.org, pas
dans le fichier de la zone inverse.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc
163.172.215.0/24 ?
Probablement pas le /24 ;-)
Leur interface d'administration de la dedibox permet de modifier le
reverse (ici golgoth99.redatomik.org).
Donc pas de délégation du tout, sinon tu n'aurais pas besoin de passer
par l'interface d'administration.
Au pire la zone reverse diffusée par mon serveur est ignorée.
Non, au pire la résolution DNS inverse de ton serveur est faussée pour
tout ce sous-réseau et cela peut causer divers dysfonctionnements si le
système l'utilise comme serveur cache récursif. Par exemple une machine
dans cette plage veut transférer du courrier au MTA qui tourne sur ce
serveur, ce dernier vérifie le reverse DNS et reçoit une réponse erronée
qui peut lui faire refuser la communication.
Le registrar est online.net et son interface de gestion des DNS est
plutôt sommaire mais, de mon point de vue, correctement renseignée
avec:
DNS Primaire: golgoth99.redatomik.org (le nouveau serveur)
DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se
synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la
configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire
était de 1W, je l'ai modifiée depuis à 1 heure.
La valeur de l'expire n'a rien à voir. C'est l'équivalent de l'option
"masters" dans la définition de la zone qui compte.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais
seul l'ancien serveur enchaine sur un transfert de zone.
Donc nssec.online.net est encore configuré avec l'ancien serveur comme
master. La modification dans l'interface n'a été prise en compte que
pour mettre à jour la délégation amont dans .org. Bug dans l'interface.
Tu peux trafiquer tes propres configs dans tous les sens, ça n'y
changera rien.
Puisque tu as tes deux DNS opérationnels, tu peux essayer de supprimer
nssec.online.net de la liste des NS pour ton domaine dans l'interface
d'Online, puis le réintégrer un peu plus tard. Cela déclenchera peut-êtr
une reconfiguration du serveur.
(renvoi dans le groupe, désolé pour l'envoi en mail privé) Le 13/08/2016 à 14:41, Doug713705 a écrit :
Le 13-08-2016, Pascal Hambourg nous expliquait dans
Le 13/08/2016 à 11:59, Doug713705 a écrit :
zone "215.172.163.in-addr.arpa" IN { type master; //autoriser le dns secondaire à copier la zone allow-transfer { 62.210.16.8; };
Pour quoi faire ? nssec.online.net n'est pas défini comme NS dans le fichier de zone.
Il me semble qu'il est défini ici: @ IN NS nssec.online.net.
Je n'ai vu cette ligne que dans le fichier de la zone redatomik.org, pas dans le fichier de la zone inverse.
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ?
Probablement pas le /24 ;-) Leur interface d'administration de la dedibox permet de modifier le reverse (ici golgoth99.redatomik.org).
Donc pas de délégation du tout, sinon tu n'aurais pas besoin de passer par l'interface d'administration.
Au pire la zone reverse diffusée par mon serveur est ignorée.
Non, au pire la résolution DNS inverse de ton serveur est faussée pour tout ce sous-réseau et cela peut causer divers dysfonctionnements si le système l'utilise comme serveur cache récursif. Par exemple une machine dans cette plage veut transférer du courrier au MTA qui tourne sur ce serveur, ce dernier vérifie le reverse DNS et reçoit une réponse erronée qui peut lui faire refuser la communication.
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire était de 1W, je l'ai modifiée depuis à 1 heure.
La valeur de l'expire n'a rien à voir. C'est l'équivalent de l'option "masters" dans la définition de la zone qui compte.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais seul l'ancien serveur enchaine sur un transfert de zone.
Donc nssec.online.net est encore configuré avec l'ancien serveur comme master. La modification dans l'interface n'a été prise en compte que pour mettre à jour la délégation amont dans .org. Bug dans l'interface. Tu peux trafiquer tes propres configs dans tous les sens, ça n'y changera rien. Puisque tu as tes deux DNS opérationnels, tu peux essayer de supprimer nssec.online.net de la liste des NS pour ton domaine dans l'interface d'Online, puis le réintégrer un peu plus tard. Cela déclenchera peut-êtr une reconfiguration du serveur.
Doug713705
Le 13-08-2016, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<non6kn$18qg$) :
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ?
Probablement pas le /24 ;-) Leur interface d'administration de la dedibox permet de modifier le reverse (ici golgoth99.redatomik.org).
Donc pas de délégation du tout, sinon tu n'aurais pas besoin de passer par l'interface d'administration.
Au pire la zone reverse diffusée par mon serveur est ignorée.
Non, au pire la résolution DNS inverse de ton serveur est faussée pour tout ce sous-réseau et cela peut causer divers dysfonctionnements si le système l'utilise comme serveur cache récursif. Par exemple une machine dans cette plage veut transférer du courrier au MTA qui tourne sur ce serveur, ce dernier vérifie le reverse DNS et reçoit une réponse erronée qui peut lui faire refuser la communication.
Ah ! Du coup je ne défini aucune zone inverse. C'est ça ?
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire était de 1W, je l'ai modifiée depuis à 1 heure.
La valeur de l'expire n'a rien à voir. C'est l'équivalent de l'option "masters" dans la définition de la zone qui compte.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais seul l'ancien serveur enchaine sur un transfert de zone.
Donc nssec.online.net est encore configuré avec l'ancien serveur comme master. La modification dans l'interface n'a été prise en compte que pour mettre à jour la délégation amont dans .org. Bug dans l'interface. Tu peux trafiquer tes propres configs dans tous les sens, ça n'y changera rien. Puisque tu as tes deux DNS opérationnels, tu peux essayer de supprimer nssec.online.net de la liste des NS pour ton domaine dans l'interface d'Online, puis le réintégrer un peu plus tard. Cela déclenchera peut-êtr une reconfiguration du serveur.
Je vais essayer ça :) Merci. -- Hey Mec, voici les photos de nos routes Prises d'avion par nuit de brouillard Dans ce vieux catalogue des doutes Aux pages moisies par le hasard. -- H.F. Thiéfaine, Errer humanum est
Le 13-08-2016, Pascal Hambourg nous expliquait dans
fr.comp.reseaux.ip
(<non6kn$18qg$1@saria.nerim.net>) :
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc
163.172.215.0/24 ?
Probablement pas le /24 ;-)
Leur interface d'administration de la dedibox permet de modifier le
reverse (ici golgoth99.redatomik.org).
Donc pas de délégation du tout, sinon tu n'aurais pas besoin de passer
par l'interface d'administration.
Au pire la zone reverse diffusée par mon serveur est ignorée.
Non, au pire la résolution DNS inverse de ton serveur est faussée pour
tout ce sous-réseau et cela peut causer divers dysfonctionnements si le
système l'utilise comme serveur cache récursif. Par exemple une machine
dans cette plage veut transférer du courrier au MTA qui tourne sur ce
serveur, ce dernier vérifie le reverse DNS et reçoit une réponse erronée
qui peut lui faire refuser la communication.
Ah ! Du coup je ne défini aucune zone inverse. C'est ça ?
Le registrar est online.net et son interface de gestion des DNS est
plutôt sommaire mais, de mon point de vue, correctement renseignée
avec:
DNS Primaire: golgoth99.redatomik.org (le nouveau serveur)
DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se
synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la
configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire
était de 1W, je l'ai modifiée depuis à 1 heure.
La valeur de l'expire n'a rien à voir. C'est l'équivalent de l'option
"masters" dans la définition de la zone qui compte.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais
seul l'ancien serveur enchaine sur un transfert de zone.
Donc nssec.online.net est encore configuré avec l'ancien serveur comme
master. La modification dans l'interface n'a été prise en compte que
pour mettre à jour la délégation amont dans .org. Bug dans l'interface.
Tu peux trafiquer tes propres configs dans tous les sens, ça n'y
changera rien.
Puisque tu as tes deux DNS opérationnels, tu peux essayer de supprimer
nssec.online.net de la liste des NS pour ton domaine dans l'interface
d'Online, puis le réintégrer un peu plus tard. Cela déclenchera peut-êtr
une reconfiguration du serveur.
Je vais essayer ça :)
Merci.
--
Hey Mec, voici les photos de nos routes
Prises d'avion par nuit de brouillard
Dans ce vieux catalogue des doutes
Aux pages moisies par le hasard.
-- H.F. Thiéfaine, Errer humanum est
Le 13-08-2016, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<non6kn$18qg$) :
Tu es sûr qu'Online te délègue la gestion DNS inverse de son bloc 163.172.215.0/24 ?
Probablement pas le /24 ;-) Leur interface d'administration de la dedibox permet de modifier le reverse (ici golgoth99.redatomik.org).
Donc pas de délégation du tout, sinon tu n'aurais pas besoin de passer par l'interface d'administration.
Au pire la zone reverse diffusée par mon serveur est ignorée.
Non, au pire la résolution DNS inverse de ton serveur est faussée pour tout ce sous-réseau et cela peut causer divers dysfonctionnements si le système l'utilise comme serveur cache récursif. Par exemple une machine dans cette plage veut transférer du courrier au MTA qui tourne sur ce serveur, ce dernier vérifie le reverse DNS et reçoit une réponse erronée qui peut lui faire refuser la communication.
Ah ! Du coup je ne défini aucune zone inverse. C'est ça ?
Le registrar est online.net et son interface de gestion des DNS est plutôt sommaire mais, de mon point de vue, correctement renseignée avec: DNS Primaire: golgoth99.redatomik.org (le nouveau serveur) DNS secondaire: nssec.online.net
C'est tout ce qui devrait être nécessaire pour que le NS secondaire se synchronise sur le nouveau primaire, si l'interface est bien foutue.
C'est ce qu'il me semble également.
Parfois il faut un peu de temps pour que le changement se propage à la configuration du NS secondaire.
Ça fait une semaine que ça dure et même si la valeur initiale du exprire était de 1W, je l'ai modifiée depuis à 1 heure.
La valeur de l'expire n'a rien à voir. C'est l'équivalent de l'option "masters" dans la définition de la zone qui compte.
Sur l'ancien serveur comme sur le nouveau j'ai une trace des NOTIFY mais seul l'ancien serveur enchaine sur un transfert de zone.
Donc nssec.online.net est encore configuré avec l'ancien serveur comme master. La modification dans l'interface n'a été prise en compte que pour mettre à jour la délégation amont dans .org. Bug dans l'interface. Tu peux trafiquer tes propres configs dans tous les sens, ça n'y changera rien. Puisque tu as tes deux DNS opérationnels, tu peux essayer de supprimer nssec.online.net de la liste des NS pour ton domaine dans l'interface d'Online, puis le réintégrer un peu plus tard. Cela déclenchera peut-êtr une reconfiguration du serveur.
Je vais essayer ça :) Merci. -- Hey Mec, voici les photos de nos routes Prises d'avion par nuit de brouillard Dans ce vieux catalogue des doutes Aux pages moisies par le hasard. -- H.F. Thiéfaine, Errer humanum est
Pascal Hambourg
Le 13/08/2016 à 15:36, Doug713705 a écrit :
Ah ! Du coup je ne défini aucune zone inverse. C'est ça ?
C'est ça. Ou bien, si tu y tiens, une zone pour la seule adresse et non pour le sous-réseau entier.
Le 13/08/2016 à 15:36, Doug713705 a écrit :
Ah ! Du coup je ne défini aucune zone inverse. C'est ça ?
C'est ça. Ou bien, si tu y tiens, une zone pour la seule adresse et non
pour le sous-réseau entier.
Ah ! Du coup je ne défini aucune zone inverse. C'est ça ?
C'est ça. Ou bien, si tu y tiens, une zone pour la seule adresse et non pour le sous-réseau entier.
Doug713705
Le 13-08-2016, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<nomv9t$16n8$) :
J'ai malheureusement systématiquement eu des problèmes lors des différentes migrations du serveur DNS maitre lorsque le regisrar est online.net et visiblement je n'ai toujours pas compris ce qui cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça chez Gandi.
Pour la petite histoire il se trouve qu'il existe un menu dans l'interface de gestion de la dedibox (!= l'interface de gestion du domaine) dans laquelle il faut associer la dedibox concernée, un dns secondaire (nssec.online.net) et le nom de domaine concerné (redatomik.org). Après avoir découvert ce menu, il a encore fallu désactiver cette association sur l'ancienne dedibox pour pouvoir l'appliquer à la nouvelle. Bref, l'interface n'est pas claire du tout mais avec l'aide de l'équipe technique présente sur leur chan irc, j'ai fini par m'en sortir. Mais maintenant que tout est Ok je m'aperçois qu'Online ne gère pas DNSSEC /o /me pense sérieusement à transférer son domaine chez Gandi. Merci pour ton aide. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 13-08-2016, Pascal Hambourg nous expliquait dans
fr.comp.reseaux.ip
(<nomv9t$16n8$1@saria.nerim.net>) :
J'ai malheureusement systématiquement eu des problèmes lors des
différentes migrations du serveur DNS maitre lorsque le regisrar est
online.net et visiblement je n'ai toujours pas compris ce qui
cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça
chez Gandi.
Pour la petite histoire il se trouve qu'il existe un menu dans
l'interface de gestion de la dedibox (!= l'interface de gestion du
domaine) dans laquelle il faut associer la dedibox concernée, un dns
secondaire (nssec.online.net) et le nom de domaine concerné
(redatomik.org).
Après avoir découvert ce menu, il a encore fallu désactiver cette
association sur l'ancienne dedibox pour pouvoir l'appliquer à la
nouvelle.
Bref, l'interface n'est pas claire du tout mais avec l'aide de l'équipe
technique présente sur leur chan irc, j'ai fini par m'en sortir.
Mais maintenant que tout est Ok je m'aperçois qu'Online ne gère pas
DNSSEC /o
/me pense sérieusement à transférer son domaine chez Gandi.
Merci pour ton aide.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 13-08-2016, Pascal Hambourg nous expliquait dans fr.comp.reseaux.ip (<nomv9t$16n8$) :
J'ai malheureusement systématiquement eu des problèmes lors des différentes migrations du serveur DNS maitre lorsque le regisrar est online.net et visiblement je n'ai toujours pas compris ce qui cloche dans ma façon de procéder.
Rassure-toi (ou pas) : ce n'est pas propre à Online, j'ai déjà vu ça chez Gandi.
Pour la petite histoire il se trouve qu'il existe un menu dans l'interface de gestion de la dedibox (!= l'interface de gestion du domaine) dans laquelle il faut associer la dedibox concernée, un dns secondaire (nssec.online.net) et le nom de domaine concerné (redatomik.org). Après avoir découvert ce menu, il a encore fallu désactiver cette association sur l'ancienne dedibox pour pouvoir l'appliquer à la nouvelle. Bref, l'interface n'est pas claire du tout mais avec l'aide de l'équipe technique présente sur leur chan irc, j'ai fini par m'en sortir. Mais maintenant que tout est Ok je m'aperçois qu'Online ne gère pas DNSSEC /o /me pense sérieusement à transférer son domaine chez Gandi. Merci pour ton aide. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Pascal Hambourg
Le 14/08/2016 à 13:16, Doug713705 a écrit :
Pour la petite histoire il se trouve qu'il existe un menu dans l'interface de gestion de la dedibox (!= l'interface de gestion du domaine) dans laquelle il faut associer la dedibox concernée, un dns secondaire (nssec.online.net) et le nom de domaine concerné (redatomik.org).
Donc le service de DNS secondaire assuré par nssec.online.net est fourni par Dedibox, l'hébergeur du serveur dédié, et non par Online, le registrar du domaine. Comme c'est un peu le même groupe, il fallait le savoir...
Le 14/08/2016 à 13:16, Doug713705 a écrit :
Pour la petite histoire il se trouve qu'il existe un menu dans
l'interface de gestion de la dedibox (!= l'interface de gestion du
domaine) dans laquelle il faut associer la dedibox concernée, un dns
secondaire (nssec.online.net) et le nom de domaine concerné
(redatomik.org).
Donc le service de DNS secondaire assuré par nssec.online.net est fourni
par Dedibox, l'hébergeur du serveur dédié, et non par Online, le
registrar du domaine. Comme c'est un peu le même groupe, il fallait le
savoir...
Pour la petite histoire il se trouve qu'il existe un menu dans l'interface de gestion de la dedibox (!= l'interface de gestion du domaine) dans laquelle il faut associer la dedibox concernée, un dns secondaire (nssec.online.net) et le nom de domaine concerné (redatomik.org).
Donc le service de DNS secondaire assuré par nssec.online.net est fourni par Dedibox, l'hébergeur du serveur dédié, et non par Online, le registrar du domaine. Comme c'est un peu le même groupe, il fallait le savoir...
