Agrandir
/
Qu'est-ce que ce flux de chiffres binaires a à voir avec DNS ? Rien, vraiment, mais bonne chance pour trouver une jolie photo quelque part qui le fait !
Santo Heston
commentaires des lecteurs
121
avec 76 affiches participantes, y compris l'auteur de l'histoire
Partagez cette histoire
Partager sur Facebook
Partager sur Twitter
Partager sur Reddit
Si vous voulez être un administrateur système ou un administrateur réseau de quelque nature que ce soit, il existe une technologie fondamentale que vous devez vraiment comprendre : le DNS, le système de noms de domaine. Il fut un temps où un administrateur système sans ambition de gérer des services accessibles sur Internet pouvait s'en sortir sans comprendre le DNS, mais ce temps est révolu.
Vous ne pouvez pas apprendre tout ce qu'il y a à savoir sur le DNS dans un seul article. Mais ce n'est pas ce que nous cherchons à faire aujourd'hui ; au lieu de cela, nous voulons vous donner un guide clair et concis sur la structure et la signification de la partie la plus importante du système de noms de domaine : un fichier de zone, comme on le voit dans BIND, le Berkeley Internet Name Daemon.
Exemple de fichier de zone
Agrandir
/
Cet exemple de fichier de zone ne contient pas tous les types d'enregistrements possibles, mais c'est un bon début.
Jim Salter
Origine et TTL
Ci-dessus, nous avons un exemple petit mais complet d'un fichier de zone typique. En fait, il s'agit d'une version anonymisée d'un fichier de zone de production sur un domaine que je gère. Parcourons-le ligne par ligne.
$ORIGINE tld.$TTL 5m
Chaque fois que vous voyez un
$ORIGINE
ligne dans un fichier de zone, il s'agit d'un raccourci qui permet à BIND de savoir que toute référence de nom d'hôte non terminée suivant cette ligne doit être présumée se terminer par l'argument suivant
$ORIGINE
. Dans ce cas, c'est
.tld
—le domaine de premier niveau fictif pour
exemple.tld
.
La ligne suivante,
$TTL 5m
, déclare que les lignes suivantes auront une durée de vie de cinq minutes. Cette valeur relativement courte signifie que les résolveurs DNS distants ne doivent mettre en cache les enregistrements récupérés de cette zone que pendant cinq minutes avant de les redemander. Si vous êtes relativement certain que votre DNS pour un domaine donné ne changera pas très souvent, vous pouvez envisager d'augmenter cette valeur afin de réduire le nombre de fois où les hôtes distants doivent interroger votre serveur de noms, mais gardez à l'esprit qu'un TTL plus long est également signifie des périodes d'indisponibilité plus longues, lorsque vous devez apporter une modification à votre DNS (ou effectuer une modification qui le casse accidentellement).
Les deux
$ORIGINE
et
$TTL
peuvent être définis plusieurs fois dans la même zone — chaque fois que vous les redéfinissez, vous modifiez leur valeur pour toutes les lignes sous les nouvelles valeurs dans le même fichier de zone.
Enregistrement SOA
exemple DANS SOA ns1.example.tld. hostmaster.exemple.tld. ( 90 ; série 4h ; rafraîchissement 15m ; réessayer 8h ; expirer 4m) ; TTL de mise en cache négative
Le premier enregistrement réel de notre exemple de fichier de zone (ou de tout fichier de zone normal) est l'enregistrement SOA, qui nous indique le Start Of Authority pour le domaine. C'est aussi facilement le type d'enregistrement le plus déroutant de tout le système DNS.
Pour toute liste d'enregistrements, y compris cet enregistrement SOA, le premier argument est le nom d'hôte auquel l'enregistrement s'applique — dans ce cas,
Exemple
. Rappelez-vous comment nous définissons
$ORIGINE tld
sur la première ligne du fichier de zone ? Cela signifie que ce nom d'hôte non terminé
Exemple
s'étend à
exemple.tld
—donc, nous définissons le SOA pour le FQDN (nom de domaine complet)
exemple.tld.
Nous faisons référence à ce nom d'hôte
Exemple
comme "non terminé" car il ne se termine pas par un point. Si nous voulions contourner le
$ORIGINE
définir et faire référence à un nom de domaine complet directement, nous le terminerions par un point final, par exemple,
exemple.tld.
serait le FQDN ici,
avec
le point de fuite.
Le prochain argument que nous voyons est
DANS
, abréviation de « Internet ». C'est la classe record. Il existe d'autres classes d'enregistrement DNS, mais vous pouvez facilement faire toute votre carrière sans en voir une (comme
CH
, pour Chaos) en production. La classe record est facultative ; s'il est omis, BIND supposera que l'enregistrement spécifié est de classe
DANS
. Nous recommandons
ne pas
en l'omettant, cependant, de peur que quelque chose ne change et que tous vos fichiers de zone soient soudainement cassés après une mise à jour BIND !
Les deux arguments suivants sont des noms de domaine complets, du moins, ils y ressemblent. Le premier FQDN est vraiment un FQDN, et il devrait être le FQDN du serveur de noms principal pour le domaine lui-même — dans ce cas,
ns1.exemple.tld.
Notez que vous
pouvez
utilisez ici des noms d'hôte non terminés - par exemple, nous aurions pu simplement utiliser
ns1.exemple
pour cet argument, qui se serait étendu à
ns1.exemple.tld.
grâce à notre
$ORIGINE .tld
ligne, mais il est probablement préférable d'être explicite ici.
Le deuxième FQDN,
hostmaster.exemple.tld.
, n'est pas du tout un FQDN. Au lieu de cela, c'est une façon perverse de réécrire une adresse e-mail.
@
est un caractère réservé dans les fichiers de zone, et le BIND d'origine utilise la première section de ce "FQDN" comme partie utilisateur d'une adresse e-mail. Cela se traduirait donc par l'adresse
hostmaster@exemple.tld
. C'est
incroyablement
courant de voir cela foutu dans les fichiers de zone de la vie réelle - heureusement, cela n'a pas beaucoup d'importance. Nous ne connaissons littéralement personne qui utilise réellement cette fonctionnalité d'une zone DNS pour contacter qui que ce soit.
En continuant, nous avons
en série
,
rafraîchir
,
réessayez
,
expirer
, et
TTL négatif
pour la zone entre parenthèses. Notez que les commentaires que vous voyez ici les étiquetant ne sont pas obligatoires et dans la vraie vie, vous les verrez rarement. Nous préférons fortement mettre ces commentaires dans des fichiers de zone de production afin de faciliter leur lecture, mais BIND lui-même s'en moque !
en série
— il s'agit d'un simple numéro de série pour le fichier de zone, qui doit être incrémenté chaque fois que le contenu de la zone est modifié. Si vous ne mettez pas à jour le numéro de série du fichier de zone, vos modifications apportées à la zone ne seront pas prises en compte par les résolveurs DNS qui ont précédemment mis en cache les enregistrements de votre zone ! Autrefois, il s'agissait d'un format AAMMJJnn, mais ce format n'est plus requis, voire même pris en charge dans certains cas. Démarrez simplement vos zones en série
1
, incrémenter à
2
la prochaine fois que vous modifiez la zone, et ainsi de suite.
rafraîchir
— après cette période, les serveurs de noms secondaires doivent interroger le serveur de noms principal pour cet enregistrement SOA, afin de détecter les changements de numéro de série. Si le numéro de série a été incrémenté, tous les enregistrements mis en cache doivent être invalidés et récupérés à nouveau à partir du serveur de noms principal.
réessayez
— si le serveur de noms principal ne répond pas à une requête SOA, un serveur de noms secondaire doit attendre aussi longtemps avant d'essayer d'interroger à nouveau le serveur de noms principal.
expirer
— si le serveur de noms principal n'a pas réussi à répondre à la demande SOA d'un serveur de noms secondaire pendant cette période, le serveur de noms secondaire doit cesser entièrement d'offrir la résolution DNS pour le domaine.
TTL de mise en cache négative
—cela contrôle la durée pendant laquelle une réponse "négative"—par exemple, "Je n'ai pas l'enregistrement que vous demandez"—doit être mise en cache.
Publicité
L'un des domaines de confusion les plus courants dans l'enregistrement SOA est l'effet
rafraîchir
,
réessayez
, et
expirer
arguments ont. Ces arguments n'affectent pas du tout les résolveurs DNS, mais uniquement les serveurs de noms secondaires faisant autorité pour le domaine. si vous n'avez pas un ou plusieurs serveurs de noms secondaires pour votre domaine, qui utilisent la réplication BIND pour récupérer les mises à jour du primaire, ces arguments n'auront aucun effet.
Une dernière remarque : les anciennes versions de BIND exigeaient que tous ces temps soient en secondes... même lorsque l'intervalle de temps réel était en jours ou en semaines. BIND9—publié il y a près de 20 ans, en octobre 2000—prend en charge les suffixes de temps lisibles par l'homme tels que "m" pour les minutes, "h" pour les heures et "d" pour les jours.
S'il te plaît
utilisez ces suffixes lisibles par l'homme lors de l'écriture des fichiers de zone ; personne ne devrait avoir à sortir une calculatrice pour comprendre que 86 400 secondes représentent un jour !
enregistrements NS
EN NS ns1.example.tld.IN NS ns2.example.tld.
Dans ces deux enregistrements, nous définissons les noms d'hôtes, qui sont des serveurs de noms faisant autorité pour notre zone. Encore une fois, nous avons utilisé des FQDN terminés par des points pour ces enregistrements. Encore une fois, nous
pourrait
ont utilisé des noms d'hôtes non terminés—
ns1.exemple
et
ns2.exemple
- et s'est appuyé sur notre
$ORIGINE .tld
pour les étendre. Cela rendrait la zone plus confuse et difficile à lire, cependant.
Notez que l'enregistrement NS spécifie
noms d'hôtes
, pas les adresses IP. C'est une source courante de confusion pour les débutants en DNS, et il est important de bien faire les choses. Tu
ne peut pas
spécifiez une adresse IP nue comme serveur de noms pour un domaine ; vous devez absolument spécifier un nom d'hôte ici.
Enfin, notez que nous n'avons spécifié le nom de domaine lui-même sur aucune des lignes, c'est parce que nous l'avons hérité du
SOA
enregistrement ci-dessus. Nous avons commencé cette ligne avec
Exemple
, qui s'étend à
exemple.tld
. Comme nous n'avons pas spécifié d'autre nom d'hôte, ces nouveaux
N.-É.
Les enregistrements s'appliquent également à ce nom d'hôte par défaut.
Dans le monde réel, vous pouvez également voir des fichiers de zone avec
$ORIGINE exemple.tld.
, et en commençant le SOA et éventuellement d'autres lignes avec le caractère réservé spécial
@
. Quand tu vois
@
en tant que nom d'hôte dans un fichier de zone, cela signifie simplement que vous utilisez le nu
$ORIGINE
sans autre qualificatif.
Enregistrement(s) MX
EN MX 10 mail.exemple.tld.
Dans ce domaine simple, nous avons un seul serveur de messagerie, et c'est
mail.exemple.tld.
L'enregistrement MX indique simplement à quiconque souhaite envoyer un e-mail à n'importe quelle adresse à
exemple.tld
pour établir leur connexion SMTP au nom d'hôte spécifié dans cet enregistrement.
L'argument précédent—
dix
dans ce cas, correspond à la priorité numérique du serveur de messagerie dans cet enregistrement spécifique. Des nombres inférieurs signifient une priorité plus élevée. Lorsque plusieurs serveurs SMTP sont disponibles pour un domaine, vous verrez plusieurs
MX
également, chacun avec une priorité différente. En théorie, les serveurs de messagerie de priorité plus élevée doivent toujours être essayés en premier, et les serveurs de messagerie de priorité plus faible ne doivent être essayés que si le serveur de priorité plus élevée échoue.
Les serveurs SMTP bien élevés suivent ce protocole, mais les spammeurs ont tendance à cibler délibérément les serveurs de messagerie de priorité inférieure en premier, en partant du principe que les serveurs à priorité élevée pourraient être des passerelles anti-spam, et que les serveurs de priorité inférieure pourraient être les serveurs nus. , serveur final non filtré. Les spammeurs sont nuls.
Un ou plusieurs enregistrements
DANS UN 127.0.0.1
Un enregistrement est la partie d'un fichier de zone qui fait en réalité ce que la plupart des gens pensent du DNS : ils traduisent un nom d'hôte en une adresse IPv4 nue. Dans ce cas, il ne s'agit que d'un exemple de fichier—et notre
UNE
enregistrer pour
exemple.tld
se résout simplement à localhost, sur le même principe que les numéros de téléphone dans les films commencent toujours par l'échange
555
. Dans la vraie vie, bien sûr, vous mettriez l'adresse IP du serveur auquel vous vous attendiez à répondre lorsque vous
exemple de ping.tld
, pointez un navigateur Web sur
https://exemple.tld/
, et ainsi de suite.
Dans ce simple fichier de zone, nous n'avons qu'un seul
UNE
enregistrer pour
exemple.tld
. Dans la vraie vie, vous pourriez en rencontrer plusieurs : il pourrait y avoir plusieurs serveurs de passerelle capables de répondre aux requêtes Web pour
https://exemple.tld/
; et si c'était le cas, chacun obtiendrait son propre enregistrement A sur sa propre ligne.
Enregistrement(s) TXT
EN TXT "v=spf1 a mx a:mail.example.tld a:www.example.tld ?all"
Cette
SMS
, ou enregistrement de texte, est toujours dans la section head de notre fichier de zone, sous le nom d'hôte
exemple.tld
. Son champ d'application est donc l'ensemble
exemple.tld
domaine. Vous pouvez mettre à peu près n'importe quoi dans un
SMS
enregistrer; celui-ci est un
FPS
enregistrement, formaté pour donner aux serveurs de messagerie des informations sur les machines autorisées à émettre du courrier au nom de
exemple.tld
.
Dans ce cas, nous disons que nous utilisons la version SPF1 du formatage. Nous informons ensuite toute personne interrogeant cet enregistrement que tout
UNE
enregistrer pour
exemple.tld
est autorisé à envoyer du courrier en son nom, comme tout
MX
pour le domaine, et enfin que les adresses IP associées au
UNE
dossiers pour
mail.exemple.tld
et
www.exemple.tld
sont autorisés à envoyer du courrier. Finalement,
?tous
dit que si une autre machine dit qu'elle veut envoyer du courrier à partir d'une adresse à
exemple.tld
, cela devrait être autorisé... mais cela devrait être examiné de plus près que ne le sont les hôtes spécifiquement autorisés.
Noms d'hôtes, sous-domaines et CNAME sous example.tld
$ORIGINE example.tld.ns1 DANS UN 127.0.0.2ns2 DANS UN 127.0.0.3www DANS CNAME example.tld.mail DANS AAAA ::1mail DANS UN 127.0.0.4
Maintenant que nous avons défini tout ce dont nous avons besoin pour le domaine, nous pouvons commencer à ajouter des enregistrements pour tous les noms d'hôtes et sous-domaines
sous
exemple.tld
lui-même. La première chose que nous faisons ici est de changer notre
$ORIGINE
à
exemple.tld.
Encore une fois, remarquez ce dernier point de terminaison : si vous l'oubliez, les choses vont devenir vraiment étranges et vous vous arracherez les cheveux en vous demandant pourquoi aucun de vos enregistrements ne se résout correctement !
Nous voyons
UNE
enregistre ici pour
ns1
,
ns2
, et
courrier
. Ces
UNE
les enregistrements fonctionnent de la même manière que les
UNE
record pour le domaine lui-même l'a fait - nous disons à BIND à quelle adresse IP résoudre les demandes pour ce nom d'hôte.
Nous avons également un
AAAA
enregistrer pour
mail.exemple.tld.
-
AAAA
les enregistrements sont comme
UNE
enregistrements, mais ils sont destinés à résoudre IPv6 plutôt qu'IPv4. Encore une fois, nous avons choisi dans notre exemple d'utiliser une adresse localhost. Vous devrez vous familiariser avec
AAAA
enregistrements si vous prévoyez de configurer votre propre serveur de messagerie : Google a cessé de vouloir parler aux serveurs de messagerie sans un DNS IPv6 pleinement fonctionnel il y a quelques années !
Publicité
Le dernier type d'enregistrement que nous voyons ici est
CNAME
, abréviation de nom canonique. Ceci est un alias—il vous permet de dire à BIND de toujours résoudre les demandes pour le
CNAME
d hôte à l'aide de l'enregistrement A ou AAAA spécifié dans l'argument cible. Dans ce cas,
www IN CNAME exemple.tld.
signifie que l'adresse IP de
exemple.tld
lui-même devrait également être remis si quelqu'un demande
www.exemple.tld.
CNAME
les disques sont pratiques, mais ils sont un peu funky. Il ne faut pas oublier que chaque niveau de
CNAME
nécessite une autre recherche DNS - dans ce cas, une machine distante qui a demandé à résoudre
www.exemple.tld
serait dit " s'il vous plaît regardez vers le haut
exemple.tld.
afin de trouver votre réponse", puis devrait émettre un
séparé
requête DNS pour le
UNE
enregistrement associé à
exemple.tld.
Si tu as
CNAME
s pointant vers
CNAME
s pointant vers
CNAME
s, vous introduirez une latence inutile dans les demandes de vos ressources, et votre domaine apparaîtra « lent » et « retardé » pour vos utilisateurs !
Il y a d'autres limitations dans
CNAME
enregistrements. Rappelez-vous comment nous vous avons dit que
MX
et
N.-É.
les enregistrements doivent pointer vers des noms d'hôtes, pas vers des adresses IP brutes ? Plus précisément, ils doivent pointer directement vers
UNE
enregistrements, de ne pas
CNAME
enregistrements. Si vous essayez de définir
MX mail.exemple.tld.
suivie par
mail.exemple.tld. CNAME exemple.tld.
, votre fichier de zone sera cassé, et
MX
les tentatives de recherche renverront des erreurs.
Outils du métier
Si vous gérez votre propre DNS, vous devrez maîtriser les outils de ligne de commande pour interroger directement votre serveur DNS et voir comment il répond aux requêtes. en mettant
https://exemple.tld/
dans un navigateur et voir ce qui se passe.
creuser
you@box:~$ dig @127.0.0.1 NS example.tld; <<>> DiG 9.16.1-Ubuntu <<>> NS example.tld;; options globales : +cmd;; Réponse obtenue : ;; ->>EN-TÊTE<
Si vous avez accès à Linux, Mac ou au sous-système Windows pour Linux, le meilleur outil de ligne de commande est de loin
creuser
. À l'aide de
creuser
est aussi simple que de spécifier un serveur à interroger, le type d'enregistrement que vous souhaitez rechercher et le nom de domaine complet auquel il doit être associé.
Dans l'exemple ci-dessus, nous avons demandé au serveur DNS à
127.0.0.1
pour tout nous montrer
N.-É.
enregistrements associés à
exemple.tld
. En plus des réponses que nous voulions, nous avons obtenu une tonne d'informations de diagnostic - le serveur DNS que nous avons interrogé n'a pas renvoyé de
ERREUR
lorsqu'il est interrogé, il dit qu'il fait autorité pour le domaine en question, et ainsi de suite.
Vous pouvez également fournir un
+court
argumente si tu veux
creuser
pour se taire et vous donner la réponse que vous cherchez sans tous les diagnostics détaillés :
you@box:~$ dig +short @127.0.0.1 NS example.tldns1.example.tld.ns2.example.tld.
Sachez cependant que s'il n'y a pas de réponses disponibles pour un
+court
requête, par exemple, si vous tapez le nom de domaine, vous n'obtiendrez aucune réponse, même si le serveur DNS interrogé a renvoyé une erreur.
you@box:~$ dig +short @127.0.0.1 NS example.tmdyou@box:~$
Si vous voulez savoir
Pourquoi
vous n'avez pas obtenu de réponse, vous devrez perdre le
+court
argument pour le savoir.
nslookup
Si vous n'avez pas accès à
creuser
, vous pouvez généralement vous en tirer avec
nslookup
. Le plus souvent, il s'agit d'une solution de contournement semi-maudite pour les utilisateurs assis devant une boîte Windows sans accès au sous-système Windows pour Linux, à cygwin ou à un autre moyen d'accéder à des outils plus avancés que ceux fournis par l'interface de ligne de commande Windows.
nslookup
est généralement invoqué sans arguments et interrogé en mode interactif. Voici un exemple de session :
C:\> nslookup> serveur 127.0.0.1 Serveur par défaut : 127.0.0.1Adresse : 127.0.0.1#53> example.tldServer : 127.0.0.1Address : 127.0.0.1#53Réponse ne faisant pas autorité : Nom : example.tldAddress : 127.0. 0,1
En définissant
serveur 127.0.0.1
, nous avons spécifié à
nslookup
d'utiliser cette machine comme serveur DNS pour interroger. Vous n'êtes pas obligé de le spécifier ; si vous ne le faites pas,
nslookup
utilisera le résolveur DNS par défaut de votre machine.
Après avoir éventuellement réglé le
serveur
, vous pouvez simplement taper un nom d'hôte nu dans
nslookup
l'invite interactive de , et il renverra n'importe quel
UNE
ou
AAAA
enregistrements qu'il peut trouver pour ce nom d'hôte.
Si vous souhaitez interroger le serveur distant pour un type d'enregistrement différent, vous devrez utiliser un
définir le type
commander.
> set type=ns> example.tldServer: 127.0.0.1Address: 127.0.0.1#53Non-authoritative answer:example.tld nameserver = ns1.example.tld.example.tld nameserver = ns2.example.tld.Les réponses faisant autorité peuvent être trouvé à partir de :> set type=mx > example.tldServer : 127.0.0.1Address : 127.0.0.1#53Réponse non autorisée :example.tld mail exchanger = 10 mail.example.tld.Les réponses faisant autorité peuvent être trouvées à partir de :example.tld nameserver = ns2.example.tld.example.tld nameserver = ns1.example.tld.mail.example.tld adresse internet = 127.0.0.4> exit
Dans les exemples ci-dessus, nous avons utilisé
définir le type=ns
et
définir le type=mx
pour interroger le serveur DNS distant pour
N.-É.
et
MX
dossiers pour
exemple.tld
. Cela fonctionne et vous obtenez vos réponses... mais la syntaxe est délicate, il y a moins d'informations de diagnostic disponibles, c'est beaucoup moins scriptable, et si vous êtes comme nous, vous maudirez probablement la chose obsolète une ou deux fois avant vous c'est fini.
La bonne façon de sortir de
nslookup
le mode interactif de est la commande
sortir
. Espérons que vous n'aurez jamais besoin de rechercher des informations sur un domaine de premier niveau également nommé
sortir
-ou si vous le faites, vous aurez un meilleur outil disponible que
nslookup
quand tu le fais.
Conclusion
J'espère que vous avez trouvé quelque chose de précieux aujourd'hui sur le fonctionnement du DNS et la manière dont ses informations sont stockées. Bien que BIND ne soit pas la seule plate-forme de serveur DNS, en particulier, les administrateurs Windows devront travailler avec Active Directory DNS, les leçons apprises ici s'appliquent presque également à toutes les plates-formes et applications.
Bien que le format de stockage puisse changer quelque peu d'un serveur à l'autre, comme un contrôleur de domaine Active Directory stockant littéralement des zones à l'intérieur d'Active Directory lui-même, plutôt qu'un fichier texte brut, les types d'enregistrement sont universels et le formatage au moins quasi universel.
Si vous êtes un administrateur système en herbe ou un passionné qui souhaite exécuter votre propre serveur DNS, je vous recommande fortement de le faire et d'utiliser la plate-forme d'origine lorsque vous le faites ; BIND sur Linux ou BSD. La charge système d'exécution d'un serveur de noms est presque inexistante à n'importe quelle échelle, à moins d'être vraiment massive ; une boîte Digital Ocean ou Linode à 5 $ peut très bien faire le travail.
En plus de la pure joie d'apprendre à gérer ces choses, vous pouvez également constater que vous appréciez la possibilité de définir vos TTL absurdement courts - la plupart des serveurs DNS gérés n'autoriseront pas un TTL de moins de 30 m, et la plupart essaieront de passer par défaut vous à des TTL allant jusqu'à une semaine. C'est très bien pour une zone DNS, qui est déjà correctement configurée et n'a pas besoin de changer... mais si votre adresse IP change et que votre DNS doit changer avec elle, un TTL de cinq minutes est très, très belle chose à avoir.
