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

[thierry8]

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.

[zimounet]

message supprimé

[Cranky21]

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.

[thierry8]

Oui:
http://www.google.fr/search?hl=fr&q=DNS ... cher&meta=
http://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.

[thierry8]

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...

[DaviXX]

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,

[zimounet]

message supprimé

[wullon]

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.

[thierry8]

Et bien merci à vous...

J'en avais bien besoin...

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

Merci.

[thierry8]

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.

[thierry8]

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 ?

[DaviXX]

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,

[thierry8]

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.

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.

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.

[DaviXX]

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...

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: Tout sélectionner

[...]
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

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,

[thierry8]

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 ?)

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: Tout sélectionner

[...]
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 ?

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...