Aller au contenu

Configuration d'un serveur DNS et reverse


renaud63

Sujets conseillés

Bonjour à tous,

Après avoir lu des dizaines de tutos et parcouru autant de forum, je viens demander de l'aide car la configuration de mon serveur de DSN n'est toujours pas bonne.

- 1 serveur dédié linux / Plesk9 commandé chez 1 and 1

- Côté 1 and 1 : 2 adresses IP configurées comme suit :

* IP1 (principale) => ns2.mon-serveur-nom.com

* IP2 => ns1.mon-serveur-nom.com

- Coté PLesk, pour le domaine mon-serveur-nom.com, la zone DNS

* IP1/24 PTR mon-serveur-nom.com

* IP2/24 PTR mon-serveur-nom.com

* mon-serveur-nom.com NS ns1.mon-serveur-nom.com

* mon-serveur-nom.com NS ns2.mon-serveur-nom.com

* ns1.mon-serveur-nom.com A IP2

* ns2.mon-serveur-nom.com A IP1

* mon-serveur-nom.com A IP1

Je passe volontairement sur les entrées MX, CNAME...pour ne pas alourdir le post.

- Les autres sites hébergés sur le dédié sont configurés comme suit :

* domaineX.com A IP1

* domaineX.com NS ns1.mon-serveur-nom.com

* domaineX.com NS ns2.mon-serveur-nom.com

Lorsque je fais un test sur l'IP1 (principale), j'obtiens :

Looking up Reverse DNS for IP Address: [iP1]

RDNS for IP1 is: [ns2.mon-serveur-nom.com] - (PTR record - 160.217.106.87.in-addr.arpa) // note : j'ignore d'où provient cette IP "PTR record"!

ERROR - Lookup Failed for [ns2.mon-serveur-nom.com]

ERROR - Reverse Lookup Failed

IP [iP1] does not match []

ET le même test sur l'IP2

Looking up Reverse DNS for IP Address: [iP2]

RDNS for IP2 is: [ns1.mon-serveur-nom.com] - (PTR record - 152.94.165.213.in-addr.arpa)

IP Address for ns1.mon-serveur-nom.com is: [iP2]

SUCCESS! - Forward Confirmed Reverse DNS is CORRECT!

The IP address for the reverse lookup name matches the original IP

Qu'est ce qui cloche la dedans ?

Merci d'avance pour aide précieuse.

Lien vers le commentaire
Partager sur d’autres sites

Le reverse pour l'IP a.b.c.d s'obtient par un enregistrement PTR pour le nom d.c.b.a.in-addr.arpa, pas pour le nom a.b.c.d.mon-serveur.com (c'est logique, puisqu'on part de l'adresse IP et qu'on n'a aucune idée du ou des domaines associés et que c'est justement ce qu'on est en train de chercher).

Donc:

- pas besoin de mettre d'enregistrements PTR dans ta zone (personne ne viendra jamais les demander)

- il faut (éventuellement)modifier les PTR dans pour "d" dans la zone c.b.a.in-addr.arpa, qui doit être sous le contrôle de ton hébergeur.

Ceci dit:

- on peut donc déduire tes adresses IP à partir des in-addr.arpa cités ci-dessous :-)

- la config DNS forward et reverse est en fait presque bonne, mais les glue records sont inversés par rapport à ceux que tu as dans ta base (ns1->ip1,ns2->ip2)

- ton ns2 (d'après ta zone, ns1 d'après les glue records) ne répond pas aux requêtes DNS et c'est probablement pour cette raison-là que tu as eu une erreur en fait.

Deux bons outils pour vérifier les choses:

- http://www.squish.net/dnscheck/ permet de faire une vérification complète de la racine DNS jusqu'aux enregistrements A que tout fonctionne correctement et est cohérent (mais il semblerait avoir manqué l'incohérence des glue records).

- dig avec l'option @ pour spécifier le serveur de noms à interroger. Par exemple:

dig NS com.

(va te donner la liste des serveurs de noms de .com)

dig NS mon-serveur.com. _AT_a.gtld-servers.net.

(a.gtld-servers.net est l'un des NS de .com)

(tu vas voir que ns1->ip1 et ns2->ip2 dans les glue records)

dig NS ns1.mon-serveur.net _AT_ip1

dig NS ns2.mon-serveur.net _AT_ip1

dig NS ns1.mon-serveur.net _AT_ip2

dig NS ns2.mon-serveur.net _AT_ip2

(tu vas voir qu'il y en a un qui ne répond pas, et l'autre qui répond mais renvoie des résultats différents des glue records).

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Merci de ta réponse. Je ne suis pas sûr d'avoir bien compris comment utiliser l'outil...dig

J'ai refait le test NS il y a une heure...et il semble bon, cette fois. A n'y rien comprendre.

Si je te donne les IP et noms de domaine réels, peux tu effectuer le test pour moi ?

D'avance je t'en remercie.

Renaud.

Lien vers le commentaire
Partager sur d’autres sites

Comme déjà expliqué, à partir des adresses in-addr.arpa citées, je connais tes IPs, et à partir de là ton nom de domaine. C'est pour ça que je peux te dire que:

- l'un de tes deux NS ne répond pas (celui dont l'IP commence par 87).

- les glue records (les adresses des NS qui sont dans la zone .com) sont inversés par rapport à ceux que tu as dans ta zone

Comme tu as un NS sur deux qui répond, suivant celui sur lequel tu tombes, ça peut marcher, ou pas. En gros tu as une chance sur deux.

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Alors...

la config DNS forward et reverse est en fait presque bonne, mais les glue records sont inversés par rapport à ceux que tu as dans ta base (ns1->ip1,ns2->ip2)

Chez 1 and 1 l'hébergeur, j'ai :

IP1 ==> ns2.serveur-nom

IP2 ==> ns1-serveur-nom

Et sur le dédié :

ns1.serveur-nom ==> IP2

ns2.serveur-nom ==> IP1

Il faudrait que j'inverse ? chez 1 and 1 ou sur le serveur ?

Lien vers le commentaire
Partager sur d’autres sites

Il y a 3 endroits où il y a un mapping:

- dans la configuration du domaine (ton-serveur.com), chez Network Solutions a priori, où tu précises les NS associés, et leurs adresses IP, puisque les NS sont "dans" le domaine qu'ils servent (tu peux voir tout ça dans le whois pour ton domaine)

- dans la zone pour ton-serveur.com sur ton NS primaire

- dans les zones de reverse (via 1&1)

Les 2 derniers (ceux que tu cites) sont "d'accord", le premier ne l'est pas. Change ce que tu veux, débrouille-toi juste pour qu'ils soient tous d'accord.

Note au passage qu'il y a aussi un "glue record" supplémentaire pour ton-serveur.com tout court, avec une autre adresse IP. Il n'a pas l'air d'être utilisé, mais il est visible dans le whois, c'est un peu bizarre, et ça risque de te faire des mauvaises surprises un jour ou un autre.

Et l'un de tes deux NS (celui en 87.*) ne répond toujours pas aux requêtes DNS...

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Hummm,

Effectivement, le 3ème cas de figure auquel je n'avais pas pensé, c'est le registrar : Amen, en l'occurrence.

Et chez eux, c'est déclaré comme suit :

DNS 1 : ns1.serveur-nom.com

DNS 2 : ns2.serveur-nom.com

Ce qui l'inverse des 2 autres (1 and 1 et le serveur privé).

Donc il faudrait que j'échange aussi chez Amen de sorte que les 3 soient configurés idem ?

Lien vers le commentaire
Partager sur d’autres sites

Le problème c'est pas tellement leur "ordre" que les IPs associées. Soit tu permutes chez eux, soit tu permutes chez 1&1 et dans ta zone.

Et je me répète un peu, mais ton plus gros problème c'est quand même surtout que l'un de tes deux NS ne répond pas...

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Encore une fois je te remercie de ton aide.

Et l'un de tes deux NS (celui en 87.*) ne répond toujours pas aux requêtes DNS...

Bon. Donc c'est ce que j'ai testé hier et qui, comme tu le disais, sort en succes "un coup sur deux".

C'est donc l'IP principale du privé.

Ce qui, selon toi, serait indépendant des ns1 et ns2 configurées chez Amen, 1 and 1 et sur le serveur. (je vais donc aller chez Amen pour modifier et configurer comme les 2 autres).

Mais ce DNS qui ne répond pas...comment faire ?

Est ce en rapport avec le nom de la machine (chez 1 and 1 : sxxxx789.onlinehome-server.info) et qui est donné, sur Plesk, comme

"Nom d'hôte complet" ? Faut-il accorder quelque chose avec ça ?

Mes excuses pour ma naïveté et mon inculture en la matière. Je débute. Merci encore.

Lien vers le commentaire
Partager sur d’autres sites

Je pense que c'est surtout que named n'est pas lancé sur le serveur en question...

Ce qui me fait un peu peur c'est que si j'en crois ton nom de domaine tu veux te lancer dans un métier que tu n'as pas l'air de vraiment maîtriser, je me trompe?

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Non, je te rassure : malgré ce nom de domaine, je n'ai pas du tout l'intention de faire de l'hébergement !

Effectivement, je ne maîtrise pas du tout...et je ne suis pas fou. Il y a des centaines de pros qui font ça très bien.

C'est seulement nos sites qui sont sur ce serveur. Depuis 1 an.

Je pense que je me suis fait "avoir" par 1 and 1 car leur offre de dédié ne prévoit aucune aide.

Et depuis quelques temps nous sommes blacklistés car des spammeurs utilisent le privé pour envoyer des saloperies.

Alors j'ai arrêté Postfix et je tente de résoudre ce problème. Mais c'est galère.

Tu dis que le DNS de l'IP principale qui ne répond pas correspond à named qui n'est pas lancé sur le serveur...

Ca veut dire que le bind ne fonctionne pas ? Que le fichier named.conf est mal configuré ?

Où puis-je regarder, vérifier, tester ?

Je suis un peu paumé, je l'avoue.

Lien vers le commentaire
Partager sur d’autres sites

Ah ben c'est un peu le principe d'un serveur dédié: il est à toi, tu fais ce que tu veux dessus, mais tu te débrouilles tout seul, c'est partout pareil. Et gérer ses zones DNS soi-même quand on n'est pas à l'aise avec tout ça, ce n'est pas forcément une idée extraordinaire. Quel est l'intérêt pour toi? Les outils de gestion de zone de ton registrar ne suffisent pas?

named c'est le nom du processus de bind.

Je n'ai jamais utilisé plesk donc je ne sais pas ce qu'on peut faire avec ou pas, et j'ai l'impression que ssh c'est pas ton truc. Ca risque d'être un peu chaud... L'idée c'est de voir si en théorie il est lancé ou pas (si ça se trouve il est lancé, mais il y a autre chose qui bloque genre une règle de firewall, par exemple). S'il n'est pas lancé, il faut essayer de la lancer, et voir si ça résoud le problème. S'il ne se lance pas, il faut voir les messages d'erreur qu'il donne (dans /var/log/messages a priori, ou directement quand il est lancé, suivant l'erreur).

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

oui le serveur bind est bien lancé : sur plesk, on le voit.

je sais utiliser la console shell : si tu as des commandes à me donner pour tester, pas de problème.

Et encore merci.

Lien vers le commentaire
Partager sur d’autres sites

Ben s'il est lancé soit il y a un truc très bizarre dans la config, soit tu as un firewall ou autre filtre qui empêche d'y accéder.

En ssh, tape:

dig ns1.ton-serveur.com. _AT_127.0.01

et:

dig ns1.ton-serveur.com. _AT_son.adresse.ip

Et vois s'il répond (correctement). S'il répond correctement dans le deux cas, c'est un problème de filtre/firewall. S'il ne répond pas, il faudrait voir le fichier named.conf.

Au fait, si tu penses que Postfix n'est pas lancé sur tes serveurs j'ai une mauvaise nouvelle pour toi :-)

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Alors :

dig ns1.ton-serveur.com. _AT_127.0.01

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ns1.jld-hebergement.com. _AT_

127.0.01

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59679

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;ns1.jld-hebergement.com. IN A

;; ANSWER SECTION:

ns1.jld-hebergement.com. 169939 IN A 87.106.217.160

;; Query time: 1 msec

;; SERVER: 87.106.187.251#53(87.106.187.251)

;; WHEN: Sat Mar 6 14:11:38 2010

;; MSG SIZE rcvd: 57

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 568

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;_AT_127.0.01. IN A

;; AUTHORITY SECTION:

. 86400 IN SOA a.root-servers.net. nstld.verisi

gn-grs.com. 2010030600 1800 900 604800 86400

;; Query time: 5 msec

;; SERVER: 87.106.187.251#53(87.106.187.251)

;; WHEN: Sat Mar 6 14:11:38 2010

;; MSG SIZE rcvd: 105

et dig ns1.jld-hebergement.com. _AT_87.106.217.160

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ns1.jld-hebergement.com. _AT_87.106.217.160

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17332

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;ns1.jld-hebergement.com. IN A

;; ANSWER SECTION:

ns1.jld-hebergement.com. 169678 IN A 87.106.217.160

;; Query time: 1 msec

;; SERVER: 87.106.187.251#53(87.106.187.251)

;; WHEN: Sat Mar 6 14:15:58 2010

;; MSG SIZE rcvd: 57

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53981

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;_AT_87.106.217.160. IN A

;; AUTHORITY SECTION:

. 86400 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2010030601 1800 900 604800 86400

;; Query time: 17 msec

;; SERVER: 87.106.187.251#53(87.106.187.251)

;; WHEN: Sat Mar 6 14:15:58 2010

;; MSG SIZE rcvd: 111

Mais comme j'ai modif chez Amen pour que ça soit idem 1 and 1 et le dédié,c'est à dire inversé, j'ai testé aussi :

dig ns1.jld-hebergement.com. _AT_213.165.94.152 :

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ns1.jld-hebergement.com. _AT_213.165.94.152

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57328

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;ns1.jld-hebergement.com. IN A

;; ANSWER SECTION:

ns1.jld-hebergement.com. 169496 IN A 87.106.217.160

;; Query time: 1 msec

;; SERVER: 87.106.187.251#53(87.106.187.251)

;; WHEN: Sat Mar 6 14:19:00 2010

;; MSG SIZE rcvd: 57

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35379

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;_AT_213.165.94.152. IN A

;; AUTHORITY SECTION:

. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010030600 1800 900 604800 86400

;; Query time: 5 msec

;; SERVER: 87.106.187.251#53(87.106.187.251)

;; WHEN: Sat Mar 6 14:19:00 2010

;; MSG SIZE rcvd: 111

En espérant que ce charabia te parle ;-)

Lien vers le commentaire
Partager sur d’autres sites

Ca veut dire que named est bien lancé et répond bien, donc que tu as un filtre/firewall quelque part qui bloque. Il faut lui dire de laisser passer les requêtes DNS (UDP et TCP port 53), comme sur l'autre serveur.

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Voici la config du firewall de PLesk

Interface d'administration de Plesk Autoriser entrant de all

serveur WWW Autoriser entrant de all

Serveur FTP Autoriser entrant de all

Serveur SSH Autoriser entrant de all

SMTP (submission port) server Autoriser entrant de 87.106.217.160

Interdire entrant de tous les autres

Serveur SMTP Autoriser entrant de all

Serveur POP3 Autoriser entrant de all

serveur IMAP Autoriser entrant de all

service de changement de mot de passe du mail Autoriser entrant de all

Serveur MySQL Autoriser entrant de all

Serveur PostgreSQL Interdire entrant de tout

Interface d'administration de Tomcat Interdire entrant de tout

Samba (file sharing in Windows networks) Interdire entrant de tout

VPN Plesk Interdire entrant de tout

Serveur de nom de domaine Autoriser entrant de all

service de Ping Interdire entrant de tout

Politique système pour le trafic entrant Interdire tout autre trafic entrant

Politique système pour le trafic sortant Autoriser tout autre trafic sortant

Politique système pour les transferts (trafic) Interdire transfert de tout autre trafic

Mais je ne vois pas DNS. Il faut que je crée une nouvelle règle ?

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Bonjour,

Je me permets de faire un point ce matin car le reverse test échoue toujours.

http://ipadmin.junkemailfilter.com/rdns.php?ip=87.106.217.160

Et pire : hier le test pour l'IP 2 répondait success, maintenant il est en échec aussi.

Mais une chose étonnante lors du test :

Looking up Reverse DNS for IP Address: [87.106.217.160]

RDNS for 87.106.217.160 is: [ns2.jld-hebergement.com] - (PTR record - 160.217.106.87.in-addr.arpa)

ERROR - Lookup Failed for [ns2.jld-hebergement.com]

ERROR - Reverse Lookup Failed

IP [87.106.217.160] does not match []

On voit : PTR record 160.217.106.87.in-addr-arpa

et si je fais un lookup sur cette IP :elle appartient à un type d'une université de République Tchèque !

Quelle est cette folie ?

- J'ai crée une nouvelle règle firewall : Autoriser entrant de tout sur les ports 53/tcp, 53/udp.

- Chez Amen registrar : Dns primaire NS2.JLD-HEBERGEMENT.COM - Dns secondaire NS1.JLD-HEBERGEMENT.COM (mais est-ce propagé ?)

- Chez 1 and 1 hébergeur : ip1 => ns2 et ip2 => ns1

- Sur zone IP serveur : ns1 => ip2 et ns1 => ip1

Donc on peut dire que c'est "inversé" sur les 3 zones.

Le nom de la machine est resté celui attribué par 1 and 1 : sxxxxx.onlinehome-server.info

Ne faut-il pas le changer ? l'associer à jld-hebergement qui est serveur de noms ?

Voici la config de la zone DNS du serveur de noms (est elle en conformité ?)

213.165.94.152 / 24 PTR jld-hebergement.com.

87.106.217.160 / 24 PTR jld-hebergement.com.

ftp.jld-hebergement.com. CNAME jld-hebergement.com.

jld-hebergement.com. NS ns1.jld-hebergement.com.

jld-hebergement.com. NS ns2.jld-hebergement.com.

jld-hebergement.com. A 87.106.217.160

jld-hebergement.com. MX (10) mail.jld-hebergement.com.

mail.jld-hebergement.com. A 87.106.217.160

ns1.jld-hebergement.com. A 213.165.94.152

ns2.jld-hebergement.com. A 87.106.217.160

webmail.jld-hebergement.com. A 87.106.217.160

www.jld-hebergement.com. CNAME jld-hebergement.com.

Merci d'avance et bonne journée.

Modifié par renaud63
Lien vers le commentaire
Partager sur d’autres sites

Le problème est que le NS sur 87.* est toujours inaccessible. Tu as bien mis ta règle qui autorise les requêtes DNS avant celles qui interdisent "tout le reste"?

Encore une fois, dans le PTR, l'adresse IP est inversée (a.b.c.d devient d.c.b.a.in-addr.arpa), et les PTRs dans ta zone ne servent à rien.

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

voici ce qu'affiche le firewall :

Nom Description Commande

Nouvelle règle personnalisée Autoriser entrant de tout sur les ports 53/tcp, 53/udp

Interface d'administration de Plesk Autoriser entrant de all

serveur WWW Autoriser entrant de all

Serveur FTP Autoriser entrant de all

Serveur SSH (shell sécurisé) Autoriser entrant de all

SMTP (submission port) server Autoriser entrant de 87.106.217.160

Interdire entrant de tous les autres

Serveur SMTP (envoi de mail) Autoriser entrant de all

Serveur POP3 (récupération de mail) Autoriser entrant de all

serveur IMAP (récupération de mail) Autoriser entrant de all

service de changement de mot de passe du mail Autoriser entrant de all

Serveur MySQL Autoriser entrant de all

Serveur PostgreSQL Interdire entrant de tout

Interface d'administration de Tomcat Interdire entrant de tout

Samba (file sharing in Windows networks) Interdire entrant de tout

VPN Plesk Interdire entrant de tout

Serveur de nom de domaine Autoriser entrant de all

service de Ping Autoriser entrant de all

Politique système pour le trafic entrant Interdire tout autre trafic entrant

Politique système pour le trafic sortant Autoriser tout autre trafic sortant

Politique système pour les transferts (trafic) Interdire transfert de tout autre trafic

et d'après ça la règle pour le 53 est en 1er.

Et dans shell, si je fais : netstat -natup | grep 53

J'obtiens :

tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 25392/couriertcpd

tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 25382/couriertcpd

tcp 0 0 87.106.217.160:80 38.99.97.53:51115 SYN_RECV -

tcp 0 0 213.165.94.152:53 0.0.0.0:* LISTEN 20881/named

tcp 0 0 87.106.217.160:53 0.0.0.0:* LISTEN 20881/named

tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 20881/named

tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 20881/named

tcp 1 0 87.106.217.160:51053 212.227.116.10:80 CLOSE_WAIT 3894/udevd

tcp 1 0 87.106.217.160:43253 93.184.221.133:80 CLOSE_WAIT 3894/udevd

tcp 0 0 ::ffff:87.106.217.160:22 ::ffff:109.210.237.45:58959 ESTABLISHED 15332/sshd: root_AT_no

tcp 0 0 ::ffff:87.106.217.160:80 ::ffff:38.99.97.53:30394 TIME_WAIT -

udp 0 0 0.0.0.0:53 0.0.0.0:* 20881/named

udp 0 0 213.165.94.152:53 0.0.0.0:* 20881/named

udp 0 0 87.106.217.160:53 0.0.0.0:* 20881/named

udp 0 0 127.0.0.1:53 0.0.0.0:* 20881/named

udp 0 0 0.0.0.0:5353 0.0.0.0:* 22329/avahi-daemon:

udp 0 0 :::5353 :::* 22329/avahi-daemon:

Modifié par renaud63
Lien vers le commentaire
Partager sur d’autres sites

Il n'y a pas quelque chose à faire genre "appliquer les règles"? Parce que là c'est sûr, ça ne passe toujours pas. Il n'y a pas de filtrage au niveau de 1&1? Essaie aussi en comparant les règles sur les deux serveurs: il y en a sur lequel ça marche, il faut donc faire pareil sur l'autre :-)

Jacques.

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Euh...quand tu dis "sur les deux serveurs"...

tu parles de 1 and 1 et de mon privé ?

Oui je vois sur 1 and 1 qu'un parefeu est activé sur l'IP 1.

Je modif.

Modifié par renaud63
Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Super !

Je te remercie beaucoup, vraiment.

Avant de clore ce sujet, j'aurais quelques questions à te poser :

- Pour que les tests fonctionnent, j'ai désactivé le pare-feu de 1 and 1 mais laissé celui de PLesk avec ces deux règles :

* Autoriser entrant de tout sur les ports 53/tcp, 53/udp

* Autoriser sortir vers tout sur les ports 53/tcp, 53/udp

n'est ce pas dangereux de laisser ça ?

- Par ailleurs, j'ai l'impression que mon serveur a été hacké et qu'il sert pour envoyer des spams. Car j'ai trouvé ce genre de "undelivered" dans

la file attente des messages :

Received: by s15303100.onlinehome-server.info (Postfix)

id 87EAD2407619D; Sun, 7 Mar 2010 09:46:25 -0500 (EST)

Date: Sun, 7 Mar 2010 09:46:25 -0500 (EST)

From: MAILER-DAEMON_AT_s15303100.onlinehome-server.info (Mail Delivery System)

Subject: Undelivered Mail Returned to Sender

To: caroline26141_AT_yahoo.com

Auto-Submitted: auto-replied

MIME-Version: 1.0

Comment en être sûr ? quels tests faire ?

J'ai installé Clamav et mises à jour par cron + fail2ban pour les attaques "brute force" ftp + chrootkit.

clamav scanne le dossier www et ne trouve rien. Faut il faire un scan complet ?

Comment savoir si une "bête" est tapie quelque part ?

Si un des domaines est vérolé, comment savoir lequel ?

Quels logs scruter ?

Merci encore pour tes précieux conseils.

Renaud.

Modifié par renaud63
Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...