Introduction
Le DNS, ou Domain Name System, est souvent une partie très difficile à appréhender lors de l’apprentissage de la configuration des sites web et des serveurs. Comprendre le fonctionnement du DNS vous aidera à diagnostiquer les problèmes liés à la configuration de l’accès à vos sites web et vous permettra d’approfondir votre compréhension de ce qui se passe en coulisses.
Dans ce guide, nous aborderons certains concepts fondamentaux du DNS qui vous aideront à démarrer rapidement avec votre configuration DNS. Après avoir abordé ce guide, vous devriez être prêt à configurer votre nom de domaine avec DigitalOcean ou mettre en place votre propre serveur DNS.
Avant de passer à la configuration de vos propres serveurs pour résoudre votre domaine ou de configurer nos domaines dans le panneau de contrôle, examinons quelques concepts de base sur le fonctionnement réel de tout cela.
Terminologie de domaine
Nous devrions commencer par définir nos termes. Bien que certains de ces sujets soient familiers dans d’autres contextes, il y a de nombreux termes utilisés lorsqu’on parle de noms de domaine et de DNS qui ne sont pas trop souvent utilisés dans d’autres domaines de l’informatique.
Commençons par le plus simple:
Système de noms de domaine
Le système de noms de domaine, plus communément appelé « DNS », est le système de réseau en place qui nous permet de résoudre des noms conviviaux pour les humains en adresses IP uniques.
Nom de domaine
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
L’URL « google.com » est associée aux serveurs appartenant à Google Inc. Le système de noms de domaine nous permet d’atteindre les serveurs Google lorsque nous tapons « google.com » dans nos navigateurs.
Adresse IP
Une adresse IP est ce que nous appelons un emplacement adressable sur un réseau. Chaque adresse IP doit être unique dans son réseau. Lorsque nous parlons de sites Web, ce réseau est l’ensemble d’Internet.
IPv4, la forme la plus courante d’adresses, sont écrites sous la forme de quatre ensembles de nombres, chaque ensemble ayant jusqu’à trois chiffres, avec chaque ensemble séparé par un point. Par exemple, « 111.222.111.222 » pourrait être une adresse IP IPv4 valide. Avec DNS, nous associons un nom à cette adresse afin que vous n’ayez pas à vous souvenir d’un ensemble compliqué de nombres pour chaque endroit que vous souhaitez visiter sur un réseau.
Domaine de premier niveau
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
Les domaines de premier niveau sont au sommet de la hiérarchie en termes de noms de domaine. Certaines parties sont dotées du contrôle de gestion sur les domaines de premier niveau par l’ICANN (Internet Corporation for Assigned Names and Numbers). Ces parties peuvent alors distribuer des noms de domaine sous le TLD, généralement par l’intermédiaire d’un registre de domaines.
Hôtes
Dans un domaine, le propriétaire du domaine peut définir des hôtes individuels, qui font référence à des ordinateurs ou services séparés accessibles via un domaine. Par exemple, la plupart des propriétaires de domaines rendent leurs serveurs web accessibles via le domaine nu (example.com) et également via la définition d’hôte « www » (www.example.com).
Vous pouvez avoir d’autres définitions d’hôtes sous le domaine général. Vous pourriez avoir un accès API via un hôte « api » (api.example.com) ou vous pourriez avoir un accès ftp en définissant un hôte appelé « ftp » ou « files » (ftp.example.com ou files.example.com). Les noms d’hôte peuvent être arbitraires tant qu’ils sont uniques pour le domaine.
Sous-Domaine
A subject related to hosts are subdomains.
Le DNS fonctionne de manière hiérarchique. Les TLD peuvent avoir de nombreux domaines sous eux. Par exemple, le TLD « com » a à la fois « google.com » et « ubuntu.com » sous lui. Un « sous-domaine » fait référence à tout domaine qui fait partie d’un domaine plus grand. Dans ce cas, « ubuntu.com » peut être considéré comme un sous-domaine de « com ». C’est généralement appelé le domaine ou la partie « ubuntu » est appelée SLD, ce qui signifie domaine de deuxième niveau.
De même, chaque domaine peut contrôler des « sous-domaines » qui se trouvent sous lui. C’est généralement ce que nous entendons par sous-domaines. Par exemple, vous pourriez avoir un sous-domaine pour le département d’histoire de votre école à « www.history.school.edu« . La partie « history » est un sous-domaine.
La différence entre un nom d’hôte et un sous-domaine est qu’un hôte définit un ordinateur ou une ressource, tandis qu’un sous-domaine étend le domaine parent. C’est une méthode de subdivision du domaine lui-même.
Cela signifie qu’il spécifie chaque domaine parent, y compris le TLD. Un FQDN correct se termine par un point, indiquant la racine de la hiérarchie DNS. Un exemple de FQDN est « mail.google.com.« . Parfois, les logiciels qui demandent un FQDN n’exigent pas le point final, mais le point final est nécessaire pour se conformer aux normes de l’ICANN.
Serveur de noms
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
Les serveurs de noms peuvent être « authoritative », ce qui signifie qu’ils donnent des réponses aux requêtes sur les domaines sous leur contrôle. Sinon, ils peuvent pointer vers d’autres serveurs ou servir des copies mises en cache des données d’autres serveurs de noms.
Fichier de zone
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
Les fichiers de zone résident dans les serveurs de noms et définissent généralement les ressources disponibles sous un domaine spécifique, ou l’endroit où l’on peut aller pour obtenir ces informations.
Enregistrements
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
Dans un fichier de zone, des enregistrements sont conservés. Dans sa forme la plus simple, un enregistrement est essentiellement une seule correspondance entre une ressource et un nom. Ils peuvent mapper un nom de domaine à une adresse IP, définir les serveurs de noms pour le domaine, définir les serveurs de messagerie pour le domaine, etc.
Enregistrements
Dans un fichier de zone, les enregistrements sont conservés. Dans sa forme la plus simple, un enregistrement est essentiellement une correspondance unique entre un ressource et un nom. Ces enregistrements peuvent associer un nom de domaine à une adresse IP, définir les serveurs de noms pour le domaine, définir les serveurs de messagerie pour le domaine, etc.
Fonctionnement du DNS
Maintenant que vous êtes familier avec certains des termes impliqués dans le DNS, comment fonctionne le système réellement?
Le système est très simple à un niveau de vue général, mais est très complexe lorsque vous regardez les détails. Néanmoins, c’est une infrastructure très fiable qui a été essentielle à l’adoption d’Internet tel que nous le connaissons aujourd’hui.
Serveurs racines
Comme nous l’avons dit ci-dessus, le DNS est, dans son essence, un système hiérarchique. Au sommet de ce système se trouvent ce qu’on appelle les « serveurs racines ». Ces serveurs sont contrôlés par diverses organisations et sont délégués d’autorité par l’ICANN (Internet Corporation for Assigned Names and Numbers).
Il existe actuellement 13 serveurs racines en fonctionnement. Cependant, étant donné le nombre incroyable de noms à résoudre chaque minute, chacun de ces serveurs est en réalité mise en miroir. La chose intéressante à propos de cet ensemble est que chacun des miroirs pour un seul serveur racine partagent la même adresse IP. Lorsque des demandes sont faites pour un certain serveur racine, la demande sera acheminée vers le miroir le plus proche de ce serveur racine.
Que font ces serveurs racines? Les serveurs racines traitent les demandes d’informations sur les domaines de premier niveau. Donc, si une demande arrive pour quelque chose qu’un serveur de noms de niveau inférieur ne peut pas résoudre, une requête est faite au serveur racine pour le domaine.
Les serveurs racines ne sauront pas réellement où le domaine est hébergé. Ils seront cependant en mesure de diriger l’auteur de la demande vers les serveurs de noms qui traitent le domaine de premier niveau spécifiquement demandé.
Donc, si une demande pour « www.wikipedia.org » est faite au serveur racine, le serveur racine ne trouvera pas le résultat dans ses enregistrements. Il vérifiera ses fichiers de zone pour un enregistrement correspondant à « www.wikipedia.org« . Il ne le trouvera pas.
Il trouvera plutôt un enregistrement pour le « org » TLD et donnera à l’entité qui fait la demande l’adresse du serveur de noms responsable des adresses « org ».
Serveurs TLD
L’auteur de la demande envoie ensuite une nouvelle demande à l’adresse IP (donnée par le serveur racine) qui est responsable du domaine de premier niveau de la demande.
Donc, pour continuer notre exemple, cela enverrait une demande au serveur de noms responsable de la connaissance des domaines « org » pour voir s’il sait où se trouve « www.wikipedia.org« .
Une fois de plus, le demandeur cherchera « www.wikipedia.wikipedia.org » dans ses fichiers de zone. Il ne trouvera pas cet enregistrement dans ses fichiers.
Cependant, il trouvera un enregistrement indiquant l’adresse IP du serveur de noms responsable de « wikipedia.org« . C’est beaucoup plus proche de la réponse que nous voulons.
Serveurs de noms au niveau du domaine
À ce stade, le demandeur a l’adresse IP du serveur de noms qui est responsable de connaître l’adresse IP réelle de la ressource. Il envoie une nouvelle demande au serveur de noms en lui demandant, une fois de plus, s’il peut résoudre « www.wikipedia.org« .
Le serveur de noms vérifie ses fichiers de zone et il constate qu’il a un fichier de zone associé à « wikipedia.org« . À l’intérieur de ce fichier, il y a un enregistrement pour l’hôte « www ». Cet enregistrement indique l’adresse IP où se trouve cet hôte. Le serveur de noms retourne la réponse finale au demandeur.
Qu’est-ce qu’un serveur de noms résolveur?
Dans le scénario ci-dessus, nous avons fait référence à un « requérant ». Quel est le requérant dans cette situation?
Dans presque tous les cas, le requérant sera ce que nous appelons un « serveur de noms résolvant ». Un serveur de noms résolvant est un serveur configuré pour poser des questions à d’autres serveurs. Il sert essentiellement d’intermédiaire pour l’utilisateur et stocke en cache les résultats des requêtes précédentes pour améliorer la rapidité et connaît les adresses des serveurs racine pour pouvoir « résoudre » les requêtes concernant des éléments qu’il ne connaît pas déjà.
En gros, un utilisateur aura généralement quelques serveurs de noms résolvant configurés sur son système informatique. Les serveurs de noms résolvant sont généralement fournis par un FAI ou d’autres organisations. Par exemple Google fournit des serveurs DNS résolvants que vous pouvez interroger. Ils peuvent être configurés sur votre ordinateur automatiquement ou manuellement.
Lorsque vous saisissez une URL dans la barre d’adresse de votre navigateur, votre ordinateur vérifie d’abord s’il peut déterminer localement où se trouve la ressource. Il consulte le fichier « hosts » sur l’ordinateur et quelques autres emplacements. Il envoie ensuite la requête au serveur de noms résolvant et attend de recevoir l’adresse IP de la ressource.
Le serveur de noms résolvant vérifie ensuite dans sa cache pour obtenir la réponse. S’il ne la trouve pas, il passe par les étapes décrites ci-dessus.
Les serveurs de noms résolvant permettent essentiellement de compresser le processus de requête pour l’utilisateur final. Les clients doivent simplement savoir demander aux serveurs de noms résolvant où se trouve une ressource et avoir confiance qu’ils enquêteront et retourneront la réponse finale.
Fichiers de zone
Nous avons mentionné dans le processus ci-dessus l’idée de « fichiers de zone » et de « enregistrements ».
Les fichiers de zone sont la façon dont les serveurs de noms stockent des informations sur les domaines qu’ils connaissent. Chaque domaine qu’un serveur de noms connaît est stocké dans un fichier de zone. La plupart des requêtes adressées au serveur de noms moyen ne concernent pas des domaines pour lesquels le serveur possède des fichiers de zone.
S’il est configuré pour gérer des requêtes récursives, comme un serveur de noms résolveur, il trouvera la réponse et la renverra. Sinon, il indiquera à la partie demanderesse où chercher ensuite.
Plus un serveur de noms possède de fichiers de zone, plus il pourra répondre de manière autoritaire à des requêtes.
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
L’origine de la zone $ORIGIN est un paramètre égal au niveau d’autorité le plus élevé de la zone par défaut.
Ainsi, si un fichier de zone est utilisé pour configurer le domaine « example.com.« , l’origine $ORIGIN serait définie sur example.com..
Cela est configuré soit en haut du fichier de zone, soit peut être défini dans le fichier de configuration du serveur DNS qui référence le fichier de zone. Dans tous les cas, ce paramètre décrit ce pour quoi la zone sera autoritaire.
De même, le $TTL configure le « temps de vie » des informations qu’il fournit. C’est essentiellement un minuteur. Un serveur de noms en cache peut utiliser des résultats précédemment interrogés pour répondre à des questions jusqu’à ce que la valeur TTL soit épuisée.
Types d’enregistrements
Dans le fichier de zone, nous pouvons avoir plusieurs types d’enregistrements différents. Nous passerons en revue certains des types les plus courants (ou obligatoires) ici.
Enregistrements SOA
L’enregistrement Start of Authority, ou SOA, est un enregistrement obligatoire dans tous les fichiers de zone. Il doit être le premier enregistrement réel dans un fichier (bien que les spécifications $ORIGIN ou $TTL puissent apparaître au-dessus). C’est aussi l’un des plus complexes à comprendre.
L’enregistrement de début d’autorité ressemble à ceci :
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
Expliquons à quoi sert chaque partie :
-
domain.com.: C’est la racine de la zone. Cela spécifie que le fichier de zone est pour le domainedomain.com.. Souvent, vous verrez cela remplacé par@, qui est juste un espace réservé qui substitue le contenu de la variable$ORIGINque nous avons appris ci-dessus. -
DANS SOA: La partie « IN » signifie internet (et sera présente dans de nombreux enregistrements). SOA est l’indicateur qu’il s’agit d’un enregistrement de début d’autorité.
-
ns1.domain.com.: Cela définit le serveur de noms principal pour ce domaine. Les serveurs de noms peuvent être soit primaires soit secondaires, et si le DNS dynamique est configuré, un serveur doit être un « principal », qui va ici. Si vous n’avez pas configuré de DNS dynamique, alors c’est juste l’un de vos serveurs de noms principaux. -
admin.domain.com.: Il s’agit de l’adresse e-mail de l’administrateur pour cette zone. Le « @ » est remplacé par un point dans l’adresse e-mail. Si la partie nom de l’adresse e-mail a normalement un point, celui-ci est remplacé par un « » dans cette partie ([email protected]devientvotre\nom.domain.com). -
12083: Il s’agit du numéro de série du fichier de zone. Chaque fois que vous modifiez un fichier de zone, vous devez augmenter ce numéro pour que le fichier de zone se propage correctement. Les serveurs secondaires vérifieront si le numéro de série du serveur principal pour une zone est supérieur à celui qu’ils ont sur leur système. S’il l’est, il demande le nouveau fichier de zone, sinon, il continue de servir le fichier original.
-
3h: Il s’agit de l’intervalle de rafraîchissement pour la zone. C’est le temps que le serveur secondaire attendra avant de consulter le serveur principal pour les modifications du fichier de zone.
-
30m: C’est l’intervalle de nouvelle tentative pour cette zone. Si le serveur secondaire ne peut pas se connecter au serveur primaire lorsque la période de rafraîchissement est écoulée, il attendra cette durée et réessaiera de sonder le serveur primaire.
-
3w: C’est la période d’expiration. Si un serveur de noms secondaire n’a pas pu contacter le serveur primaire pendant cette période, il ne renvoie plus de réponses en tant que source d’autorité pour cette zone.
-
1h: C’est la durée pendant laquelle le serveur de noms mettra en cache une erreur de nom s’il ne peut pas trouver le nom demandé dans ce fichier.
A and AAAA Records
Les deux de ces enregistrements cartographient un hôte avec une adresse IP. L’enregistrement « A » est utilisé pour mapper un hôte avec une adresse IP IPv4, tandis que les enregistrements « AAAA » sont utilisés pour mapper un hôte avec une adresse IPv6.
Le format général de ces enregistrements est le suivant:
host IN A IPv4_address
host IN AAAA IPv6_address
Donc, puisque notre enregistrement SOA mentionne un serveur principal à « ns1.domain.com », nous devrions mapper ceci à une adresse IP puisque « ns1.domain.com » est dans la zone « domain.com » que ce fichier définit.
L’enregistrement pourrait ressembler à ceci :
ns1 IN A 111.222.111.222
Remarquez que nous n’avons pas besoin de donner le nom complet. Nous pouvons simplement donner l’hôte, sans le FQDN, et le serveur DNS remplira le reste avec la valeur $ORIGIN. Cependant, nous pourrions tout aussi bien utiliser le FQDN entier si nous voulons être sémantiques :
ns1.domain.com. IN A 111.222.111.222
Dans la plupart des cas, c’est là que vous définirez votre serveur web comme « www » :
www IN A 222.222.222.222
Nous devrions également indiquer où le domaine de base se résout. Nous pouvons le faire comme ceci :
domain.com. IN A 222.222.222.222
Nous aurions pu utiliser « @ » pour faire référence au domaine de base également :
@ IN A 222.222.222.222
Nous avons également la possibilité de résoudre tout ce qui se trouve sous ce domaine qui n’est pas défini explicitement vers ce serveur aussi. Nous pouvons le faire avec le joker « * » :
* IN A 222.222.222.222
Tous ces éléments fonctionnent tout aussi bien avec les enregistrements AAAA pour les adresses IPv6.
Enregistrements CNAME
Les enregistrements CNAME définissent un alias pour le nom canonique de votre serveur (défini par un enregistrement A ou AAAA).
Par exemple, nous pourrions avoir un enregistrement de nom A définissant l’hôte « server1 » et ensuite utiliser « www » comme alias pour cet hôte :
server1 IN A 111.111.111.111
www IN CNAME server1
Sachez que ces alias entraînent des pertes de performance car ils nécessitent une requête supplémentaire au serveur. La plupart du temps, le même résultat pourrait être obtenu en utilisant des enregistrements A ou AAAA supplémentaires.
Un cas où un CNAME est recommandé est de fournir un alias pour une ressource en dehors de la zone actuelle.
Enregistrements MX
Les enregistrements MX sont utilisés pour définir les échanges de courrier utilisés pour le domaine. Cela aide les messages électroniques à arriver correctement sur votre serveur de messagerie.
Contrairement à de nombreux autres types d’enregistrements, les enregistrements de messagerie ne mappent généralement pas un hôte vers quelque chose, car ils s’appliquent à toute la zone. En tant que tel, ils ressemblent généralement à ceci:
IN MX 10 mail.domain.com.
Notez qu’il n’y a pas de nom d’hôte au début.
Notez également qu’il y a un numéro supplémentaire. Il s’agit du numéro de préférence qui aide les ordinateurs à décider vers quel serveur envoyer le courrier s’il existe plusieurs serveurs de messagerie définis. Les numéros plus bas ont une priorité plus élevée.
L’enregistrement MX devrait généralement pointer vers un hôte défini par un enregistrement A ou AAAA, et non pas par un CNAME.
Donc, disons que nous avons deux serveurs de messagerie. Il faudrait alors des enregistrements qui ressemblent à ceci:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
Dans cet exemple, l’hôte « mail1 » est le serveur d’échange de courrier électronique préféré.
Nous pourrions également écrire cela de la manière suivante:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
Enregistrements NS
Ce type d’enregistrement définit les serveurs de noms utilisés pour cette zone.
Vous vous demandez peut-être : « si le fichier de zone réside sur le serveur de noms, pourquoi doit-il se référencer lui-même ? ». Une partie de ce qui rend le DNS si efficace est ses multiples niveaux de mise en cache. Une raison de définir les serveurs de noms dans le fichier de zone est que le fichier de zone peut en fait être servi à partir d’une copie mise en cache sur un autre serveur de noms. Il existe d’autres raisons pour lesquelles il est nécessaire de définir les serveurs de noms sur le serveur de noms lui-même, mais nous n’aborderons pas cela ici.
Tout comme les enregistrements MX, ceux-ci sont des paramètres globaux de la zone, donc ils ne prennent pas non plus d’hôtes. En général, ils ressemblent à ceci :
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Vous devriez avoir au moins deux serveurs de noms définis dans chaque fichier de zone afin de fonctionner correctement en cas de problème avec un serveur. La plupart des logiciels serveurs DNS considèrent un fichier de zone comme invalide s’il n’y a qu’un seul serveur de noms.
Comme toujours, incluez le mappage pour les hôtes avec des enregistrements A ou AAAA :
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
Il existe quelques autres types d’enregistrements que vous pouvez utiliser, mais ce sont probablement les types les plus courants que vous rencontrerez.
Enregistrements PTR
Les enregistrements PTR sont utilisés pour définir un nom associé à une adresse IP. Les enregistrements PTR sont l’inverse d’un enregistrement A ou AAAA. Les enregistrements PTR sont uniques en ce sens qu’ils commencent à la racine .arpa et sont délégués aux propriétaires des adresses IP. Les Registres Internet Régionaux (RIR) gèrent la délégation des adresses IP aux organisations et fournisseurs de services. Les Registres Internet Régionaux comprennent APNIC, ARIN, RIPE NCC, LACNIC et AFRINIC.
Voici un exemple d’enregistrement PTR pour 111.222.333.444 :
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Cet exemple d’enregistrement PTR pour une adresse IPv6 montre le format nibble de la réversibilité du serveur DNS IPv6 de Google, 2001:4860:4860::8888.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
L’outil en ligne de commande dig avec le drapeau -x peut être utilisé pour rechercher le nom DNS inversé d’une adresse IP.
Voici un exemple de commande dig. Le +short est ajouté pour réduire la sortie au nom DNS inversé.
La sortie de la commande dig ci-dessus sera le nom de domaine dans l’enregistrement PTR pour l’adresse IP :
google-public-dns-b.google.com.
Les serveurs sur Internet utilisent les enregistrements PTR pour placer les noms de domaine dans les entrées de journal, prendre des décisions informées sur le traitement du spam et afficher des détails faciles à lire sur d’autres appareils.
La plupart des serveurs de messagerie utilisés couramment rechercheront l’enregistrement PTR d’une adresse IP à partir de laquelle ils reçoivent un e-mail. Si l’adresse IP source n’a pas d’enregistrement PTR associé, les e-mails envoyés peuvent être traités comme du spam et rejetés. Il n’est pas important que le FQDN dans le PTR corresponde au nom de domaine de l’e-mail envoyé. Ce qui est important, c’est qu’il existe un enregistrement PTR valide avec un enregistrement A correspondant et correspondant.
Normalement, les routeurs réseau sur Internet se voient attribuer des enregistrements PTR correspondant à leur emplacement physique. Par exemple, vous pouvez voir des références à « NYC » ou « CHI » pour un routeur à New York ou à Chicago. Cela est utile lors de l’exécution d’une traceroute ou MTR et de l’examen du chemin emprunté par le trafic Internet.
La plupart des fournisseurs proposant des serveurs dédiés ou des services VPS donneront aux clients la possibilité de définir un enregistrement PTR pour leur adresse IP. DigitalOcean attribuera automatiquement l’enregistrement PTR de tout Droplet lorsque le Droplet est nommé avec un nom de domaine. Le nom du Droplet est attribué lors de sa création et peut être modifié ultérieurement en utilisant la page des paramètres du panneau de contrôle du Droplet.
Note: Il est important que le FQDN dans l’enregistrement PTR ait un enregistrement A correspondant et correspondant. Exemple : 111.222.333.444 a un PTR de serveur.example.com et serveur.example.com est un enregistrement A qui pointe vers 111.222.333.444.
Enregistrements CAA
Les enregistrements CAA sont utilisés pour spécifier quelles autorités de certification (CA) sont autorisées à délivrer des certificats SSL/TLS pour votre domaine. Depuis le 8 septembre 2017, toutes les CAs sont tenues de vérifier ces enregistrements avant de délivrer un certificat. Si aucun enregistrement n’est présent, n’importe quelle CA peut délivrer un certificat. Sinon, seules les CAs spécifiées peuvent délivrer des certificats. Les enregistrements CAA peuvent être appliqués à des hôtes individuels ou à des domaines entiers.
Un exemple d’enregistrement CAA suit:
example.com. IN CAA 0 issue "letsencrypt.org"
L’hôte, IN, et le type d’enregistrement (CAA) sont des champs DNS courants. Les informations spécifiques aux CAA ci-dessus sont la partie 0 issue "letsencrypt.org". Elle est composée de trois parties: les indicateurs (0), les balises (issue), et les valeurs ("letsencrypt.org").
- Les indicateurssont un entier qui indique comment une CA doit gérer les balises qu’elle ne comprend pas. Si l’indicateur est
0, l’enregistrement sera ignoré. Si1, la CA doit refuser de délivrer le certificat. - Les balisessont des chaînes de caractères qui indiquent le but d’un enregistrement CAA. Actuellement, elles peuvent être
issuepour autoriser une CA à créer des certificats pour un nom d’hôte spécifique,issuewildpour autoriser des certificats génériques, ouiodefpour définir une URL où les CAs peuvent signaler les violations de politique. - Les valeurs sont une chaîne associée à la balise du enregistrement. Pour
issueetissuewild, il s’agira généralement du domaine de l’AC à qui vous accordez la permission. Pouriodef, il peut s’agir de l’URL d’un formulaire de contact, ou d’un lienmailto:pour les retours par e-mail.
Vous pouvez utiliser dig pour récupérer les enregistrements CAA en utilisant les options suivantes :
Pour des informations plus détaillées sur les enregistrements CAA, vous pouvez lire le RFC 6844, ou notre tutoriel Comment créer et gérer les enregistrements CAA avec DigitalOcean DNS
Conclusion
Vous devriez maintenant avoir une assez bonne compréhension de la façon dont fonctionne le DNS. Bien que l’idée générale soit relativement facile à comprendre une fois que vous êtes familiarisé avec la stratégie, cela peut encore être difficile pour les administrateurs inexpérimentés à mettre en pratique.
Pour un aperçu, consultez Comment configurer les domaines dans le panneau de contrôle DigitalOcean.