Flaz's Hotline

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Configuration du reverse DNS ipV6 chez OVH ======

Le cas d'usage testé dans cette fiche est celui d'un serveur dédié OVH (octobre 2016).
OVH offre une connectivité IPv6 à ses serveur dédiés, même les plus basiques (kimsufi).
===== Besoin =====
Le système ayant été installé et configuré pour exploiter cette connectivité IPv6, les logiciels serveurs installés sur ce host vont automatiquement se configurer pour fonctionner en IPv6. C'est notamment le cas du serveur [[https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol|SMPT]] ([[http://www.postfix.org/|Postfix]]) avec pour conséquence, circonstance "aggravante", que l'accès via IPv6 au service proposé sera souvent privilégié((Au détriment du même service s'il est également accessible via IPv4.)).

Dès l'instant où nous mettons en place un service disponible via IPv6, nous avons tout intérêt à avoir une configuration DNS irréprochable, tout comme en IPv4. Il en va de la réputation numérique du service. C'est particulièrement important pour un serveur SMTP, en raison du fonctionnement chaîné de l'acheminement du mail et du fléau que constitue le pourriel. C'était déjà le cas en IPv4, cela deviendra la norme en IPv6.

Gmail a ouvert le bal en refusant de livrer tout courriel expédié par un serveur SMTP ne disposant pas d'une configuration DNS IPv6 complète mais il y tout lieu de penser que cela va se généraliser bien au-delà des GAFAM. L'incomplétude la plus fréquente est l'absence de reverse DNS pour l'adresse IPv6 du serveur((Il peut y avoir des raisons plus basiques, mais on sort du cadre de cette fiche.)).

Cette incomplétude se caractérise par la présence d'enregistrements [[https://en.wikipedia.org/wiki/IPv6_address#Domain_Name_System|AAAA]] et [[https://fr.wikipedia.org/wiki/Domain_Name_System#MX_record|MX]] (Ipv6) pour le host hébergeant le serveur. Pour que la configuration soit cohérente, on part du principe que le serveur SMTP est configuré pour reconnaître et autoriser les IP et ports correspondants.

Exemple de message renvoyé par les serveurs de Gmail :
<code>
gmail-smtp-in.l.google.com #<gmail-smtp-in.l.google.com #5.7.1 smtp; 550-5.7.1 [9876:5432:10fe:dcba::] Our system has detected that this message does 550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information. z2si23226952wjl.141 - gsmtp> #SMTP#
</code>

===== Problématique =====
Le serveur est un dédié fourni par OVH. L'interface d'administration d'OVH permet la configuration directe du reverse IPv4 mais pas IPv6.

OVH propose la délégation du reverse IPv6. Cette délégation cohabite avec la gestion directe du reverse IPv4 par OVH : pas de souci pour la configuration reverse déjà en place.

Il faut donc :
  - disposer d'un serveur DNS sur lequel on pourra
    - déclarer une zone IPv6
    - la configurer correctement pour qu'elle gère le reverse
  - indiquer, via l'interface OVH, qu'il faut déléguer le reverse (et lui seul) à ce serveur.

===== Configuration de la zone =====
==== Contexte et pré-requis ====
Avant de configurer le reverse IPv6, il faut s'assurer que le //hostname// est défini((S'il n'est pas défini, il suffit d'ajouter une déclaration (AAAA record) dans la zone compétente pour le hostname, c'est-à-dire là ou est déclaré l'enregistrement IPv4 (A record) pour le host.)) en IPv6 :
<code>dig host.domain.tld AAAA</code>
On suppose qu'on dispose déjà d'un serveur DNS que l'on contrôle. Dans le cas étudié, il s'agit du serveur qui contrôle le nom de domaine du host, mais ça peut être n'importe quel serveur DNS((Le reverse n'opère pas dans le même espace de nommage !)). Pour ce qu'on lui demande ici, ce serveur n'a pas besoin d'autoriser la récursion((Le serveur ne répond qu'aux requêtes DNS des zones qu'il gère. Souvent, il autorise la récursion pour les requêtes locales mais c'est hors sujet pour le propos de cette fiche.)).

Dans le configuration de démonstration présentée ici, le même host héberge à la fois les seveurs SMTP et DNS Ce serveur est équipé de l'outil d'administration [[http://www.webmin.com/|Webmin]] et utilise [[https://www.isc.org/downloads/bind/|Bind]] comme serveur DSN. Je vais donc décrire la configuration du DNS via cet outil. Le fichier de zone est le même si on configure "à la main".

==== Réalisation ====

Il s'agit de créer une zone maîtresse dans laquelle sera déclaré un enregistrement [[https://fr.wikipedia.org/wiki/Domain_Name_System#PTR_record|PTR]] (reverse). L'IPv6((Adresse IPv6 unicast globale. Dans cette configuration de démonstration, on déclare tout le sous-réseau correspondant à la topologie privée.)) que l'on veut déclarer est :
<code>ip -6 addr | grep global</code>
  * soit : 9876:5432:10fe:dcba::/64
//L'adresse peut avoir une forme différente, telle que "9876:5432:10fe:dcba::1/128".//

Créer une zone : 
  * Webmin > Servers > BIND DNS Server
  * Create master zone > Zone type > Reverse (Adresses to Names)

Éditer la zone :
  * Reverse Address

Sauvegarder :
  * check records,
  * return to zone list,
  * Check Bind Config,
  * ¡¡ lire la réponse et s'assurer que tout est OK avant de passez à l'étape suivante !!
  * Apply Configuration

=== Résultat ===
Voilà l'allure du fichier de zone généré par Webmin :
<code>
$ttl 38400
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa.	IN	SOA	host.domain.tld. user.mail-domain.tld. (
			2016102701
			10800
			3600
			604800
			38400 )
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa.	IN	NS	host.domain.tld.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa.	IN	PTR	host.domain.tld.
</code>
On relève que webmin a automatiquement déclaré host.domain.tld., le hostname de votre serveur DNS, comme NS pour l'IP, dans le domaine //ip6.arpa// et qu'il fait autorité.

=== Test local au serveur DNS ===
On commence par tester la réponse du serveur DNS en local, c'est-à-dire à une requête issue du système sur lequel il tourne (on suppose ici que le système utilise __son__ serveur DNS comme resolver DNS…).
<code>
dig -x 9876:5432:10fe:dcba::

;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. IN PTR

;; ANSWER SECTION:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. 38400 IN PTR host.domain.tld.

;; AUTHORITY SECTION:
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. 38400 IN NS host.domain.tld.
</code>

On a testé la bonne configuration de la zone et sa prise en compte par le serveur DNS mais encore faut-il que le serveur réponde correctement à une demande émanant d'internet. De plus, les récursion sont généralement autorisées en local et interdite depuis internet.
=== Test depuis internet ===
On peut utiliser n'importe quel poste de travail. On force à utiliser notre serveur DNS pour résoudre le reverse.
<code>
dig -x 9876:5432:10fe:dcba:: @host.domain.tld

;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. IN PTR

;; ANSWER SECTION:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. 38400 IN PTR host.domain.tld.

;; AUTHORITY SECTION:
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. 38400 IN NS host.domain.tld.
</code>
Si tout s'est bien passé, on a obtenu la même réponse ;-). Pas de récursion et //host.domain.tld// fait bien autorité.

===== Délégation du reverse =====

Sur la console d'administration d'OVH : Dédié > host.domain.tld
  - Cliquer sur la roue dentée, juste à droite du nom du serveur, en haut de page, accolée aux IP (v4 et v6)
  - Via la roue dentée située au niveau de l'IPv6, choisir déléguer le reverse et indiquer //host.domain.tld// (ben oui !)

==== Test Final ====
Il faut attendre que la propagation ait été faite côté //arpa// (c-à-d dans l'espace de nom du reverse...).

Test effectué après 24h, depuis un poste de travail, en laissant le DNS trouver le bon serveur :
<code>
dig -x 9876:5432:10fe:dcba:: ANY

;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. IN PTR

;; ANSWER SECTION:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. 38400 IN PTR host.domain.tld.

;; AUTHORITY SECTION:
a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.ip6.arpa. 38400 IN NS host.domain.tld.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
</code>
La dernière ligne indique que le poste de travail a utilisé son propre serveur DNS pour résoudre le reverse. Dans l'exemple, il s'agit d'un serveur //Bind// configuré en //résolveur// local. Cela nous préserve des [[free:dns|aberrations que peut produire le serveur DNS du FAI]].
==== Test optionnel ====
Si vous voulez être totalement rassurée quant à la configuration DNS pour le service SMTP, effectuez un contrôle via [[https://www.zonemaster.fr/|ZoneMaster]] sur une zone pour laquelle votre serveur de courrier traite du courrier (on suppose que le domaine est configuré pour IPv6).

Dans la configuration de démonstration, on utilise le fait que le serveur SMTP traite son propre courrier pour tester la zone //domain.tld//.
==== Test réel ====
Enfin, rien ne vaut un test réel d'envoi de courriel depuis votre serveur SMTP.
=== Pré-validation ===
L'outil en ligne [[https://www.mail-tester.com/|mail tester]] permet d'obtenir un compte-rendu d'analyse de réception de mails que vous adressez à l'outil.

Depuis votre station d'administration((La station de travail depuis laquelle vous administrer à distance votre serveur.)), faites pointer un navigateur sur [[https://www.mail-tester.com/|mail tester]], une adresse de courriel vous est proposée (xxxxxxx@mail-tester.com)

Dans un terminal ouvert sur le serveur(en supposant que vous l'avez équipé d'une interface/client mail en ligne de commande)
<code>
mail xxxxxxx@mail-tester.com
subject : Test ipv6
Coucou.
.
EOF
</code>

Depuis votre station vérifiez votre score et obtenez l'analyse de réception. Dans la configuration proposée ici, vous devriez obtenir 9/10((Le point manquant provient du fait que DKIM n'a pas été configuré.)).

=== Validation via Gmail ===
Il reste à envoyer un courriel à une adresse existante de Gmail pour vous assurer que Gmail accepte désormais vos messages.

Depuis le serveur (en supposant que vous l'avez équipé d'une interface/client mail en ligne de commande) :
<code>
mail une_adresse@gmail.com
subject : Test ipv6
Coucou.
.
EOF
</code>
//Si le "." isolé sur la ligne n'est pas interprété par le logiciel comme une fin de message, "EOF" ne sera pas affiché et la commande ne sera pas terminée (affichage du prompt). Dans ce cas, on termine la saisie du corps du message par <Ctrl + D>.//

Dans les journaux système du serveur (par ex. //syslog//, pour une configuration standard) voyez si le courriel a été livré. Sinon vous aurez une réponse immédiate de Gmail qui se traduira par un //bounce// (rebond).
<code>
cat /var/log/syslog | grep une_adresse@gmail.com
</code>
Au milieu du //blabla//, vous devriez trouver :
<code>
blabla…   relay=gmail-smtp-in.l.google.com[2a00:1450:400b:c00::1a]:25, delay=1, delays=0.23/0/0.41/0.38, dsn=2.0.0, status=sent blabla
</code>
La phrase magique est "**status=sent**". Sinon, lisez attentivement les messages affichés…
===== Configuration anti-spam spf1 =====
==== Principe ====
Source : [[http://antone.geckotribe.com/alpha-gecko/how-to-set-up-spf-records/|How to set up SPF records]] (en).

La configuration d'une zone décrivant un serveur MX (smpt) possède très probablement une déclaration conforme à la norme "Sender Policy Framework" ([[https://fr.wikipedia.org/wiki/Sender_Policy_Framework|SPF]]). Elle indique les serveurs autorisés à expédier du mail pour le(s) nom(s) de domaine(s) concerné(s). En effet ce type de déclaration est aujourd'hui exigé par un nombre croissant de [[https://en.wikipedia.org/wiki/Message_transfer_agent|MTA]] et, plus encore, de [[https://fr.wikipedia.org/wiki/Mail_Delivery_Agent|MDA]]. Techniquement, une déclaration SPF se fait à l'aide d'un enregistrement de type TXT.
==== Réalisation ====
Afin de compléter la configuration du reverse, il est de plus en plus important((Le niveau d'exigence ne cesse de croître.)) d'ajouter l'ipv6 du serveur smtp à la déclaration SPF (ou de la déclarer, ainsi que l'ipv4). Dans le cas d'un ajout, on il suffira d'insérer la chaîne de caractères "ip6:<my IPv6> (sans "v"). En reprenant l'une des ipv6 imaginées précédemment, l'enregistrement aura la forme suivante :
<code><myDomainName>	IN	TXT	"v=spf1 … ip6:9876:5432:10fe:dcba::1 …</code>

Avec l'outil d'administration Webmin, un tel enregistrement est construit à travers un formulaire : Servers > Bind DNS Server > <zone name> > Sender Permitted From.

Dans tous les cas, il est impératif de s'assurer de la conformité du fichier de zone avant de l'appliquer ! Une fois la conformité a priori effectuée, il est conseillé de la tester à travers des outils de validation dynamique qui vont directement interroger le DNS, par exemple : [[http://www.kitterman.com/spf/validate.html|SPF Record Testing Tools]].
==== Domaines concernés ====
Alors que la configuration du reverse ne concerne que le //host// hébergeant le serveur smpt, la déclaration SPF doit être appliquée à tous les noms de domaines pour lesquels l'envoi de mail est autorisé depuis ce serveur. En toute logique, ces déclarations ne peuvent pas se faire dans le fichier de zone du serveur smtp.

Si ce //host// émet du mail sous son propre nom ((Par exemple, des mails d'administration envoyés par des utilisateurs système de ce //host//.)) , il faudra bien sûr lui adjoindre la déclaration SPF adéquate.

Le nombre de zones concernées peut être important. Si l'on utilise un outil d'administration de serveurs virtuels mutualisés (tel Virtualmin), il sera judicieux d'intégrer cette déclaration "SPF ipv6" au modèle de génération des configurations des serveurs virtuels.
==== Annexe ====
Le reverse et la déclaration SPF sont deux solides pré-requis pour s'assurer que le mail envoyé depuis un serveur indépendant sera acheminé à bon port. Les contrôles indiqués ci-après sont un bon complément, sachant qu'il faudra parfois contacter directement certains services et opérateurs pour qu'ils laissent passer votre courrier…

  * Votre [[http://www.spamhaus.org/lookup.lasso|serveur n'est pas blacklisté]]
  * Votre [[http://www.mxtoolbox.com/|zone est correctement définie]] pour le mail
  * Vous avez [[http://antone.geckotribe.com/alpha-gecko/how-to-set-up-spf-records/|fait les déclarations SPF requises]]
  * Le [[http://unixwiz.net/techtips/postfix-HELO.html|serveur de mail s'annonce bien avec le hostname]] du serveur qui l'héberge
  * Le [[http://www.spamhelp.org/shopenrelay/|serveur n'est pas un relais ouvert]] de messagerie((Une usine à spam.))
  * Le [[http://www.simpledns.com/help/v51/index.html?df_ttl.htm|TTL du MX n'est pas éxagérément bas]]((24h - 86400 secondes est un délais raisonnable.)), ceux des spammeurs sont souvent bas
  * Votre [[http://postmaster.aol.com/guidelines/standards.html|serveur respecte les exigences technique d'AOL]]((Elle recoupent beaucoup de celles indiquées ci-avant. L'avantage d'AOL est qu'il est très exigent et qu'il indique comment vérifier, pas à pas, que l'on respecte ses exigences.)).
===== Réponse du serveur DNS sur son ipV6 =====
Source : [[http://mirrors.deepspace6.net/Linux+IPv6-HOWTO/hints-daemons-bind.html|Berkeley Internet Name Domain (BIND) daemon “named” : Listening on IPv6 addresses]]
==== Problématique ====
La pression au passage en ipV6 s'exerce sur le DNS lui-même, en tant que service. Si un //host// muni d'une ipV6 déclarée dans le DNS héberge un serveur DNS, le DNS tentera de l'interroger sur son ipV6. L'absence de réponse sur l'ipV6 sera considérée comme un mauvais fonctionnement((Plus généralement, l'existence d'un enregistrement AAAA pour un //host// est interprétée comme un engagement de la par du //host// à fournir les services qu'il rend via IPv6. Par exemple, //Let's Encrypt// ne pourra pas utiliser la vérification par requête http si un enregistrement AAAA existe, même si le service https fourni en IPv4. En présence d'un enregistrement de type AAAA, l'absence de service en IPv6 est considérée comme une rupture de contrat.)). Tant que le serveur répond sur son ipV4, la zone ne disparaîtra pas du DNS mais la réputation du //host//, des services qu'il rend et de la zone((Potentiellement de tout le nom de domaine.)) en sera entachée.
==== Diagnostic ====
Pour des raisons de sécurité, la configuration par défaut d'un serveur DNS ne prévoit pas l'activation du service sur les IP publiques((En général, le serveur sera en écoute sur les ip locales (ipV4 et ipV6) et autorisera même la récursion pour ces ip.)). La commande suivante, exécutée sur le host hébergeant le serveur DNS concerné, vous indiquera sur quelles ip est rendu le service DNS:
<code>
# netstat -lnptu |grep "named\W*$"
</code>
l'absence d'une ligne affichant l'ipV6 du //host// **et** le mot-clé "LISTEN" indique que le serveur DNS de ce host n'est pas configuré pour répondre sur son ipV6.
==== Configuration du serveur BIND ====
Dans notre cas, le service DNS étant rendu par BIND, nous illustrons par la configuration de ce serveur.

L'écoute sur l'ipV6 se fait à l'aide d'une déclaration "listen-on-V6". Par défaut, cette déclaration sera souvent présente mais ne mentionnera que l'ip locale :
<code>
listen-on-v6 {::1;};
</code>
Il suffit d'ajouter l'ipV6 publique en respectant la syntaxe intuitive de la déclaration. Avec l'outil Webmin, on accédera au bon fichier de configuration par le chemin suivant :

Webmin > Servers > BIND DNS Server > Edit Config File > named.conf.options

Une fois éditée, la déclaration "listen-on-v6" aura la forme suivante :
<code>
	listen-on-v6 {
		::1;
		9876:5432:10fe:dcba::1;
		};
</code>

Ne pas oublier d'enregistrer et d'appliquer la modification.

Sur certains système, la configuration post-installation peut déjà contenir une déclaration englobante, couvrant toutes les interfaces connues :
<code>
        listen-on-v6 { any; };
</code>

==== Vérification ====
On commence par s'assurer, en local, que le serveur DNS écoute sur l'ipV6 publique :
<code>
# netstat -lnptu |grep "named\W*$"
…
tcp6       0      0 9876:5432:10fe:dcba::1:53  :::*                    LISTEN      17003/named
…
</code>
Ici, on constate que BIND écoute, en TCP((Il pourrait également le faire en UDP, mais c'est une autre histoire.)), sur l'adresse publique ipV6, sans restriction sur l'origine ipV6 des requêtes.

Le service web [[https://www.zonemaster.fr/|ZoneMaster]] permet de s'assurer que le service est vu de l'extérieur. Pour ce faire, on peut utiliser n'importe quel nom de domaine pour lequel le //host// a été déclaré en tant que NS (pas nécessairement le nom de domaine dont dérive le hostname !).