DNS secondaire, comment vérifier qu'il donne la route ?

  • Auteur de la discussion Auteur de la discussion thierry8
  • Date de début Date de début
WRInaute accro
Bonjour,

Je souhaiterai savoir s'il est possible de vérifier le dns secondaire ?

S'il indique bien la bonne route en cas d'inaptitude du dns principale.

Merci de votre aide.
 
WRInaute discret
Ca peut parfois etre utile de verifier si les dns secondaires donne bien les bonnes infos si par exemple on a configurer le serveur primaire avec des restrictions sur les serveurs secondaires qui peuvent recevoir les donnees (par exemple, uniquement tel serveur avec tel ip peut devenir un secondaire).

Pour verifier cela, le plus simple est d'utiliser sur un serveur linuxla commande suivante :
nslookup - ns2.ton-domaine.com

puis tu entres l'adresse de ton site et tu verras ce que ton serveur secondaire repondra.
 
WRInaute accro
Oui:
https://www.google.fr/search?hl=fr&q=DNS ... cher&meta=
https://www.google.fr/search?hl=fr&q=DNS ... cher&meta=

Non mais c'est pas grave désolé.

Il est vrai que je suis de nature curieuse et je pose trop de questions, je vais faire une pose WRI pendant une petite semaine, parce que je me rend bien compte qu'avec mes questions je gonfle. (susceptible également par la force des choses)

bye et je m'excuse auprès de tout le monde.

:arrow: :arrow: :arrow: :arrow: :arrow: :arrow: :arrow: :arrow:
 
WRInaute accro
Cranky21 a dit:
Ca peut parfois etre utile de verifier si les dns secondaires donne bien les bonnes infos si par exemple on a configurer le serveur primaire avec des restrictions sur les serveurs secondaires qui peuvent recevoir les donnees (par exemple, uniquement tel serveur avec tel ip peut devenir un secondaire).

Pour verifier cela, le plus simple est d'utiliser sur un serveur linuxla commande suivante :
nslookup - ns2.ton-domaine.com

puis tu entres l'adresse de ton site et tu verras ce que ton serveur secondaire repondra.
Merci à toi ! ;)
EDIT: je suis debian, la commande est inexistante. :?

Allé, je file...
 
Nouveau WRInaute
Bonjour,

Tu peut utiliser un outil web :
http://www.dnsstuff.com/tools/traversal ... com&type=A
dans ce cas, ça te permet de vérifier que zone.com pointe bien vers la même IP aux yeux de tes deux serveurs dns. Tu as pas mal d'outils sur http://www.dnsstuff.com

Sinon en ligne de commande, tu as :

$ dig a zone.com @serveurainterroger.net

par exemple

$ dig a www.chanial.com @ns2.sd-france.net

va interroger ns2.sd-france.net pour connaitre l'adresse IP pointée par www.chanial.com

Si tu as DJBDNS, tu peut utiliser dnsq, mais bon, je pense pas que tu ait ce programme d'installé.

Cordialement,
 
WRInaute accro
DaviXX a parfaitement répondu.

Tu complètes avec un petit dnsreport.com pour vérifier que tout va bien, et après plus de soucis :p.
 
WRInaute accro
Et bien merci à vous...

J'en avais bien besoin...

Quelques problèmes rencontré comme je le suspectais avec le dns secondaire.

Merci.
 
WRInaute accro
Je viens à vous car il y a deux ou trois truc que je ne sais pas à quoi ça correspond.

FAIL - Open DNS servers
EDIT: ok, ça c'est normal ! ;)

WARN - SOA Serial Number
EDIT: la je ne sais pas du tout.

WARN - SPF record
EDIT: je suis entrain de regarder, si vous avez un lien pour configurer un SPF, je suis preneur.

WARN - Nameservers on separate class C's
EDIT: bon ben ça aussi ! ;)
Est-ce que j'ai bien compris: en fait c'est parce que le dns primaire et secondaire sont dans la même zone ?

J'en est réglé quelques uns..
mais la je sèche.
 
WRInaute accro
Pour le SPF record, c'est good.

Pour ceux qui veulent savoir:
v=spf1 a mx ip4:xx.xx.xx.xx ~all

Je n'en suis pas certain, mais ça fonctionne. !;)

Si j'ai bien compris le site http://www.openspf.org/, cela permet de n'envoyer des messages dont les domaines possède ce type qu'a partir du serveur (ip indiquée).

Par contre si l'on passe via notre FAI, il faut donc ajouter l'ip du FAI ?
 
Nouveau WRInaute
Bonjour,

Je viens à vous car il y a deux ou trois truc que je ne sais pas à quoi ça correspond.

Allons-y !

FAIL - Open DNS servers
EDIT: ok, ça c'est normal ! Wink

Pourquoi est-ce normal ?

WARN - SOA Serial Number
EDIT: la je ne sais pas du tout.

Il n'y a pas un détail de l'erreur ? a priori, il y a deux avertissements possibles :

=> Les serveurs DNS de ton nom de domaine n'ont pas le même SERIAL, ce qui est grave, puisque si ils n'ont pas le même serial ça implique généralement que les informations (POINTAGE/ALIAS/...) ne sont pas identiques.

En effet, lorsque tu modifies ta zone DNS, du dois incrémenter (ajouter 1) à ton serial, par évidence, si deux serveurs DNS n'ont pas me même serial pour une zone donnée, cela veut dire, que les modifications que tu as apporté sur l'un ne sont pas sur l'autre, et que si on interroge le serveur qui a le serial le plus petit, il va probablement répondre quelque chose de faux, où bien, il ne va pas connaitre la réponse.

=> Ou bien, ton serial n'est pas de la forme YYYYMMDDXX (les derniers XX peutvent être des secondes ou autres, l'esssentiel c'est que si tu fais 2 modifications dans la même journée, le plus récent ait un serial plus élevé)

ARN - SPF record
EDIT: je suis entrain de regarder, si vous avez un lien pour configurer un SPF, je suis preneur.

J'ai vu que tu avais déjà trouvé une solution, sache aussi, que SPF est conseillé mais :

=> Il n'est pas du tout obligatoire (quoi que bien utile pour que les mails sortants du domaine/serveur arrive a passer chez hotmail/aol/...)

=> il vaut mieux ne pas mettre d'enregistrement SPF plutôt que d'en mettre un mauvais.

=> un grand nombre de personnes ne les utilisent (ça a des plus et des moins au vu des deux points précédents).


WARN - Nameservers on separate class C's
EDIT: bon ben ça aussi ! Wink
Est-ce que j'ai bien compris: en fait c'est parce que le dns primaire et secondaire sont dans la même zone ?

Pas dans la même zone... dans la même classe d'ip, le rôle d'un serveur DNS/MX secondaire :

=> être présent pour répondre aux requetes DNS/MX si le primaire n'est pas disponible

pourquoi le primaire ne serais pas disponible ?

=> panne matérielle ( là on est sauvé, le secondaire peut jouer son role)

=> panne réseau !!!!

le secondaire ne sert a rien, puisque si ton hébergeur a un probleme reseau sur la classe d'ip de ton premier serveur, ton second sera lui aussi en panne et sera inutile !

Cordialement,
 
WRInaute accro
DaviXX a dit:
FAIL - Open DNS servers
EDIT: ok, ça c'est normal ! Wink

Pourquoi est-ce normal ?
Ben parce que mon serveur joue le rôle de serveur DNS également, donc il faut bien qu'il soit open. :?

DaviXX a dit:
WARN - SOA Serial Number
EDIT: la je ne sais pas du tout.

Il n'y a pas un détail de l'erreur ? a priori, il y a deux avertissements possibles :

=> Les serveurs DNS de ton nom de domaine n'ont pas le même SERIAL, ce qui est grave, puisque si ils n'ont pas le même serial ça implique généralement que les informations (POINTAGE/ALIAS/...) ne sont pas identiques.

En effet, lorsque tu modifies ta zone DNS, du dois incrémenter (ajouter 1) à ton serial, par évidence, si deux serveurs DNS n'ont pas me même serial pour une zone donnée, cela veut dire, que les modifications que tu as apporté sur l'un ne sont pas sur l'autre, et que si on interroge le serveur qui a le serial le plus petit, il va probablement répondre quelque chose de faux, où bien, il ne va pas connaitre la réponse.

=> Ou bien, ton serial n'est pas de la forme YYYYMMDDXX (les derniers XX peutvent être des secondes ou autres, l'esssentiel c'est que si tu fais 2 modifications dans la même journée, le plus récent ait un serial plus élevé)
:? :? :?
Oui j'ai effectivement une erreur, j'opterai plutôt pour le YYYYMMDDXX.
Mais que faut-il faire pour y remédier ?
Je n'ai pas très bien saisie à quoi cela servait.
WARNING: Your SOA serial number is: 1142411729. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change.

Your SOA serial appears to be the number of seconds since midnight 01 Jan 1970 when the last DNS change was made (tinydns format). That works out to be Wed Mar 15 03:35:29 2006 EST.

DaviXX a dit:
WARN - Nameservers on separate class C's
EDIT: bon ben ça aussi ! Wink
Est-ce que j'ai bien compris: en fait c'est parce que le dns primaire et secondaire sont dans la même zone ?

Pas dans la même zone... dans la même classe d'ip, le rôle d'un serveur DNS/MX secondaire :

=> être présent pour répondre aux requetes DNS/MX si le primaire n'est pas disponible

pourquoi le primaire ne serais pas disponible ?

=> panne matérielle ( là on est sauvé, le secondaire peut jouer son role)

=> panne réseau !!!!

le secondaire ne sert a rien, puisque si ton hébergeur a un probleme reseau sur la classe d'ip de ton premier serveur, ton second sera lui aussi en panne et sera inutile !

Cordialement,
Mais de toute façon dans mon cas, étant donné que le serveur dns primaire héberge également le site, s'il est en panne même si le dns secondaire prend le relais, ça ne sert à rien..


Merci beaucoup de ton aide.
 
Nouveau WRInaute
thierry8 a dit:
Ben parce que mon serveur joue le rôle de serveur DNS également, donc il faut bien qu'il soit open. :?

Non, open veut dire qu'il réponds publiquement aux requêtes DNS pour des zones sur lesquels tu n'as pas autorités.

Bref, sur ton PC, en serveur de nom, si on met l'ip de ton serveur dédié, boom, on peut résoudre les noms, on peut flooder ton serveur de requêtes aussi...

thierry8 a dit:
Oui j'ai effectivement une erreur, j'opterai plutôt pour le YYYYMMDDXX.
Mais que faut-il faire pour y remédier ?
Je n'ai pas très bien saisie à quoi cela servait.
WARNING: Your SOA serial number is: 1142411729. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change.

Your SOA serial appears to be the number of seconds since midnight 01 Jan 1970 when the last DNS change was made (tinydns format). That works out to be Wed Mar 15 03:35:29 2006 EST.

en gros quand on parle de DNS, on a :

=> Un serveur DNS Master pour une zone (celui où tu feras des modifications quand tu aura besoin d'en faire)

=> Un ou plusieurs serveurs DNS Slave pour une zone (ceux où la configuration DNS de la zone en question va être récupéré, généralement automatiquement grâce à AXFR qui est par défaut utilisé par BIND)

Comment ça se passe ?

=> les Slave vont interroger le Master pour connaitre le serial, si il a changé ET qu'il est plus grand que celui que le slave avait déjà, alors il va mettre à jours la zone de son coté.

C'est pour ça que :

=> si tu n'incrémentes pas le sérial sur ton Master quand tu y fait une modification, alors le slave ne s'en rends pas compte, et il ne met pas a jour la zone (et la tu as des symptomes bizarres !!!)

=> la RFC te conseille de mettre un serial du genre YYYYMMDDnn parce que il est plus clair d'utiliser une norme pour le serial, qui permet, en un coup d'oeil, de voir la date de la modification, sachant que le nn est surtout la au cas ou tu fais plusieurs update DNS dans une même journée.

Comment mettre un serial sous la forme "YYYYMMDDnn" ?

tu as bind je suppose (process "named"), dans ce cas tu dois avoir un fichier du type "/var/named/conf/zone.conf.host", tu l'édites et tu dois avoir, en haut du fichier un truc genre :

Code:
[...]
example.com.  IN      SOA     srvXXX.sd-france.net.     postmaster.example.com. (
                2006021102      ;serial
                10800           ;Refresh
                3600            ;Retry
                604800          ;Expire
                38400 )         ;Cache TTL
[...]

là il te suffit de fixer la ligne serial


thierry8 a dit:
Mais de toute façon dans mon cas, étant donné que le serveur dns primaire héberge également le site, s'il est en panne même si le dns secondaire prend le relais, ça ne sert à rien..

cela est utile dans le cas où, entre autre / par exemple :

=> tu as définis un MX secondaire qui se trouve en dehors de ton réseau, si on ne peut pas savoir quel est le MX secondaire en cas de panne du principal, le mail est généralement retourné. alors que si on peut joindre un secondaire, on va lui relayer le mail en attendant que le primaire soit de retour.

=> normalement, les fournisseurs de serveurs dédiés te proposes d'accepter de jouer le rôle de MX et DNS secondaire.

Cordialement,
 
WRInaute accro
DaviXX a dit:
thierry8 a dit:
Ben parce que mon serveur joue le rôle de serveur DNS également, donc il faut bien qu'il soit open. :?

Non, open veut dire qu'il réponds publiquement aux requêtes DNS pour des zones sur lesquels tu n'as pas autorités.

Bref, sur ton PC, en serveur de nom, si on met l'ip de ton serveur dédié, boom, on peut résoudre les noms, on peut flooder ton serveur de requêtes aussi...
Et y a t-il un moyen de se protéger ?
je suppose que oui, mais comment ? (est-ce complexe ?)


DaviXX a dit:
thierry8 a dit:
Oui j'ai effectivement une erreur, j'opterai plutôt pour le YYYYMMDDXX.
Mais que faut-il faire pour y remédier ?
Je n'ai pas très bien saisie à quoi cela servait.
WARNING: Your SOA serial number is: 1142411729. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change.

Your SOA serial appears to be the number of seconds since midnight 01 Jan 1970 when the last DNS change was made (tinydns format). That works out to be Wed Mar 15 03:35:29 2006 EST.

en gros quand on parle de DNS, on a :

=> Un serveur DNS Master pour une zone (celui où tu feras des modifications quand tu aura besoin d'en faire)

=> Un ou plusieurs serveurs DNS Slave pour une zone (ceux où la configuration DNS de la zone en question va être récupéré, généralement automatiquement grâce à AXFR qui est par défaut utilisé par BIND)

Comment ça se passe ?

=> les Slave vont interroger le Master pour connaitre le serial, si il a changé ET qu'il est plus grand que celui que le slave avait déjà, alors il va mettre à jours la zone de son coté.

C'est pour ça que :

=> si tu n'incrémentes pas le sérial sur ton Master quand tu y fait une modification, alors le slave ne s'en rends pas compte, et il ne met pas a jour la zone (et la tu as des symptomes bizarres !!!)

=> la RFC te conseille de mettre un serial du genre YYYYMMDDnn parce que il est plus clair d'utiliser une norme pour le serial, qui permet, en un coup d'oeil, de voir la date de la modification, sachant que le nn est surtout la au cas ou tu fais plusieurs update DNS dans une même journée.

Comment mettre un serial sous la forme "YYYYMMDDnn" ?

tu as bind je suppose (process "named"), dans ce cas tu dois avoir un fichier du type "/var/named/conf/zone.conf.host", tu l'édites et tu dois avoir, en haut du fichier un truc genre :

Code:
[...]
example.com.  IN      SOA     srvXXX.sd-france.net.     postmaster.example.com. (
                2006021102      ;serial
                10800           ;Refresh
                3600            ;Retry
                604800          ;Expire
                38400 )         ;Cache TTL
[...]

là il te suffit de fixer la ligne serial
Je suis sous Plesk, et je n'ai malheureusement pas ce fichier.
En tout cas il ne doit pas se nommer ainsi.
Une question tout de même, il faudrait alors l'éditer à chaque fois que l'on rajoute un domaine ? :?

DaviXX a dit:
thierry8 a dit:
Mais de toute façon dans mon cas, étant donné que le serveur dns primaire héberge également le site, s'il est en panne même si le dns secondaire prend le relais, ça ne sert à rien..

cela est utile dans le cas où, entre autre / par exemple :

=> tu as définis un MX secondaire qui se trouve en dehors de ton réseau, si on ne peut pas savoir quel est le MX secondaire en cas de panne du principal, le mail est généralement retourné. alors que si on peut joindre un secondaire, on va lui relayer le mail en attendant que le primaire soit de retour.

=> normalement, les fournisseurs de serveurs dédiés te proposes d'accepter de jouer le rôle de MX et DNS secondaire.

Cordialement,
Oui, je n'y avais pas pensé, mais je n'ai pas de mx de secour.
Et pour le MX secondaire, il faut payer...
 
WRInaute accro
En fouillant dans Plesk j'ai trouvé, donc pour ceux qui sont dans le même as que moi: /home/var/named/run-root/var/...

La dedans il y a plusieurs fichiers.

Pour chaque domaine il y en a un, c'est bien cela ?
En revanche, il faut faire cela pour chaque domaine ?
Et quand est-ce qu'il faut le modifier ?
La je met bien la date d'aujourd'hui.

Merci encore de ton aide !
:D

EDIT: j'ai mis la date d'aujourd'hui et je n'ai plus d'erreur.
Si tu pouvais encore me renseigner par rapport au reste. :oops: Merci

EDIT: non je me suis trompé, j'ai toujours l'erreur, mais il n'a pas pris en compte ce que j'ai inscrit: WARNING: Your SOA serial number is: 1142411729.

EDIT: grrr ! quel c** que je suis ! bind n'avait pas encore redémarrer.
donc finallement la prise en compte est ok.
 
Nouveau WRInaute
thierry8 a dit:
Et y a t-il un moyen de se protéger ?
je suppose que oui, mais comment ? (est-ce complexe ?)

J'ai pas le code sous les yeux, mais ça doit être quelque chose comme "allow-recursion: none"

cherche sous google, et pense a AUTORISER la recursion vers tes DNS secondaires.

thierry8 a dit:
Je suis sous Plesk, et je n'ai malheureusement pas ce fichier.
En tout cas il ne doit pas se nommer ainsi.
Une question tout de même, il faudrait alors l'éditer à chaque fois que l'on rajoute un domaine ? :?

Laisse tomber... pour commencer c'est pas grave que le serial ne soit pas dans ce style là,

et surtout, avec des outils comme PLESK, vaut mieux le laisser gerer comme il veut.

thierry8 a dit:
Oui, je n'y avais pas pensé, mais je n'ai pas de mx de secour.
Et pour le MX secondaire, il faut payer...

Ok.
Pas mal d'hébergeur proposent ça gratuitement, tu es chez qui ?

Cordialement,
 
WRInaute accro
- Je suis chez Oxyd. (pas terrible en support, je tiens à le signaler)

- Concernant le Serial, peut tu juste m'indiquer, s'il faut le modifier souvent ?
A chaque modification par rapport au domaine ?
(car je l'ai déjà modifié, et je ne souhaiterai pas que cela pose des problèmes)

- pour allow-recursion: none je vais chercher tout ça.
En revanche, c'est à quel niveau qu'il faut l'inscrire ?

Je te remercie.
 
WRInaute accro
Le numéro de série sert à identifier la "version" du fichier de zone : plus il est grand, plus le fichier de zone est récent.

Il faut donc incrémenter le numéro de série à chaque nouvelle modification.

Cela sert notemment aux serveurs secondaires : s'ils voient que le numéro de série du serveur primaire est plus élevé que le leur, ils mettent à jour les infos.

Pour plus de simplicité, il est conseillé d'utiliser le format YYYYMMDDNN, mais ce n'est pas du tout obligatoire, tant que ça "monte". Et comme le dit DaviXX, vaut mieux laisser Plesk gérer, si tu modifies manuellement, il va s'enmêler les pinceaux.

En cadeau, http://rollernet.us/ propose gratuitement un serveur MX secondaire :) (j'ai eu du mal pour le trouvé celui là ^^).

Aussi : tu dis que ce n'est pas trop grave que les deux IPs soient sur la même classe C, parce que si ton hébergeur est down, tout sera down.

Ce n'est pas forcément vrai !!!
Il y les autres services (je pense aux emails par exemple), et avoir le DNS secondaire qui marche et qui est sous ton controle peut être très utile pour changer rapidement d'IP et passer sur un hébergement temporaire.
 

➡️ Offre MyRankingMetrics ⬅️

pré-audit SEO gratuit avec RM Tech (+ avis d'expert)
coaching offert aux clients (avec Olivier Duffez ou Fabien Faceries)

Voir les détails ici

coaching SEO
Discussions similaires
Haut