Mettre en place un serveur DNS slave (avec AS différent)

Support Debian
#5

Merci pour ce retour et ton service a l’air d’être exactement ce que je cherchais.

Petite question subsidiaire : J’ai donc corrigé 2 ou 3 trucs dans ma conf DNS, et mon reverse déconne. Dans un sens, ça me parait assez logique. Lorsque je fais un dig -x monip j’obtiens ceci :

root@mail:/etc/bind/zones# dig -x 88.121.250.140

; <<>> DiG 9.10.3-P4-Debian <<>> -x 88.121.250.140
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16851
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;140.250.121.88.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
140.250.121.88.in-addr.arpa. 21599 IN    PTR     4fc70-1-88-121-250-140.fbx.proxad.net.

;; Query time: 217 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 29 11:23:50 CEST 2018
;; MSG SIZE  rcvd: 105

Ce qui me gêne, c’est cette ligne :

140.250.121.88.in-addr.arpa. 21599 IN    PTR     4fc70-1-88-121-250-140.fbx.proxad.net.

Sachant que je suis derrière une freebox, si je veux avoir à la place un enregistrement juste, il faut que dans l’interface de ma freebox, je déclare un nom de domaine, précisément celui que je veux héberger, pour que le reverse soit juste (pour que l’ip de ma freebox corresponde) ? Pour obtenir :

140.250.121.88.in-addr.arpa. 21599 IN    PTR     www.mondomaine.com.

(l’ip a été changé par souci de confidentialité)

#6

Quel est le problème ?

J’oubliais : les registrars fournissent fréquemment un service de DNS secondaire pour les domaines enregistrés chez eux. Si le domaine est enregistré chz OVH, je serais surpris qu’OVH ne fournisse pas ce service.

#7

Eh bien, il faut que je puisse utiliser mon serveur pour gérer l’envoi et la réception des mails. J’ai donc un postfix qui tourne, mais lorsque j’essaye d’envoyer des mails, ceux-ci passent en deffered :

May 29 15:05:28 test postfix/smtpd[27296]: connect from localhost[127.0.0.1]
May 29 15:05:28 test postfix/smtpd[27296]: 190451C0BAF: client=localhost[127.0.0.1]
May 29 15:05:28 test postfix/cleanup[27299]: 190451C0BAF: message-id=20180529130528.190451C0BAF@test.mondomaine.ovh
May 29 15:05:28 test postfix/qmgr[17731]: 190451C0BAF: from=webadmin@mondomaine.ovh, size=478, nrcpt=1 (queue active)
May 29 15:05:28 test postfix/smtpd[27296]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
May 29 15:05:28 test postfix/smtp[27300]: connect to mail.mondomaine.ovh[88.121.250.140]:25: Connection refused
May 29 15:05:28 test postfix/smtp[27300]: 190451C0BAF: to=webadmin@mondomaine.ovh, relay=none, delay=0.15, delays=0.12/0.03/0/0, dsn=4.4.1, status=deferred (connect to mail.mondomaine.ovh[88.121.250.140]:25: Connection refused)
May 29 15:09:05 test postfix/qmgr[17731]: 205711C0BA4: from=webadmin@mondomaine.ovh, size=478, nrcpt=1 (queue active)
May 29 15:09:35 test postfix/smtp[27305]: connect to mail.mondomaine-de-prod.ovh[164.132.50.45]:25: Connection timed out
May 29 15:09:35 test postfix/smtp[27305]: 205711C0BA4: to=webadmin@mondomaine-de-prod.ovh, relay=none, delay=502, delays=472/0.05/30/0, dsn=4.4.1, status=deferred (connect to mail.mondomaine-de-prod.ovh[164.132.150.5]:25: Connection timed out)

J’ai essayé d’envoyer un mail depuis l’adresse webadmin@mondomaine.ovh vers webadmin@mondomaine-de-prod.ovh.

Je pense que le problème vient du reverse qui n’est pas correct, non ?

#8

Je ne vois rien qui me laisse penser que le reverse DNS est en cause.
Les échecs sont au niveau de l’établissement des connexions TCP, un refus pour la première et un time-out pour la seconde. Dans mon expérience, un rejet à cause du reverse DNS a lieu au niveau du dialogue SMTP lorsque la connexion TCP est établie et le MTA peut vérifier le reverse. Pour que la connexion soit rejetée au niveau TCP il faudrait que ce soit un pare-feu situé en amont du MTA qui fasse la vérification DNS. Pas impossible mais ça me paraît lourd.

Par contre certains serveurs de mail refusent les connexions directes depuis les adresses IP d’abonnés des FAI “résidentiels”, les forçant à passer par les relais SMTP de leur FAI. Il me semble aussi que par défaut la Freebox interdit ces connexions directes sur le port 25. As-tu modifié ce réglage ?

Un détail me surprend : ton postfix essaie d’abord de se connecter à l’adresse IP de ta box, comme si celle-ci était déclarée comme MX du domaine de production destinataire. Le refus peut venir de l’absence de redirection du port 25 sur la box.

#9

Pour les rejets au niveau SMTP, je pense avoir compris : je n’utilise que du 25, pas de chiffrage, je suis vraiment au ras des pâquerettes au niveau sécurité, je pense que les serveurs distants refusent simplement mes mails à cause de ça (me concernant, pour la prod, c’est comme ça que ça marche en tout cas) ?
Pour preuve, j’arrive à envoyer des mails vers des adresses Free, mais pas vers les adresses Gmail.

Je voulais déjà valider le fonctionnement de l’ensemble sur le port 25, pour l’envoi avant d’avancer plus loin en mettant en place du SSL.

Aurais-tu un protocole de test efficace que je pourrais effectuer, pour vérifier point par point là où ça pêche, depuis le serveur DNS jusqu’à la conf mail ? J’ai essayé plusieurs choses côté mail, y compris une séquence telnet sur le port 25, mais tout a l’air bon de ce côté :

root@test:/usr/share/nginx/html/postfixadmin# telnet localhost 25
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
220 test.mondomaine.ovh ESMTP Postfix (Debian/GNU)
ehlo localhost
250-test.mondomaine.ovh
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8

#10

Chiffrement.

Le MTA distant n’accepte même pas la connexion TCP, il ne peut pas encore savoir si tu vas utiliser TLS ou pas. De nos jours on utilise toujours le port 25 et on passe ensuite en TLS explicite si le client le demande. L’utilisation du port 465 pour du SMTP avec SSL implicite est dépréciée.

D’autre part, je ne vois pas pourquoi un MX refuserait les connexions entrantes non chiffrées. Si le MTA expéditeur estime que le mail ne nécessite pas de chiffrement, ça ne regarde que lui. Le seul cas où un serveur SMTP pourrait exiger le chiffrement est celui d’un relais (smarthost) avec authentification afin de protéger la transmission du mot de passe, pas d’un MX.

Preuve de quoi ?
Free autorise peut-être les connexions directes à ses propres MX depuis les adresses IP de ses abonnés.

Non, rien de bien rigoureux.
Requête DNS pour les enregistrements MX du domaine destinataire.
Test de connexion aux MX avec telnet sur le port 25.

ehlo xxxx
mail from: <xx@xx>
rcpt to: <yy@yy>
rset
quit

Note que si tu ne veux pas t’embêter avec tout ça, il suffit de définir le relais SMTP de Free en smarthost dans la configuration de postfix.

#11

Non non, je veux tout comprendre. Je veux savoir gérer intégralement l’ensemble des services de mon domaine, et pas passer par un tiers.
Il faut vraiment que tout soit clean, en vue d’une migration de la prod pour quand je serai prêt (la deadline n’est pas un problème, puisque je suis décideur pour le coup).

Là j’ai récupéré une conf que je n’avais pas mis en place moi même, je me dois de pouvoir la reproduire et l’améliorer (dans la mesure du possible) pour le futur.

Je vais reprendre tout ce que j’ai fait, point par point, en suivant ce tuto. Il faut que tout soit en SSL, avec du rainloop, dovecot, de l’antispam/antivirus, sous nginx, avec le support de php5.6 et 7.0. Du boulot :slight_smile:

Je m’y remets.

#12

En générale le port 587 est recommandé assez souvent pour palier à ce type de blocage.

#13

Pas le même usage.

Le port 587 est utilisé uniquement avec le protocole Submission (sous-ensemble du protocole SMTP) pour la communication entre un MUA (client mail) et un MTA relais, pas avec le protocole SMTP pour la communication entre MTA dont il est question ici.

Si tu veux causer à un MX, c’est avec le port 25.

#14

Oui effectivement :confused: toute mes confuses.

#15

Mhh bon, j’avance, voilà où j’en suis :

  • J’émets et je reçois de monadresse@mondomaine.ovh <=> monadresse@mondomaine-de-prod.ovh
  • J’émets et je reçois de monadresse@mondomaine.ovh <=> monadresse@free.fr
  • J’émets depuis monadresse@gmail.com => monadresse@mondomaine.ovh
  • Impossible d’émettre en revanche de monadresse@mondomaine.ovh => gmail, orange.fr, etc… sauf free.fr

Voici un petit extrait de la log :

May 29 22:23:26 test postfix/submission/smtpd[4467]: connect from unknown[192.168.1.254]
May 29 22:23:26 test postfix/submission/smtpd[4467]: Anonymous TLS connection established from unknown[192.168.1.254]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May 29 22:23:26 test postfix/submission/smtpd[4467]: E8FF81C0D00: client=unknown[192.168.1.254], sasl_method=PLAIN, sasl_username=webadmin@mondomaine.ovh
May 29 22:23:26 test postfix/cleanup[4446]: E8FF81C0D00: message-id=eea472ab-24de-343a-be8d-54ef85f9f2bc@mondomaine.ovh
May 29 22:23:27 test postfix/qmgr[4306]: E8FF81C0D00: from=webadmin@mondomaine.ovh, size=783, nrcpt=1 (queue active)
May 29 22:23:27 test postfix/submission/smtpd[4467]: disconnect from unknown[192.168.1.254] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
May 29 22:23:27 test postfix/error[4469]: E8FF81C0D00: to=monadresse@gmail.com, relay=none, delay=0.11, delays=0.07/0/0/0.03, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to alt4.gmail-smtp-in.l.google.com[74.125.195.27]:25: Connection timed out)
May 29 22:23:27 test dovecot: imap(webadmin@mondomaine.ovh): Connection closed in=763 out=1572

Ce qui m’ennuie/inquiète, c’est que je n’arrive pas à établir de connexion au port 25 à ces différents serveurs distants… Serais-je banni ? Y-a-t-il une autre explication ?

Tout ceci ne me dit rien qui vaille :

traceroute to alt4.gmail-smtp-in.l.google.com (74.125.195.26), 30 hops max, 60 byte packets
1 192.168.1.254 0.496 ms 0.623 ms 0.597 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Au passage, le copain mxtoolbox me répond ceci :

Connecting to 88.121.250.114

220 mail.mondomaine.ovh ESMTP Postfix (Debian/GNU) [969 ms]
EHLO EC2AMAZ-14J9QQI.mxtoolbox.com
250-mail.mondomaine.ovh
250-PIPELINING
250-SIZE 502400000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN [706 ms]
MAIL FROM:supertool@mxtoolbox.com
250 2.1.0 Ok [750 ms]
RCPT TO:test@mxtoolboxsmtpdiag.com
454 4.7.1 test@mxtoolboxsmtpdiag.com: Relay access denied [766 ms]

LookupServerv2 4536ms

SMTP Banner Check Reverse DNS does not match SMTP Banner More Info
SMTP Reverse DNS Mismatch OK - 88.121.250.140 resolves to 4fc70-1-88-121-250-114.fbx.proxad.net
SMTP Valid Hostname OK - Reverse DNS is a valid Hostname
SMTP TLS OK - Supports TLS.
SMTP Connection Time 1.094 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.
SMTP Transaction Time 3.409 seconds - Good on Transaction Time

Reverse DNS does not match SMTP Banner

Alors désolé d’insister avec cette histoire de reversedns, mais ça ne viendrait pas de là mon problème ? Mon ip, au lieu de résoudre mail.mondomaine.ovh, elle renvoie 4fc70-1-88-121-250-114.fbx.proxad.net.
Du coup, les postfix distants auxquels je cherche à me connecter, ne seraient-ils pas méfiants quant au fait que l’ip ne renvoie pas le domaine attendu ?

Une fois ce problème réglé j’attaque DKIM/SPIF histoire de présenter bien :slight_smile:

#16

Avec quelle commande traceroute complète ?

Pourquoi devrait-elle résoudre mail.mondomaine.ovh ?
Au stade où la connexion échoue, le dialogue SMTP n’a pas encore commencé et ton MTA ne s’est pas encore présenté comme mail.mondomaine.ovh.

#17

Avec celle-ci : traceroute -n -T -p 25 alt4.gmail-smtp-in.l.google.com

Du coup, je commence mieux à comprendre ce que tu disais plus haut. Tu évoques comme explication le fait qu’un gros fournisseur comme Gmail, Orange ou autre refuse que l’IP d’un client “final” se connecte directement au port 25 de leur serveur ? Si c’est bien ça, comment le confirmer ? Et si oui, comment le contourner ?

#18

Si un traceroute TCP sur le port 25 ne dépasse pas la box, c’est un indice que le filtrage est dans la box. Un traceroute ICMP ou UDP ou sur un autre port doit aller un peu plus loin.

#19

Effectivement, on va un peu plus loin avec d’autres ports. Mais j’ai déjà mis du PAT en TCP/UDP de l’exterieur du port 25 vers le port 25 du serveur de mon réseau, que puis-je faire d’autre ?

#20

En principe, la redirection de port ne concerne que les connexions entrantes depuis l’extérieur, pas les connexions sortantes (ou alors seulement celles à destination de l’adresse IP publique de la box).

Le filtrage du port 25 en sortie est-il bien désactivé dans les réglages de la freebox ?

#21

Bravo, c’était bien ça ! Je communique avec tout le monde maintenant. Un immense merci pour ton aide et ton temps.

#22

J’avais pourtant déjà évoqué ce point dans mon message n° 8.

Un mot sur le reverse DNS : jusqu’ici il n’était pas en cause, mais même correct (c’est-à-dire que le nom retourné par la résolution inverse de l’adresse IP pointe vers l’adresse IP) il pourrait le devenir. En effet certains MX n’aiment pas que :

  • le reverse DNS ne corresponde pas au nom annoncé dans le HELO/EHLO (ce qui est à mon avis une connerie du moment que le nom annoncé et le reverse DNS pointent tous les deux vers l’adresse IP) ;

  • le reverse DNS ait une forme “générique” comme celle attribuée par défaut par les FAI, comme le tien actuellement.

#23

Oui, effectivement tu avais évoqué ça, mais je l’avais très mal compris : Je pensais que tu évoquais un filtre au niveau de la freebox elle même (comme du PAT par exemple), je ne savais pas, à ce moment là, qu’il y a une paramétrie spécifique au SMTP en 25, directement accessible depuis l’espace abonné free.

Pour le reverse, j’en prends bonne note. D’ailleurs, on voit l’illustration de ton premier point dans le message de mail-tester.com suivant :

La recherche ou la résolution de la reverse DNS (rDNS) permet de déterminer si un nom de domaine est associé à l’adresse IP donnée.
Quelques entreprises comme AOL rejetteront tout message envoyé d’un serveur sans rDNS, vous devez vous assurer d’en avoir une.
Vous ne pouvez pas associer plus d’un nom de domaine à une adresse IP unique.
Votre adresse IP 88.121.250.140 est associée au nom de domaine 4fc70-1-88-121-250-140.fbx.proxad.net.
Néanmoins votre message semble être envoyé de mail.mondomaine.ovh.

Vous devriez modifier l’enregistrement du pointeur DNS (Type PTR) et le nom d’hôte (host name) de votre serveur avec la même valeur

Voici les valeurs testées pour cette vérification:
IP: 88.121.250.140
HELO: mail.mondomaine.ovh
rDNS: 4fc70-1-88-121-250-14.fbx.proxad.net

Dernière question et après j’arrête ce HS :

Dans le cas où je n’ai qu’une seule IP publique de dispo, puis-je héberger le mailing complet d’autres domaines ?

#24

Bien sûr. Un même serveur SMTP peut gérer plusieurs domaines.