Aller au contenu

Sujets conseillés

Posté (modifié)

Bonjour à tous,

J'ai passé mon petit site sur un serveur dédié ayant enfin les connaissances et les capacités.

La seule chose qui est encore assez obscure pour moi est la configuration dns sur la machine.

J'ai réussi pour ce qui est de l'accès à mon nom de domaine (et en fait sans trop de soucis), mais je ne trouve pas comment bien renseigner le champ MX et donc pouvoir ensuite configurer un petit serveur mail. J'ai testé plusieurs configurations, mais sans succès.

Bind me dit que ma zone est bien configurée mais dig ne me trouve pas de champ MX.

Je viens donc chercher de l'aide n'ayant pas pu trouver quelque chose d'acceptable sur google (surtout un bon exemple) ...

Si quelqu'un pourrait donc éclairer ma lanterne, merci :smartass:

ma zone :

$ORIGIN domaine.com. //rajouté today, ca change quelquechose ?
$TTL 604800
@ IN SOA domaine.com. root.domaine.com. (
2009082101 ; Serial
86400 ; Refresh
7200 ; Retry
1209600 ; Expire
86400 ) ; Negative Cache TTL

IN NS nommachine.ovh.net.
IN NS sdns1.ovh.net.
IN A ipmachine
mail.domaine.com. IN A ipmachine
IN MX 0 mail.domaine.com.
www IN CNAME domaine.com.
ftp IN CNAME domaine.com.

ps : est-ce le bon endroit pour demander sur le forum ?

Modifié par Noriak
Posté

Selon ce que tu affiches, cela semble bon.

Mais avec le vrai nom de domaine, on pourrait mieux voir... parce que là tu caches bien trop pour qu'on puisse t'aider :P

Posté

Tu as bien pensé à mettre à jour ton serial à chaque modif avant de dire à bind de recharger la zone? Les NS indiqués là sont bien ceux qui sont déclarés au niveau du TLD?

Comme dit Dan, ce serait plus facile pour débugger si on connaissait le domaine.

Sinon c'est pas compliqué, tu te mets à la place d'un resolver DNS, et tu descends l'arbo jusqu'à ton MX:

dig NS domaine.com. @a.gtld-servers.net.

-> te renvoie les NS

Pour chaque NS:

dig MX domaine.com. @nom-du-ns

Tu peux aussi regarder ce que ça donne avec http://www.squish.net/dnscheck/ c'est assez efficace pour détecter pas mal de problèmes.

Jacques.

Posté

A mon avis, j'ai trouvé le pb : le changement de serial ...

Sinon voici la version non censurée :

$ORIGIN xbox360france.com.
$TTL 604800
@ IN SOA xbox360france.com. root.xbox360france.com. (
2009090201 ; Serial
86400 ; Refresh
7200 ; Retry
1209600 ; Expire
86400 ) ; Negative Cache TTL

IN NS ns355413.ovh.net.
IN NS sdns1.ovh.net.
IN A 91.121.139.186
mail.xbox360france.com. IN A 91.121.139.186
IN MX 0 mail.xbox360france.com.
www IN CNAME xbox360france.com.
ftp IN CNAME xbox360france.com.

Donc maintenant je pense que j'ai plus qu'à attendre la propagation :P

Sinon la syntaxe ne doit pas être bonne pour dig MX en passant depuis un serveur specifique (le ns spécifié) et j'ai bien mis les bons ns dans la configuration de mon domaine.

Posté

Ton serveur DNS (primaire) ne répond pas. Au choix:

- named n'est pas lancé

- le port 53 est filtré

Là ça impacte la résolution pour l'ensemble de la zone y compris le A (pour 50% de ceux qui ne l'ont pas en cache).

Sinon j'avais loupé le problème initial sur le MX, c'est un classique: quand tu ne mets pas de nom au début de la ligne, ça veut dire "même nom que la ligne précédente" (ça permet de simplifier l'écriture pour le cas où on a plusieurs A pour une même adresse, par exemple). Donc là ton MX s'applique à mail.xbox360france.com. Pour qu'il s'applique à xbox360france.com, déplace la ligne au dessus (avec les NS et le A), ou mets un @ en début de ligne (ou "xbox360franc.com.") .

Jacques.

Posté

Merci pour la configuration du mx cela doit venir de là.

Sinon il y a quelquechose que je suis pas ...

Mon serveur est lancé et le port 53 est bien disponible :


aya:/etc/bind# netstat -plunt
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
...
tcp 0 0 10.0.0.1:53 0.0.0.0:* LISTEN 3679/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 3679/named
...
Doe:~ noriak$ telnet 91.121.139.186 53
Trying 91.121.139.186...
Connected to ns355413.ovh.net.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

J'ai bien grâce à dig le serial de ma configuration précédente (2009082101) même si c'est le dns secondaire qui répond et qui donne la bonne configuration (prise du primaire donc)

root_AT_ns355413:~# dig soa xbox360france.com

; <<>> DiG 9.3.4 <<>> soa xbox360france.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47751
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;xbox360france.com. IN SOA

;; ANSWER SECTION:
xbox360france.com. 493727 IN SOA xbox360france.com. root.xbox360france.com. 2009082101 86400 7200 1209600 86400

;; AUTHORITY SECTION:
xbox360france.com. 493727 IN NS sdns1.ovh.net.
xbox360france.com. 493727 IN NS ns355413.ovh.net.

;; ADDITIONAL SECTION:
sdns1.ovh.net. 30773 IN A 213.251.188.140
ns355413.ovh.net. 71802 IN A 91.121.139.186

;; Query time: 1 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Sep 2 15:23:52 2009
;; MSG SIZE rcvd: 158

En faisant un dig mx, j'ai le serial de ma dernière configuration, ce matin (2009090201) :

root_AT_ns355413:~# dig mx xbox360france.com

; <<>> DiG 9.3.4 <<>> mx xbox360france.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44848
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;xbox360france.com. IN MX

;; AUTHORITY SECTION:
xbox360france.com. 7008 IN SOA xbox360france.com. root.xbox360france.com. 2009090201 86400 7200 1209600 86400

;; Query time: 0 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Sep 2 15:25:48 2009
;; MSG SIZE rcvd: 76

Donc il doit être accessible mais ce n'est pas lui qui répond et squish ne le trouve pas (et je vois pas une seule requête passant par le port 53 lors du test).

Il y a un truc qui m'échappe ...

Posté

La plupart des requêtes DNS se font sur le port UDP 53. Il n'y a que les transferts de zone et certains resolves qui utilisent TCP.

Et même pour TCP, les lignes que tu donnes disent qu'il écoute sur 10.0.0.1 et 127.0.0.1 seulement, donc à moins que tu n'aies du NAT quelque part qui renvoie ton adresse IP publique vers l'une de ces deux adresses, il ne répondra pas aux requêtes externes.

Pour tester, c'est toujours une bonne idée que de le faire depuis une autre machine, et en précisant avec @ le serveur que tu interroges avec dig.

Jacques.

Posté

A, mais quel c**

Oui, j'ai du nat et j'avais redirigé que le port 53 en tcp vers le serveur 10.0.0.1 ...

Bizarrement, j'ai redirigé l'udp aussi et paf ça a marché ...

J'ai refait des tests avec squish et tout a l'air de bien fonctionner (il me trouve mon MX !!!).

Merci ;)

Veuillez vous connecter pour commenter

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



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