Dépannage des erreurs de mauvaise configuration DNS courantes

DNS (système de noms de domaine) peut ne pas être connu de la plupart des gens qui utilisent Internet, mais c’est la véritable force invisible qui fait fonctionner Internet, sans laquelle tout le monde verrait des chiffres et des IP. Tout le sens des noms de domaine existe aujourd’hui grâce au DNS.

Introduction

La manière la plus simple d’expliquer le DNS en une ligne est de mapper le nom de domaine à l’adresse IP. Je ne suis pas sûr de combien de personnes sauraient que lorsque quelqu’un tape un nom de domaine dans IE/firefox, le navigateur transmet la demande DNS demandant l’adresse IP au résolveur de l’ISP (fournisseur d’accès Internet) et le résolveur contacte les serveurs racines et récupère systématiquement l’adresse IP en quelques millisecondes.

Comprendre le DNS et son fonctionnement est l’un des sujets les plus difficiles en ingénierie informatique et pourtant, même les administrateurs réseau les plus expérimentés luttent sur ce sujet lorsqu’il s’agit d’écrire des fichiers de zone DNS.

Avant de poursuivre cet article, voici les points les plus importants que vous devez retenir, sinon vous ne comprendrez rien.

Points à retenir

Un enregistrement A doit TOUJOURS contenir une adresse IP (mapper l’hôte à l’IP)

Chaque fois que vous spécifiez un enregistrement A, il doit contenir une adresse IP sur le côté droit. L’enregistrement A est si important dans le DNS, sans quoi le sens de mapper les noms d’hôtes à l’IP serait absurde. Alors souvenez-vous de cela !

CNAME (Alias) doit contenir des noms d’hôtes. Pas d’IP ici
Les enregistrements NS et MX doivent contenir des noms d’hôtes. Pas d’IP autorisée.
Utilisez le POINT à la fin, chaque fois que vous spécifiez un nom de domaine dans le fichier de zone DNS. Ce POINT est si important et si vous l’oubliez, vous aurez des cauchemars avec votre configuration DNS.

Par exemple

example.com. IN NS ns1.example.com.

Pourquoi le POINT ? simplement parce qu’il indique de commencer la requête à partir des serveurs racines (indiqués par le point)

Les enregistrements MX (pour les serveurs de messagerie) doivent contenir des noms d’hôtes, PAS d’IP.

Termes DNS courants et leurs significations

(i) Enregistrements Glue

Les enregistrements Glue sont des enregistrements A qui sont associés aux enregistrements NS pour fournir des informations de “démarrage” aux enregistrements de serveur de noms NS. (voir RFC 1912 section 2.3)

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 11.33.55.77
ns2 IN A 22.44.66.88

Dans l’exemple ci-dessus, nous associons chaque enregistrement NS à une adresse IP (enregistrement A), liant ainsi les serveurs de noms à l’IP (c’est-à-dire les collant).

(ii) Délégation de serveur de noms LAME

Un serveur de noms qui donne une réponse non autoritaire est généralement appelé ‘LAME’. Chaque domaine doit avoir au moins 2 serveurs de noms et si je demande à chacun d’eux, et s’ils ont des informations de zone de domaine, je recevrai une réponse autoritaire. Sinon, c’est une ‘délégation lame’. Référez-vous à la RFC 1912 section 2.8.

Un exemple de délégation lame est

domain.com IN NS ns1.domain.com
domain.com IN NS ns2.example-server.net

ns1.domain.com est configuré pour avoir des informations de zone sur le domaine, mais ns2.exserver.net n’a pas été configuré correctement et n’a aucune information sur le domaine. Donc ns1 répondra de manière autoritaire alors que ns2 ne le fera pas, ce qui sera ‘lame’ jusqu’à ce qu’il soit configuré correctement.

Pour obtenir une compréhension plus approfondie, utilisons l’outil dig pour example.com.

D’abord, nous trouvons les serveurs de noms de example.com:

 dig example.com NS

;; SECTION DE RÉPONSE:
example.com. 158240 IN NS a.iana-servers.net.
example.com. 158240 IN NS b.iana-servers.net.

Puisque nous avons reçu 2 serveurs de noms, nous demandons à chacun d’eux s’ils donnent une réponse autoritaire. Si c’est autoritaire, le drapeau ‘aa’ dans l’en-tête sera défini dans la réponse reçue (‘aa’ est une réponse autoritaire).

dig @b.iana-servers.net example.com NS
dig @a.iana-servers.net example.com NS

;; A obtenu une réponse:
;; ->>EN-TÊTE<<- opcode: QUERY, status: NOERROR, id: 60896
;; drapeaux: qr aa rd; QUERY: 1, RÉPONSE: 2, AUTORITÉ: 0, ADDITIONNEL: 0

;; SECTION DE QUESTION:
;example.com. IN NS

;; SECTION DE RÉPONSE:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.

Regardez dans les drapeaux.

drapeaux: qr aa rd

Puisque ‘aa’ est défini dans la réponse, alors les deux serveurs de noms de example.com fournissent une réponse autoritaire. Si c’est une délégation lame, vous ne recevrez pas la réponse autoritaire.

ATTENTION :

Vous ne devez pas utiliser CNAME (alias) avec les enregistrements NS et cela confond souvent la plupart des résolveurs, provoquant des boucles et conduisant souvent à une ‘délégation lame’.

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net

Donc n’utilisez jamais CNAME avec les enregistrements NS.

(iii) Serveurs de noms furtifs

Les serveurs de noms furtifs (ou serveurs de noms cachés) sont des serveurs de noms incompatibles/conflit qui existent au niveau racine par rapport aux serveurs de noms dans le domaine.

Pour illustrer cela, lorsque je demande aux serveurs parents à propos de votre domaine pour les enregistrements NS au niveau racine, je reçois

ns0.domain.com
ns2.domain.com
ns3.domain.com

mais lorsque je questionne les serveurs de noms de votre domaine pour les enregistrements NS, ce ne sont pas les mêmes et viennent comme

ns0.domain.com
ns2.domain.com
ns.example-dns.net

Puisque ns.example-dns.net et ns3.domain.com sont cachés, les deux sont des ‘serveurs de noms furtifs’. Bien qu’il n’y ait rien de mal à cela, il est conseillé de ne pas avoir de serveurs de noms furtifs à la fois au niveau racine et dans votre serveur DNS.

Vous pouvez utiliser la commande dig pour rechercher les enregistrements NS au niveau du serveur racine.

 dig +trace @K.root-servers.net example.com NS

et pour demander l’un des serveurs de noms du domaine.

 dig @ns0.domain.com example.com NS

Recherchez toute incohérence NS entre les deux requêtes. S’il manque un serveur de noms au niveau racine, ajoutez le serveur de noms manquant à votre registraire de domaine. Si le serveur de noms manque au niveau du domaine, ajoutez le serveur de noms au fichier de zone du domaine et mettez à jour tous vos serveurs de noms secondaires.

(iv) Serveur DNS ouvert

Faire fonctionner le serveur DNS ‘ouvert’ est un grand risque de sécurité car il répond aux requêtes récursives à la fois de l’intérieur et de l’extérieur de votre réseau. Cela signifie que n’importe qui peut interroger votre serveur pour obtenir une adresse IP et votre serveur DNS leur répondra.

Pour illustrer cela, nous avons deux serveurs de noms exécutant bind pour le domaine example.com.

ns1.example.com
ns2.example.com

Nous demandons à ns1.example de résoudre le domaine extérieur google.com et si nous obtenons l’adresse IP (enregistrement A) dans la section de réponse, alors cela signifie que c’est un ‘serveur DNS ouvert’.

dig @ns1.example.com google.com
dig @ns2.example.com google.com

;; options globales: printcmd
;; A obtenu une réponse:
;; ->>EN-TÊTE<<- opcode: QUERY, status: SERVFAIL, id: 12107
;; drapeaux: qr rd; QUERY: 1, RÉPONSE: 0, AUTORITÉ: 0, ADDITIONNEL: 0

;; SECTION DE QUESTION:
;google.com. IN A

;; Temps de requête: 32 msec

Puisqu’il n’y a pas de section de RÉPONSE ou d’adresse IP, les deux serveurs de noms ne constituent pas un serveur DNS ouvert.

Si vous utilisez bind8 ou une version ultérieure, tout ce que vous avez à faire est de définir ‘recursion no’ dans les options pour désactiver le serveur DNS répondant aux requêtes récursives.

options {
….
recursion no;
}

(v) Transferts de zone (demande AXFR)

Les transferts de zone sont effectués par des serveurs de noms secondaires pour récupérer les dernières informations de zone mises à jour pour le domaine à partir du serveur de noms maître ou primaire. Les transferts de zone ne doivent être disponibles que pour les serveurs de noms secondaires et non pour le monde ouvert, car c’est un grand risque de sécurité et cela peut exposer les internes de votre réseau à l’attaquant.

Pour demander un transfert de zone pour example.com, nous devons d’abord demander au serveur de noms maître. Voir l’exemple ci-dessous avec dig.

 dig @ns1.example.com example.com

Si vous voyez la sortie avec le fichier de zone complet, alors vous devez désactiver le transfert de zone. Dans la plupart des cas, vous verrez connexion échouée ou REFUSÉE, ce qui signifie que le transfert de zone n’est pas autorisé et c’est une bonne chose.

Erreurs DNS courantes dans l’écriture de fichiers de zone

1. Pas de CNAME pointant vers les enregistrements NS

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net —–> FAUX

Placer CNAME avec NS entraînera l’échec de tous les serveurs de noms et résultera en une délégation lame. Ne faites pas cela !

Référez-vous à RFC1912 2.4 et RFC2181 10.3.

2. Évitez d’exécuter des serveurs DNS sur des IPs sur le même sous-réseau (/24) ou sur le même serveur.

Le but du DNS est que les serveurs de noms soient répartis sur différents emplacements géographiques afin que si un DNS échoue, l’autre fonctionne. Bien qu’il soit très courant d’exécuter les deux serveurs de noms sur le même serveur ou sous-réseau, cela ne fournirait pas de tolérance aux pannes. Si le serveur échoue, vos serveurs de noms échoueront et votre site ne se chargera pas.

ns1 IN A 75.33.22.xx —–> même sous-réseau /24
ns2 IN A 75.33.22.xx —–> même sous-réseau /24

3. GLUE approprié

Ajoutez toujours de la glue à vos enregistrements NS aux adresses IP en utilisant un enregistrement A, sinon l’un de vos serveurs de noms échouera.

domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 1.2.3.4 —–> GLUE
ns2 IN A 2.4.6.9 —–> GLUE

Référez-vous à RFC1912.

4. Pas d’enregistrements MX en double

domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com —-> DUPLICATE

5. Autoriser le port 53 pour les connexions UDP et TCP

Si vous utilisez un pare-feu, assurez-vous de ne pas bloquer le port 53 pour les requêtes DNS TCP et UDP. Par défaut, les recherches DNS utilisent le protocole UDP tandis que les transferts de zone et les notifications utilisent le protocole TCP du port 53.

Port 53 UDP = Requêtes DNS
Port 53 TCP = Transferts de zone

6. Les CNAME ne peuvent pas coexister avec les hôtes MX.

Ne spécifiez pas CNAME ou alias pointant vers des enregistrements MX.

domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ———-> FAUX

Utilisez plutôt un enregistrement A pour mapper directement à l’adresse IP.

mail IN A 11.33.55.77 —> CORRECT

Référez-vous à RFC1912.

7. Les enregistrements MX ne doivent pas contenir d’adresses IP

domain.com. IN 10 MX mail.domain.com. —-> CORRECT
domain.com. IN 20 MX 11.22.33.44 —–> FAUX

La bonne façon de faire cela est de coller l’hôte mx à l’enregistrement A.

domain.com. IN MX 10 mail.domain.com. —–> CORRECT
mail IN A 11.33.55.77 ———-> CORRECT

8. Les enregistrements NS ne doivent PAS contenir d’adresses IP

Spécifiez toujours les serveurs de noms pour votre domaine avec des enregistrements NS. Cela doit être un nom et non une adresse IP.

domain.com. IN NS dns0.domain.com. —–> CORRECT
domain.com. IN NS 75.xx.xx.xx ———–> FAUX

DNS INVERSE POUR LA LIVRAISON DE MAIL

Pour une livraison de mail appropriée, les méthodes anti-spam suivantes sont très importantes pour s’assurer que l’email est livré dans la boîte de réception des utilisateurs. La plupart des fournisseurs de services de messagerie publics comme yahoo, hotmail et gmail utilisent ces paramètres pour signaler si un email est du spam ou non.

(i) Configurer l’IP inverse pour votre serveur de messagerie avec PTR dans DNS (nécessite une IP dédiée)
(ii) Configurer l’enregistrement SPF dans votre DNS
(iii) Configurer les clés de domaine

J’ai constaté à de nombreuses occasions que si vous utilisez un plan d’hébergement partagé, la plupart des emails se retrouvent dans le dossier spam/bulk de la boîte de réception des utilisateurs. Donc, utilisez un serveur dédié.

Configurer des IP inverses pour les IPs de serveur de messagerie

Pour configurer une IP inverse, vous devrez d’abord faire une demande à votre fournisseur d’hébergement (puisqu’il possède l’adresse IP) et leur demander de configurer une IP inverse pour votre serveur de messagerie. Une fois cela fait, vous devez placer une ligne utilisant PTR dans votre fichier de zone de domaine.

Pour tester la recherche d’IP inverse :

 host

affichera la sortie du DNS inverse.

Configurer l’enregistrement SPF

L’enregistrement SPF est configuré en utilisant un enregistrement TXT dans votre fichier de zone DNS. Cela ressemble à ce qui est montré ci-dessous. Visitez http://openspf.org pour plus d’informations sur la configuration et l’installation.

domain.com. IN TXT “v=spf1 a mx ip4:11.33.55.77 -all”

Pour interroger l’enregistrement SPF en utilisant dig :

 dig domain.com TXT

Clés de domaine

Cela contient essentiellement 2 enregistrements (avec et sans sélecteur) placés sous TXT en utilisant un underscore avec la clé publique générée.

Le ‘sel’ est un sélecteur et peut être le nom du sélecteur.

Comment configurer les serveurs de noms DNS pour votre domaine en utilisant BIND9

Il vous suffit d’aller dans votre console Linux et de taper les commandes suivantes.

yum install bind

Créez un nouveau fichier de zone pour votre domaine et insérez le fichier de zone d’exemple (voir ci-dessous). Vous devez changer domain.com, le numéro de série et les paramètres d’email.

nano /var/named/domain.com.db

Ouvrez /etc/named.conf et placez les lignes suivantes :

zone “domain.com” {
type master;
file “/var/named/domain.com.com.db”;
};

Enregistrez les modifications dans le fichier et redémarrez bind.

service named restart

Exemple de fichier de zone DNS pour BIND

Utilisez ce fichier pour configurer vos domaines et serveurs de noms dans BIND9 :

;=================================================================
;EXEMPLE DE FICHIER DE ZONE DNS BIND
;pour TOUT domaine (il suffit de changer domain.com par votre site)
;================================================================

; Avant de commencer, N’OUBLIEZ PAS LE POINT ET L’INCRÉMENT DE SÉRIE

$TTL 14400
$ORIGIN domain.com.

; Enregistrement SOA
; Spécifiez le serveur de noms principal ns1.domain.com
; Le numéro de série doit être incrémenté à chaque mise à jour
@ 14400 IN SOA ns1.domain.com. webmaster.domain.com. ( 2009092902 ; Numéro de série au format AAAAMMJJXX (XX est l’incrément)
10800; secondes de rafraîchissement
3600; réessayer
604800; expirer
38400; minimum
);
; Adresse IP du site spécifiée dans l’enregistrement A

IN A xx.xx.xx.xx

; Minimum 2 noms de serveurs de noms DNS

IN NS ns1.domain.com.
IN NS ns2.domain.com.

; Mapper tous les serveurs de noms et leurs IP correspondantes (GLUE)

ns1 IN A xx.xx.xx.xx
ns2 IN A xx.xx.xx.xx

; Spécifiez ici tous les sous-domaines et l’entrée www en utilisant l’enregistrement CNAME

www IN CNAME domain.com.
ftp IN CNAME domain.com.
server IN CNAME domain.com.
webmail IN CNAME domain.com.

; Configurer l’enregistrement MX (échangeur de mail avec priorité)
domain.com. IN MX 10 mail.domain.com.

; définir l’enregistrement A pour le mail
mail IN A xx.xx.xx.xx;====================================

À propos de l’auteur

M. Balakrishnan est un entrepreneur Internet et administrateur Linux avec des intérêts dans la programmation PHP et les applications Linux. Il peut être contacté sur son site de blog corpocrat.com ou sur sa page Twitter.