Le système de noms de domaine (DNS) joue un rôle important dans Internet. Il convertit les noms canoniques en adresses IP et est vital dans le routage de la circulation sur le net. La résolution DNS est un vaste sujet et qui ne pourra pas être complètement couvert dans cet article. Au lieu de cela, je mentionnerai les étapes les plus importantes pour rendre un site Web en direct à partir d'un serveur où vous avez acheté un compte d'hébergement.

Résolution DNS

1. Vous devez enregistrer un site Web comme Newdomain.com, newdomain.org, nouvelledomaine.biz, nouvelle.hébergement, etc. De nos jours, il y a beaucoup de nouveaux TLD comme .travail, .hébergement etc. de l'un des registraires du domaine. Les plus courants sont comme Godday.com, domaine.com, namecheap.com, bluehost.com
2. Une fois que vous avez acheté le nom de domaine dans le registraire ci-dessus, nous devons maintenant trouver un compte d'hébergement (soit il peut s'agir d'un hébergement d'hébergement / revendeur partagé ou d'un serveur VPS / dédié) . Si vous avez un compte partagé / revendeur, alors il nous fournira principalement une paire de serveurs de noms qui devraient être utilisés pour pointer le domaine vers leurs serveurs. Si vous achetez des serveurs VPS / dédiés, nous devrons peut-être configurer le serveur avec le serveur DNS pour lequel nous utilisons principalement des packages nommés ou liés.
3. Si vous utilisez les serveurs de noms d'enregistrement lui-même, vous devez créer tous les enregistrements DNS manuellement dans ce panneau. Si vous utilisez un hébergement partagé CPanel / Plesk, ils auront principalement tous les enregistrements DNS créés lors de la création du compte et il vous suffit de pointer les serveurs de noms du fournisseur d'hébergement à l'extrémité du registraire.
4. Une fois pointé, il peut prendre jusqu'à 24 à 72 heures pour que les modifications se propagent sur Internet.

Comprendre les enregistrements DNS

Les enregistrements DNS sont des paramètres qui nous aident à pointer un domaine et une variété informatique de services à ces serveurs appropriés ou adresses IP. Les enregistrements DNS agissent comme un instructeur comme ce domaine pointe vers cette IP, ce sous-domaine pointe vers une autre IP, etc. Sans enregistrements DNS appropriés, les humains devront se souvenir de l'adresse IP et se souvenir d'un iPaddress sera une tâche fastidieuse et c'est ainsi que l'importance du DNS arrive pour jouer.

Nous n'avons pas à nous souvenir d'une adresse IP car ce sera toujours un problème pour les humains d'utiliser l'adresse IP pour aller sur le site Web. C'est pourquoi nous enregistrons le nom de domaine et utilisons DNS pour le faire pointer correctement vers le serveur d'hébergement. Avant la création de serveurs ou de packages DNS, il faudra taper l'adresse IP dans le navigateur et devoir se souvenir de la même chose. Avec l'introduction de l'IPv6, il est littéralement impossible de se souvenir de l'adresse IP même pour ceux qui ont la meilleure capacité de mémoire.

Il y a plus de 70 enregistrements DNS et vous pouvez lire le lien ci-dessous pour tous les enregistrements DNS possibles et ses détails

https: // www.iana.org / affectations / dns-paramètres / dns-paramètres.xml

Je discute des enregistrements ci-dessous qui sont les plus nécessaires à un profane pour que son site héberge et le flux de courrier électronique en douceur.

1. Record de SOA
2. Valeur TTL
3. Un enregistrement
4. Record AAAA
5. NS Record
6. Record MX
7. Record TXT
8. Record SPF
9. DKIM Record
10. Record DMARC
11. PTR Record
12. CNAME Record
13. Enregistrement SRV
14. Dossier RP
15. DNSKEY Records

1. SOA (début de l'autorité) Record

SOA Record est le record le plus important et pourtant pas si populaire. C'est un record incontournable pour qu'un fichier de zone DNS fonctionne et nous donne des résultats. Cet enregistrement particulier aura le nom de la zone, l'adresse e-mail de la personne responsable gantant le fichier de zone du domaine, le numéro de série actuel, le serveur de noms principal ou principal pour la zone et quelques éléments de temps qui sont mesurés et affichés en quelques secondes.

Ci-dessous est un échantillon d'enregistrement SOA

domaine.com. 86400 dans SOA NS1.domaine.com. propriétaire.domaine.com. (
2017100505; numéro de série
3600; actualiser
7200; réessayer
1209600; expirer
86400)
Le format exact pour cela est ci-dessous
@ Dans SOA primaire-nom-serveur hostmaster-email (
numéro de série
Temps-to-Rafresh
Temps-to-drôle
temps à expirer
minimum-ttl)

Nom-serveur principal: Il montre le serveur de nom qui contient les enregistrements DNS d'origine.

Hostmaster-email: Adresse e-mail du propriétaire responsable du domaine. Une période "."Sera utilisé pour remplacer un symbole @. Pour l'adresse e-mail qui a un «."Déjà là-dedans sera échappé avec un" / ".

Numéro de série : C'est le numéro de version de la zone et il continuera à augmenter avec chaque mise à jour du fichier de zone.

Temps de rafraîchissement: Cette valeur montre le temps d'attendre pour vérifier une mise à jour du numéro de série. Ceci est principalement nécessaire lorsque vous avez un cluster DNS ou DNS secondaire qui doit vérifier une mise à jour sur le fichier maître et doit être copié le dernier des autres serveurs en cluster. S'applique uniquement à ceux qui ont une configuration DNS ou de cluster secondaire.

Temps de rétraction: Il détermine combien de temps un serveur de noms devrait attendre pour réessayer le rafraîchissement si la dernière tentative a échoué.S'applique uniquement à ceux qui ont une configuration DNS ou de cluster secondaire.

Temps pour expirer: Il détermine combien de temps devons-nous avoir besoin d'attendre avant de considérer les données du secondaire ou d'autres serveurs de noms de cluster invalides et arrêtez de répondre aux requêtes de la zone respective.

minimum-ttl: Combien de temps un serveur de nom ou des résolveurs doit-il mettre en cache une réponse négative.

2. Valeur TTL (Time To Live)

La valeur TTL est le temps en secondes selon lesquelles un DNS enregistre sera mis en cache par un serveur DNS ou un serveur de nom . L'importance principale est pendant que vous planifiez une migration et que vous avez besoin de modifications du DNS sans aucun temps d'arrêt DNS. Les modifications aux serveurs de noms peuvent toujours provoquer des temps d'arrêt car nous n'avons pas de contrôle sur ceux. Donc, avant la migration, nous modifions normalement la valeur TTL à 300 sec 1 à 2 jours avant lui-même afin qu'après la migration, nous modifierons les IP de Namesserver dans la fin du registraire et modifiera également les IP de tous les fichiers de zone dans Old Server vers les nouvelles IP de IP afin qu'il commence à résoudre à un nouveau serveur dans les deux cas, c'est-à-dire que si le DNS arrive sur un ancien serveur, il indiquera le domaine de ce serveur vers un nouveau serveur et si les serveurs de noms nouvellement mis à jour sont pris, alors il commencera également à se charger à partir de nouveau serveur.

Si aucune valeur TTL n'est mentionnée, ce sera la principale valeur par défaut pour tous les enregistrements DNS, sauf si nous avons une autre valeur spécifiée dans les enregistrements.

Échantillon
$ TTL 14400

3. Un enregistrement

Un enregistrement est également connu sous le nom d'enregistrements d'adresses ou d'enregistrements d'hôte. Ceci est principalement utilisé pour pointer le domaine / sous-domaine, etc. à l'adresse IP du serveur. Un enregistrement ne se résout qu'à une adresse IP et aucun autre argument / variables n'est là dans l'enregistrement A. Les enregistrements sont utilisés uniquement pour pointer une adresse IPv4.

L'échantillon d'un enregistrement est celui ci-dessous
domaine.com. 14400 dans un 192.168.1.1

Nous pouvons également utiliser un enregistrement DNS générique qui chargera tous les sous-domaines en une seule IP

*.domaine.com 14400 dans un 192.168.1.1

4. Record AAAA

L'enregistrement AAAA est le même que l'enregistrement ci-dessus et le but et l'utilisation de cet enregistrement est le même. La seule différence est que cela est utilisé pour pointer le domaine vers une IP IPv6 et si le domaine a également une version IPv6, nous devons également avoir un enregistrement .

L'échantillon record AAAA est ce qui est ci-dessous

domaine.com 14400 dans AAAA 0133: 4237: 89BC: CDDF: 0123: 4267: 89AB: CDDF

5. NS (serveur de noms) Enregistrement

La situation idéale sera à la fois le serveur de nom. Les enregistrements de NameServer Priminal devraient donc être là dans le fichier Registrar et DNS Zone dans le serveur qui est mentionné dans le registraire.

Échantillon
domaine.com. 86400 dans NS NS1.se maintienne.com.
domaine.com. 86400 dans NS NS2.se maintienne.com.

Lorsque vous avez les serveurs de noms pour le même domaine, assurez-vous d'ajouter des enregistrements pour ces serveurs de noms .Dans l'exemple ci-dessus, il utilise un autre serveur de noms Registerd comme NS1.se maintienne.com. Mais si vous souhaitez utiliser NS1.domaine.com lui-même en tant que nom de nom dans le registraire et le serveur, vous devez configurer des enregistrements hôtes dans le Registar (qui est l'enregistrement de colle) et vous devez également ajouter les enregistrements ci-dessous

NS1 14400 dans un 192.168.1.1
NS2 14400 dans un 192.168.1.1

6. Enregistrement MX (Mail Exchange)

Il s'agit d'un autre enregistrement DNS important qui détermine le sort de vos courriers entrants à un domaine. Lorsque quelqu'un envoie un courrier à un compte de messagerie dans un domaine, le serveur distant enverra des courriels au serveur qui est mentionné dans les enregistrements MX et celui avec la valeur la plus basse en fait qui a en fait la priorité la plus élevée

Exemples de registres MX

domaine.com 14400 dans MX 10 Mail_1.domaine.com
domaine.com 14400 dans MX 20 Mail_2.domaine.com
domaine.com 14400 dans MX 30 Mail_3.domaine.com

Dans cet exemple, si Mail_1.domaine.com est en panne, le courrier sera livré à Mail_2.domaine.com. Si Mail_2.exemple.com est également en panne, le courrier sera livré à Mail_3.domaine.com.Ceci est principalement utilisé lorsque vous avez un domaine ajouté dans plusieurs serveurs et que le courrier est configuré dans ceux. Mais ces courriers seront dispersés sur ces serveurs et vous devrez peut-être vérifier manuellement ceux.

Si vous utilisez les enregistrements MX ayant le même nom de domaine, vous devez ajouter des enregistrements DNS appropriés. Comme ce qui est ci-dessous . Mais si vous utilisez Google Apps, Outlook, etc., alors pas besoin d'ajouter un enregistrement supplémentaire pour ceux-ci car vous n'avez pas le contrôle sur ceux-ci et ceux qui devraient être ajoutés par ces fournisseurs.

Mail_1 14400 dans un 192.168.1.1
Mail_2 14400 dans un 192.168.1.2
Mail_3 14400 dans un 192.168.1.3

7. Enregistrement txt (texte)

Un enregistrement TXT ou un enregistrement de texte n'a en fait aucun rôle sur les fonctionnalités des domaines et il est généralement utilisé pour afficher des informations ou utilisé pour certaines vérifications comme lorsque vous vous inscrivez avec Google Apps ou Outlook Mail Service, puis ils vous demanderont d'ajouter un Record TXT qu'ils demandent (un code unique) afin qu'ils puissent vérifier la propriété du domaine. Les enregistrements SPF / DKIM sont également basés sur TXT mais ils ont une fonctionnalité pour effectuer. Ceux-ci peuvent également être utilisés comme une option pour authentifier votre propriété tout en ajoutant au compte Webmaster Google et à d'autres services liés à Google également.

Vous trouverez ci-dessous un exemple d'entrée DNS pour la vérification Google

domaine.com. 300 dans txt google-site-verification = gbmnbtgtiz_esmkjbkt-pxlh50m

8. Enregistrement SPF (Sender Policy Framework)

L'enregistrement SPF est essentiellement un enregistrement TXT, qui publie normalement tous les serveurs de courrier désignés pour un domaine ou un sous-domaine. L'utilisation principale de ce dossier est de prouver la légitimité des courriers et d'empêcher les courriers usurpés. Un serveur de messagerie de destination peut rejeter les courriers si ceux-ci ne sont pas des serveurs de courrier enregistrés ou mentionnés en fonction de cet enregistrement.

Échantillon
domaine.com. Dans txt "v = spf1 + a + mx + ip4: 192.168.1.5-tout "

Cela indique que ce domaine n'enverra des courriels légitimes uniquement à partir d'un enregistrement, des serveurs d'enregistrement MX, ainsi que de l'IP 192.168.1.5 Et tous les autres peuvent être rejetés . Avec l'enregistrement SPF ci-dessus, le serveur de réception vérifiera tous les serveurs et iPaddress qui sont mentionnés dans le SPF. Si l'adresse IP correspond, le chèque sera passé, et sinon, il échouera dur (le message sera rejeté automatiquement) et si nous utilisons «~ all» qui est un échec doux qui est le message sera marqué en échec mais ne sera pas rejeté.

Vous pouvez référer plus de sytanx à partir de ce lien.

9. DKIM (DomainKeys identifié le courrier)

Il s'agit également d'un enregistrement TXT qui est également un protocole d'authentification par e-mail qui est un peu plus compliqué que SPF. Ce record est créé pour un sous-domaine qui a un sélecteur unique pour la clé et aura ensuite un «."En ajoutant un tel enregistrement, il ajoutera une signature numérique aux en-têtes de l'e-mail. Cette signature est validée à l'aide de la clé publique publiée par le dossier DKIM. Ceci un peu compliqué et si vous êtes en cpanel, ils fournissent une option pour le faire facilement en utilisant une option d'activation de clic.

Échantillon
défaut._domainkey 14400 dans txt "v = dKim1; k = rsa;
p = miBijanbgkqhkig9w0baqefaaoCaq8amiibcgkcaqEamdb9e2q41olc0zdtsNo2ik4khvMumkv98n1y0
FehuccfuiuiuiuiiuiuiuicfhdyeytryUytyTfyfyfyTrytrytryrytrytryTdyBq3xatuaej
qgr0zfay6rsu ++ gqgf8zrpjjd + o3acqrzt4zt8d7uhye6ctgcv3kqed5i2dtspodizwey8reyshjmdcvulrjydp "
Uwj5prhfkwy7ec0znggtopmlByXiprx0q / Obs9tllas785xjmnwJUBYyjc6v5JUQ + TRYHWA28TWM / L6 / Eicynbze
fwx8ohqsbflt0dnsrhq9exx0udmmbddd0zwoktx + wb7itg0hppvqne8jwkexqidaqab \;

dix. Record DMARC

L'enregistrement DMARC ne fonctionne que s'il y a des enregistrements SPF et SKIM appropriés. Il s'agit d'une politique de son processus d'authentification par courrier et de la façon dont le serveur de réception doit gérer le courrier si cela viole la politique. Lorsqu'un courrier entrant est disponible dans le serveur distant, il interrogera pour son enregistrement DMARC et s'assurera de poser les questions ci-dessous

> Est les courriers entrants dkim qui sont les bons ?
> Le message provenait-il d'un nom d'hôte IP / serveur autorisé comme mentionné par l'enregistrement SPF.
> Si l'en-tête des courriers entrants a un alignement prpoper selon le RFC 5322.

Échantillon

_dmarc.domaine.com. Dans txt "v = dMarc1 \; p = Aucun \; rua = Mailto: DMARC-FROM @ Domain.com \;
RUF = Mailto: dmarc-to @ mydomain.com \; pct = 100 "

_dmarc.domaine.com: Sous-domaine qui est configuré pour l'authentification du DMARC seul.

V = DMARC1: Version DMARC utilisée.

p = aucun: mentionne le traitement préféré de la politique

rua =MailTo: DMARC-AGREGRATE @ DOMAIN.com : Les rapports Aggregrate sont envoyés à celui-ci

ruf =MailTo: DMARC-FORENSIC @ Domain.com : Les rapports ForeIncSic doivent être envoyés à ce compte de messagerie

PCT = 100: Il s'agit du pourcentage de courriers que le propriétaire souhaite que l'enregistrement vérifie et utilisé pour les mises à jour des politiques

DMARC / SPF / DKIM est tout nécessaire pour une authentification appropriée pour les services de courrier

11. PTR (pointeur) Enregistrement

Les enregistrements PTR sont également connus sous le nom de DNS inversé pour l'IP. Les enregistrements PTR sont normalement configurés au niveau du fournisseur d'hébergement ou du fournisseur de serveurs. Les enregistrements PTR nous aident à faire correspondre une adresse IP à un domaine ou à un sous-domaine (normalement à un nom de domaine FQDN entièrement qualifié) qui aidera à fonctionner les requêtes DNS inversées pour fonctionner correctement.

Ainsi, en tant que pré-requête pour définir les DNS inverses pour une IP, les fournisseurs d'hébergement / serveurs sont désormais de demander d'abord de configurer un enregistrement pour le domaine / sous-domaine à cette IP et une fois que cela sera fait, Data Center configurera le RDNS (DNS inversé enregistrer).

12.CNAME (nom canonique)

CNAME Record aide à pointer un domaine ou un sous-domaine vers un autre domaine ou sous-domaine.

Exemple d'entrée:
Nouvelle-femme.com 14400 dans le domaine CNAME.com.
Mail 14400 dans CNAME Mail.domaine.com.

Exemple 1, pointe la nouvelle femme.com au domaine.com où comme le deuxième exemple est de pointer du courrier.Nouvelle-femme.com pour envoyer.domaine.com. Avec ces enregistrements, lorsqu'une demande arrive à Newdomain.com, il trouvera un enregistrement CNAME au domaine.com. Après cela, il commencera une nouvelle recherche pour le domaine.com et il enverra la demande au domaine.com et même est le cas avec le deuxième record également.

13.Enregistrement SRV (service)

L'enregistrement SRV nous aide à pointer un service particulier qui s'exécute sur votre domaine ou sous-domaine vers un domaine cible. Cela nous aide à diriger le trafic pour des services particuliers tels que le serveur de chat ou les services de messagerie vers un serveur Anothr.

Exemple d'entrée:

_sipfederationtls._TCP. 3600 en SRV 100 1 5061 SIPFED.en ligne.lync.com.
_service._protocole.exemple.Com 3600 dans SRV 10 0 5060 Service.exemple.com
_service._proto.nom. TTL Classe SRV Priority Poind Port Target.

Service : Le nom des services doit être démarré avec un soulignement «_» et sera suivi d'un «.«Le service pourrait être n'importe quoi comme _Chat, _xMpp, _sipfederationtls (qui est utilisé pour les serveurs d'échange Microsoft) etc.

Protocole:Le nom du protocole devrait également commencer par un soulignement, puis un «."Dans ce cas, c'est" _TCP."Et il nous dit que c'est un protocole TCP qui est utilisé.

Nom : Le nom ou le nom de domaine est le domaine qui recevra le trafic d'origine pour ce service.

Priorité : C'est le premier numéro mentionné dans les exemples ci-dessus (100 et 10 respectivement) vous aide à définir la priorité du serveur cible et un nombre plus bas signifie une priorité plus élevée. Ceci est similaire à la priorité d'enregistrement MX et fonctionne de la même manière que nous pouvons également configurer un autre enregistrement en tant que rabais avec une autre priorité.

Lester : Si nous créons des enregistrements similaires avec la même priorité, le facteur décisif sera cette valeur particulière. Le poids est respectivement 1 et 0 dans les exemples ci-dessus.

Port : Cela montre le port TCP ou UDP sur lequel le service s'exécute.

Cible : Il s'agit du sous-domaine ou du domaine cible auquel ce service sera redirigé et il devrait avoir un dossier A / AAAA valide pour que ce trafic soit redirigé vers là.

14. RP (personne responsable) Record

Ce n'est normalement pas nécessaire maintenant quelques jours car il existe une adresse e-mail associée à l'enregistrement SOA. Mais si un domaine souhaite avoir spécifiquement besoin de mentionner en dehors du compte de messagerie SOA par défaut, alors nous pouvons ajouter un enregistrement RP.

15. DNSKEY Record

DNSKEY Record contient une clé publique qui sera utilisée par les Resolvers pour vérifier les signatures DNSSEC.

Échantillon

domaine.com. 300 dans Dnskey 257 3 5 Z10wdrihgjghiugiugkuoikhpouptyrsyrsyrdfytpopo
ipoeufzcndfn2avd ==
Nom TTL Classe RRTYPE FLAGS_FILED Protocole algorithme public_key

Nom : c'est le nom de domaine ou le nom d'hôte normalement

DANS : Représenter la classe d'enregistrement et la valeur par défaut est dans (ce qui signifie Internet)

Type d'enregistrement: Le type d'enregistrement est le type de l'enregistrement et dans ce cas, ce sera dnskey

Frappeurs: Les drapeaux déposés sont dans un format câblé qui est un caractère long de 2 octets. Les valeurs possibles sont 0, 256 et 257. Si la valeur est de 256, cela signifie que DNSKEY Record détient ZSK (clé de signature de zone) payé et si la valeur est 257, alors il contient KSK (KeyComponent de signature de clé. En bref, ce Fief contient un nombre impair lorsqu'il tient une paire de clés KSK.

Protocole: Cela a toujours une valeur de 3, pour DNSSEC.

Clé publique : La clé publique est les données clés et dans ce cas, c'est «Z10WDRIHGJGIUGIUGKUOIKHPUPTYRSYRRSYRDFYTPOPOIPOOFZCNDFN2AVD ==»

Algorithme: Nous aide à identifier public_keys en utilisant différents algorithmes et ci-dessous sont les plus utilisés

• 1 = RSA / MD5
• 2 = Diffie-Hellman (ce n'est pas pris en charge par Bind)
• 3 = DSA
• 4 = réservé
• 5 = RSA / SHA1
• 6 = DSA / SHA1 / NSEC3
• 7 = RSA / SHA1 / NSEC3
• 8 = RSA / SHA-256
• 10 = RSA / SHA-512

Conclusion

J'espère que cela vous aidera vraiment à comprendre le DNS et à vous assurer que votre hébergement est correctement configuré.