Après avoir vu comment sécuriser son serveur avec Iptables et Fail2ban, nous allons nous attaquer à une étape qui demande de la patience, beaucoup de patience. Il s’agit de la configuration des DNS sur une adresse IP Failover et de son Reverse IP.
Vous avez l’impression que je parle chinois ? Alors voici quelques explications :
Les serveurs DNS sont des serveurs capables de gérer un ou plusieurs niveaux de domaines. Ce sont eux qui indiquent à votre navigateur sur quel serveur (ou plutôt sur quelle adresse IP) se trouve le site web que vous voulez consulter. C’est pourquoi lorsque vous commandez un nouveau nom de domaine, vous devez indiquer au moins deux serveurs DNS configurés correctement afin que ceux-ci puissent rediriger les visiteurs de votre site web vers le bon serveur. Et pourquoi deux me direz-vous ? Tout simplement pour palier à une éventuelle panne de l’un d’entre eux. Pour celles et ceux qui aimeraient plus d’information sur ce sujet, le site OpenClassrooms fourni une explication claire et détaillée.
Le problème avec les serveurs DNS, c’est qu’ils ne sont pas mis à jour en permanence, mais seulement à intervalles plus ou moins régulières, c’est pourquoi il faut compter entre 10 minutes et 48 heures pour la propagation des DNS et pour que votre serveur puisse être atteint via son nom de domaine.
IP Failover
Venons-en maintenant à l’IP Failover. Tout serveur dédié se voit attribuer une adresse IP fixe, laquelle vous permets de vous connecter directement dessus, mais que se passerait-il si notre serveur devenait trop faible et que nous devions en prendre un plus performant ? Nous devrions tout configurer avec la nouvelle adresse IP du nouveau serveur et attendre à nouveau quelques heures voire quelques jours que la propagation des DNS se fasse, ce qui risquerait de provoquer des problèmes d’accès à tous nos sites web, et ce ne serait pas professionnel du tout ! C’est là qu’intervient l’IP Failover.
Une IP Failover est une adresse IP fixe supplémentaire que nous pouvons attribuer à n’importe lequel de nos serveurs (chez un même hébergeur). Nous pouvons même en avoir plusieurs pour un seul et même serveur, ainsi si votre serveur commence à atteindre ses limites, vous pouvez en commander un nouveau, vous y connecter via son adresse IP fixe, le configurer entièrement, copier les données de votre premier serveur puis, via le manager de votre hébergeur, rediriger l’IP Failover sur le nouveau serveur, et toutes les requêtes seront directement transmises au nouveau serveur, sans avoir à changer quoi que ce soit auprès de notre Registrar (l’organisme qui gère les noms de domaines) ni dans le serveur DNS.
Reverse IP
Et le Reverse IP alors, qu’est-ce que c’est ? Et bien tout simplement, il s’agit de faire l’inverse de ce que fait normalement un serveur DNS. Rappelez-vous, lorsque vous demandez à un serveur DNS où se trouve le site monsiteweb.com, celui-ci va vous donner en retour l’adresse IP du serveur où se trouve le site en question. Le Reverse IP permet tout simplement de connaître le nom du serveur correspondant à une adresse IP donnée. Mais un exemple sera sans doute plus clair :
Quand vous essayez de vous connecter à un site web, votre navigateur va demander à ses serveurs DNS quelle est ou quelles sont les adresses IP du serveur. On peut faire la même chose en ligne de commande dans un terminal Linux :
$ nslookup cybernaute.ch
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: cybernaute.ch
Address: 80.74.157.22
Nous voyons ainsi que l’adresse IP du serveur où se trouve mon site est 80.74.157.22, et si nous effectuons l’opération inverse :
$ nslookup 80.74.157.22
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
22.157.74.80.in-addr.arpa name = sinope.kreativmedia.ch.
Authoritative answers can be found from:
Comme vous le voyez, une recherche sur l’adresse IP de mon site web nous redirige vers sinope.kreativmedia.ch, soit le nom du serveur qui héberge ce site. Cette fonction est souvent utilisée par les serveurs de mail pour vérifier que le serveur qui veut envoyer le mail est bien un serveur et non pas un ordinateur personnel piraté qui essaie d’envoyer du spam. Aussi, si vous ne voulez pas que tous les mails que vous envoyez depuis votre serveur soient directement marqués comme spam, configurez bien votre Reverse IP.
Bien, maintenant que la théorie est posée, passons à la pratique.
Configuration des DNS
Le programme qui gère les DNS sur un serveur Linux s’appelle Bind9. Pour l’installer il suffit de saisir la commande suivante en étant connecté en root :
[root@serveur:~] apt-get install bind9
La configuration des DNS se passe dans le dossier /etc/bind/. Les fichiers que nous allons modifier sont named.conf.local dans lequel nous allons enregistrer chacun des sites web que nous hébergeons, named.conf.options dans lequel nous configurerons les options nécessaires à la communication avec le serveur DNS secondaire, et nous allons aussi créer un fichier de type db.mondomaine.com pour chaque domaine et qui contiendra la configuration personnalisée du domaine concerné.
named.conf.local
Dans ce fichier nous allons enregistrer une zone pour chacun de nos domaines comme suit :
zone "mondomaine.com" {
type master;
file "/etc/bind/db.mondomaine.com";
allow-transfer {213.186.33.199; };
};
Dans la zone, indiquez votre nom de domaine entre guillemets, sans le www. Le type master indique que nous sommes en train de configurer le serveur DNS primaire. La ligne file « /etc/bind/db.mondomaine.com »; indique où se situe le fichier de configuration de ce domaine, et la directive allow-transfer indique l’adresse IP du serveur DNS secondaire (dans ce cas,il s’agit de l’adresse IP de ns.kimsufi.com) afin que celui-ci soit autorisé à récupérer les informations de notre serveur DNS.
db.mondomaine.com
Il s’agit ici du fichier indiqué précédemment dans la zone de notre domaine. C’est le fichier le plus important, car c’est ici que nous indiquons l’adresse IP de serveur hébergeant notre domaine.
$TTL 3H
@ IN SOA ns.mondomaine.com. postmaster.mondomaine.com. (
2015082701 ; serial, todays date + todays serial
8H ; refresh
2H ; retry
1W ; expire
1D ) ; minimum ;
@ 10800 IN NS ns.mondomaine.com.
@ 10800 IN NS ns.kimsufi.com.
@ 10800 IN A 188.165.37.xx
www 10800 IN A 188.165.37.xx
ns 10800 IN A 188.165.37.xx
La valeur de $TTL donne la durée de vie en secondes de l’enregistrement dans les caches. Le caractère @ remplace le nom de notre zone (dans notre exemple, mondomaine.com, si vous préférez indiquer directement votre nom de domaine, n’oubliez pas d’ajouter un « . » à la fin). Après le SOA, nous devons indiquer notre serveur DNS primaire (ns.mondomaine.com), suivi d’une « . » puis d’une adresse e-mail valide suivie directement d’un « . ». Remarquez que le @ de l’adresse e-mail est remplacé par un point. Si votre adresse e-mail contient un « . », vous devez l’échapper avec un « \ » (par exemple : etienne\.grisel.mondomaine.com.). S’ensuit entre parenthèses les données suivantes :
serial : 2015082701 ; il s’agit d’un numéro de série composé de l’année, du mois, du jour et d’un numéro incrémenté à chaque modification (YYYYMMDD01).
refresh : 8H ; ce paramètre donne l’intervalle de temps en secondes (ou abrégé en heures ou en jour) entre deux vérifications du numéro de série (serial) par le serveur DNS. La valeur recommandée est de 24 heures (1D ou 24H ou 86400) et devra être réduite si les modifications sont fréquentes pour cette zone.
retry : 2H ; la vérification du numéro de série par un serveur secondaire peut se solder par un échec dû par exemple à des problèmes de connexion entre les deux serveurs DNS. Dans ce cas, la valeur du retry donne l’intervalle en secondes entre deux tentative de lecture du serial du fichier de zone. La valeur recommandée est 21400, soit 6 heures. Elle devra être ajustée en fonction de la connectivité entre les serveurs autoritaires de la zone.
expire : 1W ; un serveur peut ne pas réussir à vérifier le serial ou à transférer le fichier de zone. Le paramètre expire donne le temps maximum pendant lequel les données du serveur secondaire peuvent être diffusées avant d’être considérées comme périmées, si aucune vérification ni transfert de zone n’ont pu être effectuées depuis leur téléchargement. La valeur recommandée est de 3600000, soit 41 jours. Cette valeur doit être au minimum 7 fois plus importante que la valeur du refresh, sinon le registrar de votre nom de domaine risque de refuser l’inscription de notre serveur comme DNS.
minimum : 1D ; défini la durée de vie pour le negative caching, c’est-à-dire le temps qu’une réponse négative doit rester dans les caches.
Ensuite viennent les deux lignes contenant l’enregistrement NS, soit les serveurs DNS qui gèrent notre nom de domaine. Le @ reprend notre nom de zone, le chiffre suivant représente la TTL (Time To Live) spécifique à cette ligne, le IN indique que nous sommes dans une classe internet (la seule encore vraiment utilisée de nos jours), le NS indique que nous parlons des serveurs de noms (DNS) et pour finir, nous indiquons le nom du serveur DNS. N’oubliez pas d’indiquer le « . » à la fin des noms des serveurs DNS, sinon le programme croira qu’il doit encore ajouter notre zone à la fin de la ligne (ce qui nous donnerait ns.mondomaine.com.mondomaine.com et ns.kimsufi.com.mondomaine.com) et rendrait notre configuration inutilisable.
Pour finir ce fichier, nous mettons en correspondance notre adresse IP Failover et les noms de machines. Encore une fois, le @ remplace notre zone (mondomaine.com), le www indique notre sous-domaine principal (comme il n’y a pas de « . » après www, le programme l’interprète comme étant www.mondomaine.com) et le ns indique le sous-domaine correspondant à notre serveur DNS (c’est ce nom là que vous indiquerez comme premier serveur DNS à votre registrar pour les domaines que vous voudrez installer sur votre serveur). Il est évident que la ligne du sous-domaine ns ne doit être mise en place que pour votre domaine principal. Il vous faudra ajouter autant de lignes que de sous-domaine que vous voudrez pour le domaine. Si vous désirez accepter tous les sous-domaines, remplacez leur nom (par exemple www) par une astérisque « * ».
named.conf.options
Dans ce fichier, nous allons uniquement commenter deux lignes avec un double « // » et ajouter la ligne allow-transfer pour permettre au serveur secondaire d’accéder à notre serveur DNS. Modifiez le fichier pour qu’il ressemble à ça :
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
// listen-on-v6 { ::1; };
// #listen-on { 127.0.0.1; };
allow-recursion { 127.0.0.1; ::1; };
allow-recursion { 213.186.33.199; };
};
Les lignes modifiées sont mises en évidence. Bien entendu, n’oubliez pas d’indiquer l’adresse IP du serveur secondaire, qui sera très certainement différente de celle que j’ai utilisée ici.
Reverse IP
Comme indiqué précédemment, la reverse IP permet de mettre en correspondance notre adresse IP Failover (dans mon cas 188.165.37.xx) avec le nom de notre serveur (ns.mondomaine.com).
Pour commencer, nous allons reprendre notre fichier named.conf.local et nous allons y ajouter la zone suivante :
zone "37.165.188.in-addr.arpa" {
type master;
file "/etc/bind/db.mondomaine.com.rev";
};
Le nom de la zone est composé de notre adresse IP Failover inversée, sans le dernier chiffre, et suivie de .in-addr.arpa (dans mon cas, l’adresse IP 188.165.37.xx devient 37.165.188 suivie de .in-addr.arpa). Le nom du fichier utilisé est identique au précédent, sauf que nous y avons ajouté .rev pour éviter d’écraser le fichier configuré précédemment. Vous pouvez mettre n’importe quel nom de fichier, du moment que vous créez bien un fichier de ce nom contenant la configuration que nous allons voir maintenant.
/etc/bind/db.mondomaine.com.rev
Ce fichier est très semblable au précédent, mais il y a quand-même quelques petites différences à ne pas louper :
$TTL 3H
@ IN SOA ns.mondomaine.com. postmaster.mondomaine.com. (
2015083001
8H
2H
1W
1D )
@ 10800 IN NS ns.mondomaine.com.
@ 10800 IN NS ns.kimsufi.com.
xx IN PTR ns.mondomaine.com.
Les premières lignes sont identiques au fichier précédent, nous avons uniquement supprimé la correspondance entre notre zone et notre adresse IP Failover, que nous remplaçons par la dernière ligne indiquée ci-dessus. Elle commence par le dernier chiffre de notre adresse IP Failover (indiqué par xx dans mon exemple), suivi de la classe IN, du record type PTR et du nom que nous voulons donner à notre serveur. Dans mon cas, je veux qu’il m’indique la même chose que le nom de mon serveur DNS, mais nous aurions tout aussi bien pu mettre bidule.mondomaine.com. ou machin.mondomaine.com., du moment que le nom de notre domaine est indiqué et que nous n’oublions pas le « . » à la fin du nom de notre serveur.
Enfin, nous devons rajouter une interface réseau pour notre nouvelle adresse IP, sinon le serveur ne reconnaîtra pas l’IP Failover. Pour cela, nous éditons le fichier /etc/network/interfaces et nous y ajoutons les lignes suivantes :
auto eth0:0
iface eth0:0 inet static
address notre.adresse.ip.failover
netmask 255.255.255.0
broadcast notre.adresse.ip.failover
et pour finir nous redémarrons l’interface réseau :
[root@server:~] service networking restart
Nous pouvons vérifier le résultat en effectuant un ping sur notre nouvelle adresse IP Failover.
Pour terminer
Pour vérifier que notre configuration est correcte, nous pouvons utiliser la commande named-checkconf -z directement de notre serveur pour vérifier s’il n’y a pas d’erreur :
[root@server:~] named-checkconf -z
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
zone 37.165.188.in-addr.arpa/IN: loaded serial 2015083001
Si cette commande n’affiche aucune erreur, nous rechargeons BIND pour qu’il prenne en charge nos modifications et qu’il lance la propagation :
[root@server:~] service bind9 reload
Un autre utilitaire lui aussi très utile pour vérifier votre configuration est nslookup (nslookup.exe sous Windows) :
nslookup mondomaine.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: mondomaine.com
Address: 188.165.37.xx
Si vous ne voyez aucune erreur, c’est que votre configuration est correcte. Pour en avoir le cœur net, nous pouvons encore tester (sous Linux uniquement) la commande dig :
[root@server:~] dig mondomaine.com
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> mondomaine.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48555 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;mondomaine.com. IN A
;; ANSWER SECTION:
mondomaine.com. 3600 IN A 188.165.37.xx
;; AUTHORITY SECTION:
mondomaine.com. 3600 IN NS ns.mondomaine.com.
mondomaine.com. 3600 IN NS ns.kimsufi.com.
;; ADDITIONAL SECTION:
ns.mondomaine.com. 3600 IN A 188.165.37.xx
ns.kimsufi.com. 3600 IN A 213.186.33.199
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Aug 30 22:55:37 2015 ;; MSG SIZE rcvd: 109
Nous retrouvons en effet toutes les informations que nous avons enregistré précédemment.
Nous sommes presque au bout de nos efforts, mais avant que nous puissions passer à la suite, il faut encore que nous indiquions à notre serveur secondaire de venir prendre en charge notre configuration. Cela se passe dans le manager de Kumsufi, dans la rubrique DNS, option Ajouter un DNS secondaire. Dans Domaine nous indiquons le nom du domaine que nous voulons ajouter, sans le www et nous sélectionnons l’adresse IP Failover que nous avons utilisée précédemment et nous validons en cliquant sur Confirmer. Et c’est maintenant qu’il va nous falloir être patient ; en effet, il faut compter entre 10 minutes et 48 heures pour que notre configuration soit propagée sur le serveur secondaire. Pour vérifier que toute est en ordre, nous pouvons utiliser les sites Zonecheck et DNSdoctor pour tester la propagation et d’éventuelles erreurs résiduelles.
Une fois que la propagation est effective et que les sites mentionnés ci-dessus n’indiquent plus d’erreur fatale, nous pouvons enregistrer nos DNS auprès de notre registrar.
Pour finir, nous allons enregistrer notre Reverse IP dans le manager de Kimsufi, rubrique IP, section Gérer les IPs, nous allons cliquer sur la roue dentée à droite de notre IP Failover et sélectionner l’option Reverse et nous indiquons le reverse que nous venons de configurer (ns.mondomaine.com). Si tout se passe bien, vous aurez un message indiquant que tout s’est bien déroulé, sinon vous devrez patienter encore un peu que la propagation de votre configuration arrive au serveur de Kimsufi gérant les reverse IP.
Pour information, j’ai dû attendre une dizaine d’heures pour que la propagation soit effective sur le serveur secondaire (ns.kimsufi.com) et deux heures supplémentaires pour que ma demande de Reverse IP soit prise en compte, mais d’après ce que j’ai lu sur internet, cela peut prendre bien plus de temps dans certains cas. Et si après 3-4 jours vous n’y arrivez toujours pas, c’est peut-être qu’il y a quelque-chose qui cloche dans votre configuration, il ne vous restera alors plus qu’à tout revérifier 😉
Vous avez des questions ? Des remarques ? N’hésitez pas à participer via les commentaires ci-dessous.
0 commentaires