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

Support Debian
#1

Hello,

J’ai un serveur (1 ip) avec derrière un serveur Bind faisant office de DNS pour un domaine en particulier, je m’en sers pour monter une plateforme de test, plutôt que de jouer avec les domaines de prods, qui eux, sont sur des autres serveurs DNS.

Donc là je suis sur ma plateforme à moi, perso, cad une freebox, avec une IP et OVH qui renvoie les requêtes DNS du domaine de test en question vers l’ip de ma freebox. C’est bien, ça marche, mais un truc pêche : Il n’y a pas de slave du coup.

Du coup, j’aimerais, même pour du test, avoir une plateforme conforme à ce qu’attendent les tests et pouvoir mettre en place un deuxième serveur DNS, mais je ne peux pas le faire derrière ma freebox puisque je vais me retrouver derrière le même AS.

Est-ce que vous connaissez des serveurs DNS gratuits permettant de mettre en place un serveur slave ? Ou avez-vous une autre solution ?

#2

Depuis quand faut-il que les DNS ne soient pas dans le même AS ?

#3

A priori c’est une recommandation, non ? Ce n’est pas un impératif. Mais si je déclare sous OVH mes serveurs DNS NS1.mondomaine.com vers ippublic1 et NS2.mondomaine.com vers ippublic1, les outils de vérifications en ligne vont râler en disant que les 2 serveurs DNS ont une IP identique.

Et concrètement en cas d’avarie réseau de mon côté, on perd l’intégralité du service DNS.

Après, il ne s’agit que d’une plateforme de test perso, pour éviter de bricoler sur la prod. Mais j’aime bien être au plus juste avec ce qui est en production.

#4

Il ne manquerait plus que ça. Je ne vois même pas l’utilité d’une telle recommandation pour un domaine normal (je ne parle pas d’un TLD).

J’espère bien. D’ailleurs je suis étonné que l’interface d’OVH l’accepte et ne râle pas.

Si tous les services associés au domaine sont sur la même box, ça ne change pas grand-chose, ils seront injoignables de toute façon.

Dans le genre bricolage mais qui peut passer au tests, tu peux déclarer un second NS avec une adresse IPv6 du préfixe de la freebox.

Il fut un certain temps, j’utilisais les services de Xname.org pour le DNS secondaire de mes zones inverses IPv6 (native et 6to4). Mais il y a quelques années j’ai voulu faire des modifications suite à un changement d’adresse IPv4 de mon NS primaire et impossible d’appliquer la moindre modification, donc j’ai laissé tomber, me disant que de toute façon si ma connexion internet est HS la résolution des reverse DNS ne servait pas à grand-chose. J’ignore si le service existe encore, je n’y suis pas retourné depuis.

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