Merci à toi !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.
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 ! Wink
WARN - SOA Serial Number
EDIT: la je ne sais pas du tout.
ARN - 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 ! 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 ?
Ben parce que mon serveur joue le rôle de serveur DNS également, donc il faut bien qu'il soit open. :?DaviXX a dit:FAIL - Open DNS servers
EDIT: ok, ça c'est normal ! Wink
Pourquoi est-ce normal ?
:? :? :?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é)
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.
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..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,
thierry8 a dit:Ben parce que mon serveur joue le rôle de serveur DNS également, donc il faut bien qu'il soit open. :?
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.
[...]
example.com. IN SOA srvXXX.sd-france.net. postmaster.example.com. (
2006021102 ;serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
38400 ) ;Cache TTL
[...]
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..
Et y a t-il un moyen de se protéger ?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...
Je suis sous Plesk, et je n'ai malheureusement pas ce fichier.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
Oui, je n'y avais pas pensé, mais je n'ai pas de mx de secour.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,
thierry8 a dit:Et y a t-il un moyen de se protéger ?
je suppose que oui, mais comment ? (est-ce complexe ?)
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 ? :?
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...
➡️ 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