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).

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 SMPT (Postfix) avec pour conséquence, circonstance “aggravante”, que l'accès via IPv6 au service proposé sera souvent privilégié¹⁾.

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²⁾.

Cette incomplétude se caractérise par la présence d'enregistrements AAAA et 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 :

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#

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 :

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

Avant de configurer le reverse IPv6, il faut s'assurer que le hostname est défini³⁾ en IPv6 :

dig host.domain.tld AAAA

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⁴⁾. Pour ce qu'on lui demande ici, ce serveur n'a pas besoin d'autoriser la récursion⁵⁾.

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 Webmin et utilise 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”.

Il s'agit de créer une zone maîtresse dans laquelle sera déclaré un enregistrement PTR (reverse). L'IPv6⁶⁾ que l'on veut déclarer est :

ip -6 addr | grep global

• 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

Voilà l'allure du fichier de zone généré par Webmin :

$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.

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é.

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…).

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.

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.

On peut utiliser n'importe quel poste de travail. On force à utiliser notre serveur DNS pour résoudre le reverse.

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.

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é.

Sur la console d'administration d'OVH : Dédié > host.domain.tld

1. Cliquer sur la roue dentée, juste à droite du nom du serveur, en haut de page, accolée aux IP (v4 et v6)
2. 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 !)

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 :

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)

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 aberrations que peut produire le serveur DNS du FAI.

Si vous voulez être totalement rassurée quant à la configuration DNS pour le service SMTP, effectuez un contrôle via 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.

Enfin, rien ne vaut un test réel d'envoi de courriel depuis votre serveur SMTP.

L'outil en ligne 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⁷⁾, faites pointer un navigateur sur 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)

mail xxxxxxx@mail-tester.com
subject : Test ipv6
Coucou.
.
EOF

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⁸⁾.

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) :

mail une_adresse@gmail.com
subject : Test ipv6
Coucou.
.
EOF

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).

cat /var/log/syslog | grep une_adresse@gmail.com

Au milieu du blabla, vous devriez trouver :

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

La phrase magique est “status=sent”. Sinon, lisez attentivement les messages affichés…

Source : 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” (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 MTA et, plus encore, de MDA. Techniquement, une déclaration SPF se fait à l'aide d'un enregistrement de type TXT.

Afin de compléter la configuration du reverse, il est de plus en plus important⁹⁾ 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 :

<myDomainName>	IN	TXT	"v=spf1 … ip6:9876:5432:10fe:dcba::1 …

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 : SPF Record Testing Tools.

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 ¹⁰⁾ , 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.

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 serveur n'est pas blacklisté
• Votre zone est correctement définie pour le mail
• Vous avez fait les déclarations SPF requises
• Le serveur de mail s'annonce bien avec le hostname du serveur qui l'héberge
• Le serveur n'est pas un relais ouvert de messagerie¹¹⁾
• Le TTL du MX n'est pas éxagérément bas¹²⁾, ceux des spammeurs sont souvent bas
• Votre serveur respecte les exigences technique d'AOL¹³⁾.

Source : Berkeley Internet Name Domain (BIND) daemon “named” : Listening on IPv6 addresses

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¹⁴⁾. 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¹⁵⁾ en sera entachée.

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¹⁶⁾. 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:

# netstat -lnptu |grep "named\W*$"

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.

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 :

listen-on-v6 {::1;};

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 :

	listen-on-v6 {
		::1;
		9876:5432:10fe:dcba::1;
		};

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 :

        listen-on-v6 { any; };

On commence par s'assurer, en local, que le serveur DNS écoute sur l'ipV6 publique :

# netstat -lnptu |grep "named\W*$"
…
tcp6       0      0 9876:5432:10fe:dcba::1:53  :::*                    LISTEN      17003/named
…

Ici, on constate que BIND écoute, en TCP¹⁷⁾, sur l'adresse publique ipV6, sans restriction sur l'origine ipV6 des requêtes.

Le service web 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 !).