À partir du moment qu'on gère un site avec un trafic considérable, on est confronté à la gestion de plusieurs noms de domaine. Posséder son propre serveur DNS peut apporter une solution à certains problèmes, mais attention, vous devez bien saisir son rôle et décider si oui ou non vous en avez besoin.
J'expliquerai donc d'abord le fonctionnement global des noms de domaine sur Internet, et par la suite, si vous êtes toujours des nôtres, on entamera l'installation et la configuration de Maradns.
Une erreur fréquente en informatique, c'est de se lancer tête baissée dans l'installation et la configuration d'un logiciel sans même saisir pleinement sa raison d'être et son utilité (je plaide coupable ! ^^ ). Ici, pour savoir si vous avez besoin d'un serveur DNS et pour comprendre à quoi ça sert, vous devez vous approprier un minimum de vocabulaire et comprendre le processus de résolution DNS. Continuez de lire pour voir si, à tout hasard, ne j'expliquerais pas tout ça dans les prochaines lignes. :-°
Un nom de domaine
Allons-y pour la définition très précise, de ma main : Un nom de domaine désigne, en général, une adresse Internet composée de caractères alphanumériques à laquelle on peut attribuer un sens (en la composant de mots par exemple). Un nom de domaine peut être composé de toutes les vingt-six lettres de l'alphabet latin, des chiffres de 0 à 9 et du trait d'union. Les noms de domaine sont insensibles à la casse ; chaque lettre majuscule sera considérée comme son homologue minuscule.
Certains donnent la même signification à l'expression nom de domaine qu'au terme DNS. DNS est l'acronyme de Domain Name System, c'est-à-dire un ensemble de serveurs, de réseaux et de règles rendant un ou plusieurs noms de domaine opérationnels. Certains vont donner à l'acronyme DNS la signification Domain Name Server. Ce n'est pas nécessairement une erreur, cette définition est généralement bien acceptée dans le jargon. L'expression serveur DNS, bien qu'un peu répétitive si traduite ainsi, désigne, au sens large, tout logiciel ou serveur physique répondant à des requêtes DNS. Bref, DNS est utilisé un peu n'importe comment, mais généralement on comprend qu'on réfère à quelque chose en lien avec les noms de domaine. :)
Les différents niveaux de domaine
Il existe différents niveaux de domaine, qui suivis d'un point, forment un nom de domaine :
Domaine de premier niveau (abrégé TLD) : c'est le domaine complètement à la fin du nom de domaine. Par exemple, dans le nom de domaine exemple.com., le domaine de premier niveau est com.
Domaine de second niveau (abrégé SLD) : c'est généralement le domaine que nous pouvons choisir lorsque nous enregistrons un nom de domaine. Par exemple, dans le nom de domaine news.google.com, le domaine de second niveau est google.com.)
Et ainsi de suite.. on entend très rarement le terme domaine de troisième niveau, on préférera le terme sous-domaine par convention.
Remarquez la présence d'un point chaque fois que l'on termine l'écriture d'un niveau de domaine, même pour le TLD. En effet, en théorie, chaque nom de domaine devrait se terminer par un point, dans toutes les circonstances. Cependant, toutes les applications client comprennent et acceptent l'omission de ce point. Ainsi, en théorie, on devrait visiter :
http://google.com./images
plutôt que :
http://google.com/images
Vous pouvez essayer de l'entrer dans votre navigateur, vous aboutirez à la même page, car votre navigateur, peu importe duquel il s'agit, comprendra la requête.
S'il est facultatif, pourquoi insister sur la présence de ce point à la fin ? S'il est vrai que le point terminal est facultatif dans toutes les applications client tels les navigateurs Web, il en est autrement lorsque l'on parle d'un serveur DNS. Partout dans la configuration d'un serveur DNS, lorsque nous référerons à un nom de domaine, nous devrons nous assurer de le terminer par un point, comme il se doit.
Généralement, lorsque l'on parle d'enregistrer un nom de domaine, on réfère à la réservation d'un domaine de second niveau (SLD). Dans certains cas, on réfère à l'enregistrement d'un domaine de troisième niveau. Ce peut être le cas lorsque l'association régissant l'allocation du TLD décide de le diviser en plusieurs SLD. Par exemple, le TLD ca., pour les enregistrements géographiques canadiens, peut être divisé en plusieurs SLD pour chacune de ses provinces. Ainsi, lorsque l'on veut enregistrer un nom de domaine se terminant par qc.ca., on enregistrera un domaine de troisième niveau. Certains considéreront qc.ca. comme le TLD, mais c'est une erreur, il s'agit là bel et bien du SLD.
Domaines géographiques et génériques
Les TLD peuvent être...
génériques : le TLD est ouvert à tous et considéré comme international, c'est-à-dire qu'aucun état politique n'exerce de contrôle sur sa répartition. Ces domaines sont gérés par l'ICANN (Internet Corporation for Assigned Names and Numbers).
géographiques : le TLD est géré par un organisme mandaté (généralement une société d'état) et l'enregistrement de SLD est soumis à quelques restrictions. Exemple d'organismes : CIRA (Canada) et AFNIC (France)
Afin de bien comprendre le rôle de ces organismes et la façon dont ils interviennent au quotidien lorsque nous sollicitions des noms de domaine, nous devons définir un nouveau concept : la résolution DNS.
La résolution DNS
La résolution DNS est un processus au cours duquel on désire obtenir, pour un domaine (peu importe le niveau), une adresse IP. Peu importe qu'il s'agisse du domaine test.test2.example.qc.ca. ou tout simplement de com., l'objectif de la résolution DNS est le même : obtenir une adresse IP. Pour chaque niveau de domaine, en partant du TLD (premier niveau, à droite complètement), on devra solliciter un serveur DNS pour obtenir une adresse IP. Une fois que le premier serveur est sollicité, il nous fournira les informations nécessaires pour savoir quel serveur solliciter pour résoudre le SLD, et ainsi de suite. Le problème demeure : par où commencer ? Comment savoir quel serveur solliciter pour obtenir une adresse IP pour résoudre le TLD ? La réponse est simple : les serveurs racines du DNS.
Les serveurs racines du DNS
Les serveurs racines du DNS représentent une poignée de serveurs de l'ICANN (environ une vingtaine) dont les adresses IP sont connues et fixes. L'adresse IP d'un serveur à la racine du DNS ne doit pas changer, ou alors très rarement. Ainsi, depuis plus de dix ans, ces serveurs ont conservé leur adresse IP et tous les autres serveurs DNS du monde utilisent ces adresses IP pour résoudre les domaines de premier niveau. Et voilà donc, notre problème est résolu. Avec les serveurs racines du DNS, nous connaissons l'adresse IP du serveur qui nous aidera à résoudre le TLD. Nous enverrons donc une requête DNS et le serveur DNS auquel cette adresse est attribuée nous transmettra une nouvelle adresse IP pour le TLD concerné. Si pour le TLD com. nous avons obtenu l'adresse IP a.b.c.d, nous enverrons donc une nouvelle requête à cette adresse pour résoudre le SLD (domaine de second niveau). Pour l'exemple, le SLD sera exemple.com.
Généralement, une fois que le SLD est résolu, on obtient l'adresse IP d'un serveur à interroger, mais dans un autre objectif : on veut toujours obtenir une adresse IP, mais cette fois, pas nécessairement celle d'un serveur DNS, mais plutôt celle d'une machine pour laquelle le nom de domaine sera un alias de l'IP. Autrement dit, on veut enfin récupérer l'adresse IP qui répondra aux pings du nom de domaine.
Compliqué ? Pas tant que ça. Si on résume, la résolution DNS consiste, ultimement, en l'obtention d'une adresse IP pour un nom de domaine. Pour résoudre un nom de domaine, on doit d'abord résoudre tous les domaines des niveaux qui le précèdent : si on veut résoudre un domaine de second niveau, on doit d'abord résoudre le domaine de premier niveau. Pour débuter la résolution, on sollicite les serveurs à la racine du DNS, dont l'ip ne changent pas et permet de résoudre tous les domaines de premier niveau.
En résumé, pour résoudre le nom de domaine www.exemple.com., on procède ainsi :
on demande une adresse IP aux serveurs à la racine du DNS nous permettant de résoudre com.
on sollicite cette nouvelle adresse IP pour obtenir l'adresse IP correspondant à exemple.com.
Cette explication du processus est très sommaire et ne tient pas compte d'un facteur essentiel au bon fonctionnement du DNS : la mise en cache. De nombreux serveurs DNS intermédiaires peuvent intervenir dans le processus et mettre en cache les données qu'ils ont déjà sollicitées. Ainsi, les adresses IP correspondant au nom de domaine google.com. ne font pas l'objet d'une résolution DNS complète à chaque fois que l'on visite une page sur Google. Non, car :
Votre ordinateur met en cache les adresses IP pour un temps déterminé (environ 1 heure).
Votre FAI met également en cache les adresses IP pour un temps plus long (environ 24 heures).
D'autres acteurs peuvent mettre en cache les données avant qu'elles ne parviennent à vous ou à votre FAI.
Du coup, vous venez de comprendre le processus de propagation DNS. Si l'adresse IP associée à un nom de domaine venait à changer, il ne suffit pas de vider le cache DNS de son ordinateur : cela ne servira à rien tant et aussi longtemps que votre FAI ne rafraîchira pas son cache. Pour cette raison, lorsqu'un changement est apporté à un configuration DNS, il peut prendre de 24 à 48 heures pour être connu de tous les intermédiaires entre l'utilisateur final et le serveur dont provient la modification. ;)
Serveur DNS autoritaire et serveur DNS récursif
Il existe deux types de serveurs DNS :
autoritaire : on dit du serveur autoritaire qu'il a autorité sur la zone DNS. C'est-à-dire que c'est ce serveur qui fournira, au final, toutes les adresses IP associées au nom de domaine et sous-domaines.
récursif : le serveur sert uniquement de relais entre un serveur et un autre dans le processus de résolution DNS qui se terminera lorsque le serveur autoritaire aura été contacté.
Un serveur peut agir à titre de serveur autoritaire pour certaines zones, et à titre de serveur récursif pour d'autres zones.
Nous apprendrons à configurer un serveur DNS autoritaire qui ne supporte pas la récursion. Les raisons de ce choix sont simples :
L'objectif de ce tutoriel est de vous apprendre à configurer un serveur DNS qui répondra aux besoins du commun des administrateurs systèmes. Le serveur DNS récursif sert davantage à de gros acteurs du DNS (fournisseurs d'accès Internet notamment). Notre serveur DNS aura autorité sur les zones qu'il dessert.
L'AFNIC, l'association en charge du TLD fr., ne valide pas les zones desservi par des serveurs acceptant la récursion (elle évoque des motifs de sécurité très discutables sur lesquels nous ne nous acharnerons pas :-° ).
Nous sommes maintenant prêts à commencer la configuration d'un serveur DNS. Ne continuez pas si vous n'êtes pas capable de réciter par coeur la définition de la résolution DNS, parce que si vous ne comprenez pas ça, vous n'avez aucune raison d'installer un serveur DNS, croyez-moi. :D Prétentieux ? Non, juste faites pas les mêmes erreurs que moi. :-°
On ne parle généralement que d'un seul serveur DNS sur Debian, il s'agit de Bind9. La documentation sur le net est abondante pour ce serveur très performant. Personnellement, mon choix s'est arrêté sur Maradns pour la charmante simplicité de sa configuration (qui n'en demeure pas moins très malléable !). Mais détrompez-vous si vous pensez qu'il s'agit d'un nouveau serveur encore expérimental. Au contraire, Maradns est développé et maintenu très à jour depuis 2001 et les releases sont toujours extrêmement stables.
Si vous n'êtes pas sûr de comprendre le rôle de Maradns, relisez plusieurs fois la première partie qui explique tout le processus de résolution DNS. Le Maradns que l'on va configurer sera un serveur autoritaire et non un serveur récursif, c'est-à-dire qu'il sera le dernier de tous les serveurs DNS interrogés à donner l'IP finale recherchée par tout le processus.
Installation de Maradns
Si vous êtes sous Debian, sachez que Maradns, dans sa dernière version stable, est présent sur les dépôts officiels. Par contre, pour profiter des derniers correctifs apportés, on va compiler la dernière version. C'est vraiment pas compliqué ! (J'ai inséré le lien pour télécharger la version 1.4.03, mais rendez-vous sur le http://www.maradns.org pour récupérer la dernière version).
wget http://www.maradns.org/download/1.4/1.4.03/maradns-1.4.03.tar.gz
tar -xf maradns-1.4.03.tar.gz
cd maradns-1.4.03.tar.gz
./configure
make
make install
Le fichier principal de configuration de Maradns se crée automatiquement dans /etc/maradns/mararc, et bug éternel dans l'installation du logiciel (en fait le bug ne vient pas du logiciel, mais bien du make install). Tout ce que je vous demande, c'est de déplacer le fichier dans /etc/ ainsi :
mv /etc/maradns/mararc /etc/mararc
Voilà pour l'installation. Pour lancer le serveur, il vous suffit de taper maradnsça va, tout le monde a essayé ? mais ça ne sert à rien de le faire maintenant, il n'est pas configuré. :)
Le fichier de configuration principal /etc/mararc
On n'aura que quelques lignes à modifier dans /etc/mararc.
D'abord, on définit l'adresse IP du serveur (l'adresse sur laquelle le serveur écoutera et recevra les requêtes). Si c'est un serveur sur un réseau local, vous entrez l'IP locale, sinon, l'IP sur Internet. Simplement :D Recherchez la ligne, ou créez-la si vous ne la trouvez pas :
ipv4_bind_addresses = "x.x.x.x"
Le serveur pourrait écouter sur plusieurs adresses IP, il vous suffirait de les séparer par une virgule.
Ça veut dire quoi "écouter" ? C'est simplement être attentif aux requêtes. Une machine peut être contactée de plusieurs façons, mais le serveur DNS Maradns ne recevra que les requêtes pour lesquelles la machine a été contactée par les IPs sur lesquelles il écoute. Ex : l'IP 127.0.0.1 pour la machine elle-même, une IP débutant par 192.168.x.x pour un autre ordinateur sur le réseau, et une autre IP pour identifier la machine sur Internet. Si le serveur est destiné à un réseau local mais tout de même connecté à Internet, alors il pourrait n'écouter que sur son IP locale. Il ne pourrait être contacté que par les autres ordinateurs du réseau.
Ensuite, on change la variable chroot_dir pour /etc/maradns/ : c'est le dossier dans lequel se trouveront tous nos fichiers de zone pour les noms de domaine que le serveur sert :
chroot_dir = "/etc/maradns/"
On pourrait aussi ne pas utiliser cette variable et définir un chemin absolu pour chacun de nos fichiers de zone par la suite.
Modifions maintenant un paramètre qui peut se révéler très utile. Dans des zones DNS, le * peut servir à désigner tous les sous-domaines d'un domaine (par exemple). Un joker, exactement :) Par défaut, cette option n'est pas activée. Activez-la ainsi si elle vous intéresse :
bind_star_handling = 1
Finalement, on modifie une toute dernière option extrêmement importante. Mais avant, je dois apporter quelques précisions. je vais vous résumer la vie des frères TCP et UDP. :D
Tout ça pour dire que Maradns fonctionne avec UDP et que pour qu'il accepte également les requêtes TCP, on doit utiliser un second logiciel qui est fourni avec (il a été installé en même temps que Maradns et tout, ne vous inquiétez pas ^^ ). Tout ce qu'on doit faire, c'est définir sur quelle IP ce serveur écoutera. La même que Maradns, normalement. Toujours dans /etc/mararc, modifiez les lignes (ou ajoutez si elles n'y sont pas) :
tcp_convert_server = "213.251.161.162"
Voilà, et c'est tout pour la configuration de base. On va apprendre à lancer Maradns, et même à le lancer automatiquement au démarrage. Parce que non, contrairement à d'autres logiciels, il ne s'installe pas comme un démon. :diable: (gag de smiley, on a du choix et on en profite :D )
Wikipédia définit une zone DNS comme une portion du DNS dont la responsabilité administrative a été déléguée. C'est vrai, mais ce n'est pas très parlant. Dans notre cas, une zone DNS se résume à toutes les directives (adresses IP associées aux sous-domaines, serveur mail, email de l'administrateur) que l'on veut donner pour un domaine.
Concrètement, on aura un fichier par zone DNS, donc un fichier pour chaque domaine. Simple, non ? :euh: Non ? Si j'ai trois domaines : exemple1.com, exemple2.com et exemple3.com, alors j'aurai un fichier pour chacun de ces domaines.
Ces directives que contiennent nos zones DNS sont appelées des entrées ou enregistrements. Chaque entrée correspond à une ligne dans le fichier, et chaque ligne qui s'y trouvent contient une entrée (sauf les lignes vides et les lignes de commentaires). Compliqué ? Continuez de lire et portez attention aux exemples, vous comprendrez.
Il existe plusieurs types d'entrées, je vous les énumère ici en vous donnant un exemple pour chaque. Par la suite, on pourra créer une zone DNS complète en guise d'exemple.
Enregistrement SOA (Start Of Authority)
Cet enregistrement est obligatoire au début de toutes les zones DNS. Il contient des informations qui vont notamment aider les autres serveurs DNS à faire leur mise en cache. Vous pouvez, entre autres, suggérer une fréquence de rafraîchissement. Un exemple, et on décortique ensuite :
exemple.com. SOA ns1.nameserver.com. [email protected] 2010071801 7200 3600 604800 1800
Les informations sont toutes séparées par un espace, dans l'ordre :
Le nom de domaine auquel s'applique l'enregistrement (n'oubliez pas le point à la fin) ;
Le type d'enregistrement (ici SOA) ;
Le serveur DNS principal (le premier que vous avez défini chez votre registrar) ;
L'adresse email du responsable de la zone. Évitez d'utiliser une email @exemple.com, ça peut poser des problèmes parfois étant donné que c'est cette même zone qui définira les enregistrements mails ;
La date de la dernière modification d'un seul bout : 2010-07-18-01 (01 pour le numéro de la modification dans la journée) ;
Quatre valeurs en seconde qui expriment, dans l'ordre : le nombre de secondes suggéré avant de remettre à jour la zone, avant de réessayer la requête en cas d'échec, avant que la zone soit expirée et le temps minimum entre deux requêtes.
Je le répète, cet enregistrement est obligatoire, sans lequel vos noms de domaine pourraient ne pas être résolus par certains autres serveurs. ;) Contrairement aux autres enregistrements que nous allons voir, il ne doit y avoir qu'un seul et unique enregistrement SOA par zone.
Enregistrement NS
Ces enregistrements servent à répéter quels sont les serveurs DNS pour le nom de domaine géré par la zone. Oui, à répéter pour confirmer aux autres serveurs qu'ils ont la bonne information.
exemple.com. +60 NS ns1.nameserver.com.
exemple.com. +60 NS ns2.nameserver.com.
#S'il y en avait d'autres, on les placerait à la suite
Cette fois, on a quatre informations :
Le nom de domaine que gère la zone ;
Le TTL (time to live ou durée de vie, en secondes) de l'enregistrement. Cette valeur ne peut supplanter celle du SOA. En gros, si elle est plus petite, il sera mis à jour en même temps que le reste de la zone.
Le type d'enregistrement (ici, NS) ;
Les serveurs DNS tels que définis chez votre registrar.
Enregistrement A de type IPv4
Ah ! :D Sans doute le plus concret et le plus attendu. C'est enfin cet enregistrement qui nous dira vers quelle IP pointe quel nom de domaine/sous-domaine. Parce que jusqu'ici, toutes les IPS recherchées ne nous conduisaient qu'au prochain serveur DNS. Exemple :
exemple.com. +60 A x.x.x.x
Quatre informations, dont une facultative en plus :
Le nom de domaine ou sous-domaine que concerne l'enregistrement ;
Le TTL de l'enregistrement (comme pour l'enregistrement NS) ;
Le type d'enregistrement (ici A pour IPv4, Maradns supporte l'IPv6 mais pas l'auteur du tuto :-° ), notez qu'on peut omettre d'inscrire le A étant donné que c'est le type d'enregistrement par défaut ;
L'IP associée au domaine/sous-domaine.
Si je veux assigner une IP différente pour certains sous-domaines en particulier, je procède ainsi :
dev.exemple.com. +60 x.x.x.x
J'ai omis le A, pour vous montrer que cet enregistrement est strictement équivalent à celui-ci :
dev.exemple.com. +60 A x.x.x.x
Je vous ai parlé tout à l'heure du joker (*) qui nous permettrait de donner une directive pour tous les sous-domaines d'un nom de domaine. Si par exemple, je veux que par défaut, tous les sous-domaines de exemple.com pointent vers la même IP, je procède ainsi :
*.exemple.com. +60 x.x.x.x
Bricolez vos enregistrements IPv4 comme vous l'entendez, après tout, c'est votre serveur. :D
Enregistrement CNAME
Très simple à comprendre : un enregistrement CNAME est un alias d'un hôte pour un autre. Par exemple, si je définis un alias dev2.exemple.com pour dev.exemple.com, alors toutes les directives qui concernent dev.exemple.com lui seront également appliquées. Pédagogie oblige, voici un exemple :-°
dev2.exemple.com. +60 CNAME dev.exemple.com.
Enregistrement MX
Les enregistrements MX définissent vers quels serveurs mail (MX = mail exchanger) les mails seront envoyés pour le domaine donné. Vous pouvez avoir plusieurs enregistrements pour le même domaine, et les classer par priorité. Si un serveur mail est saturé ou indisponible, on enverra au deuxième, au troisième et ainsi de suite. C'est comme ça que de gros fournisseurs d'emails fonctionnent (comme Gmail par exemple).
exemple.com. MX 10 mail.exemple.com.
Ici, les mails envoyés aux adresses @exemple.com se dirigeront vers mail.exemple.com (dont l'IP est définie par notre enregistrement de type IPv4 plus haut). Le chiffre 10 indique la priorité. Ici je n'ai qu'un seul enregistrement, donc ça ne veut pas dire grand chose. Si j'en avais eu 15, j'aurais pu les ordonner par priorité, du plus petit au plus grand.
Enregistrement TXT
C'est un enregistrement qui peut servir à ce que vous voulez. À faire un commentaire sur le domaine ou peu importe, libre à vous. On ne l'utilise que lorsque l'on en a besoin, il est facultatif.
C'est cet enregistrement qui peut servir, notamment, à appliquer des contrôles de sécurité antispam. Je vous invite à consulter le site http://www.openspf.org pour prendre connaissance de ce qu'est un enregistrement SPF et ce qu'il peut faire pour vous.
On a vu les enregistrements généralement essentiels au bon fonctionnement d'un serveur DNS. Il en existe d'autres, je vous réfère à la documentation officielle de maradns, au moins pour en prendre connaissance.
Il est possible que vous ayiez deux zones identiques pour deux domaines différents et que tout ce qui change, c'est le nom de domaine. Je vous présente donc une commodité fantastique : le symbole %, qui désigne "le domaine en cours". Si la zone est ouverte pour "exemple.com.", alors % vaudra "exemple.com." et si la zone est ouverte pour exemple2.com, alors il vaudra "exemple2.com.". Vous pourrez donc utiliser le même fichier de zone pour les deux !
Maintenant que vous avez compris l'essentiel de ce fichier, vous pouvez le créer dans /etc/maradns/. S'il ne sert qu'un domaine, vous pouvez l'inclure dans le nom du fichier (ex. : exemple.com.zone), et s'il en sert plusieurs, un nom comme serveur1.zone. Notez que l'extension .zone est le fruit de mon imagination débordante, vous pouvez lui mettre un .txt ou même aucune extension, peu importe.
Une fois que le fichier pour la zone est créé, rendez-vous dans /etc/mararc et sous csv2 = {}, ajoutez une ligne pour chaque domaine avec le fichier correspondant :
Et surtout on n'oublie pas le point à la fin du nom de domaine ! ^^
À partir de maintenant, si vous lancez votre serveur avec la commande maradns, il devrait répondre à la tâche correctement.
Oui, mais il occupe ma console quand il tourne, comment je peux le faire tourner en continu ? C'est une bonne question. On va simplement le lancer dans un screen. Si vous ne savez pas ce qu'est un screen, c'est une console virtuelle que vous pouvez laisser tourner même si la console qui l'a lancée se ferme. Si screen n'est pas installé sur votre machine, faites-le avec apt-get install screen
J'ai lancé zoneserver, rappelez-vous, c'est le serveur qui permettra à maradns d'accepter les requêtes TCP.
Voilà, votre serveur tourne. Si vous voulez qu'il se lance automatiquement au démarrage, il vous suffit d'ajouter ces commandes à la séquence de boot.
Si vous avez des problèmes/questions, vous pouvez, au choix :
utiliser les commentaires de ce tuto pour discuter ;
utiliser les forums ;
utiliser la mailing list de maradns (très efficace, en anglais) : instructions ici ;
m'envoyer un message privé.
Valider une zone DNS
Comme dans tout en informatique, il y a des choses qui se font et d'autres qui... ne se font pas. :p Pour valider une zone DNS et tester sa conformité avec les standards, il existe plusieurs outils. Certains sont payants, mais je vais vous recommander zonecheck qui est gratuit et opensource. Il est utilisé notamment par l'AFNIC pour le contrôle des zones DNS régissant tous les domaines .fr. Ne l'installez pas, utilisez carrément le démo en ligne : http://www.zonecheck.fr/demo/.
Maintenant, à vous de corriger les erreurs et avertissements qu'il vous récite ! :)