Domain Name System (DNS) spiller en vigtig rolle på internettet.  Det konverterer kanoniske navne til ip-adresser og er afgørende for trafikrute på nettet.  DNS-opløsning er et stort emne, og det kan ikke dækkes fuldstændigt i denne artikel. I stedet vil jeg nævne de vigtigste trin for at gøre et websted live fra en server, hvor du har købt en hostingkonto.

DNS-opløsning

1. Du skal registrere et websted som nyt domæne.com, nyt domæne.org, nyt domæne.biz, newdomain.hosting osv. I dag er der en masse nye TLD-lignende .arbejde, .hosting osv. fra nogen af ​​domæneregistratorerne. De mest almindelige er som Godday.com, domæne.com, NameCheap.com, Bluehost.com
2. Når du først har købt domænenavnet fra ovenstående registrator, skal vi nu finde en hosting-konto (det kan enten være en delt hosting / forhandlerhosting eller en VPS / dedikeret server) . Hvis du har en delt / forhandlerkonto, vil de for det meste give os et par navneservere, der skal bruges til at pege domænet til deres servere. HVIS du køber en vps / dedikerede servere, er vi muligvis nødt til at opsætte serveren med DNS-server, som vi hovedsageligt bruger Navngivne eller Bindepakker til.
3. Hvis du selv bruger registratornavneservere, skal du oprette alle dns-poster manuelt i panelet. Hvis du bruger en cpanel / plesk delt hosting, vil de for det meste have alle dns-poster oprettet, mens du opretter kontoen, og du skal bare pege hosting-udbyderens navneservere ved registratorenden.
4. Når det er peget, kan det tage op til 24 - 72 timer at få ændringerne udbredt over hele Internettet.

Forståelse af DNS-poster

DNS-poster er indstillinger, der hjælper os med at pege et domæne, og det forskellige tjenester til de korrekte servere eller IP-adresse. Dns-poster fungerer som en instruktør som det domæne peger på den ip, at underdomænet peger på en anden ip osv.  Uden ordentlige DNS-poster bliver mennesker nødt til at huske IP-adressen, og at huske en ipaddress vil være en kedelig opgave, og det er, hvordan vigtigheden af ​​DNS kommer ind for at spille.

Vi behøver ikke at huske en IP-adresse, da det altid vil være et problem for mennesker at bruge IP-adresse til at gå til webstedet. Derfor registrerer vi domænenavnet og bruger dns for at få det peget korrekt på værtsserveren. Før DNS-servere eller -pakker blev oprettet, skal man indtaste IP-adressen i browseren og også huske den samme. Med introduktionen af ​​IPV6 er det bogstaveligt talt umuligt at huske IP-adressen, selv for dem der har den bedste hukommelseskapacitet.

Der er mere end 70 + dns-poster, og du kan læse nedenstående link for alle mulige DNS-poster og dens detaljer

https: // www.iana.org / tildelinger / dns-parametre / dns-parametre.xml

Jeg diskuterer nedenstående optegnelser, som er mest nødvendige for, at en lægmand får sit websted og sin e-mail til at strømme glat.

1. SOA Record
2. TTL-værdi
3. En post
4. AAAA Record
5. NS Record
6. MX-post
7. TXT Record
8. SPF Record
9. DKIM Record
10. DMARC Record
11. PTR Record
12. CNAME Record
13. SRV Record
14. RP Record
15. DNSKEY Records

1. SOA (START AF MYNDIGHEDEN) Record

SOA-plade er den vigtigste og alligevel ikke så populære plade. Det er et must-record for, at en DNS-zonefil fungerer og giver resultater til os. Denne særlige post vil have navnet på zonen, e-mail-adressen på den ansvarlige person, der håndterer domænes zonefil, aktuelt serienummer, primær- eller hovednavneserver for zonen og nogle tidselementer, der måles og vises i sekunder.

Nedenfor er en prøve SOA Record

domæne.com. 86400 I SOA ns1.domæne.com.   ejeremail.domæne.com.  (
2017100505; Serienummer
3600; opdatering
7200; prøv igen
1209600; udløber
86400)
Det nøjagtige format til dette er nedenstående
@ IN SOA primær-navn-server hostmaster-e-mail (
serienummer
time-to-refresh
time-to-retry
time-to-expire
minimum-TTL)

Primær-navneserver: Det viser navneserveren, der indeholder de originale dns-poster.

Hostmaster-e-mail: E-mail-adresse til ejeren, der er ansvarlig for domænet.  En periode ".”Bruges til at erstatte et @ symbol. For e-mail-adresse, der har en “.”Allerede i det vil blive undsluppet med et“ / ”.

Serienummer : Det er versionsnummeret på zonen, og det fortsætter med at stige med hver opdatering af zonefilen.

Tid til opdatering: Denne værdi viser tid til at vente på kontrol af en opdatering af serienummeret. Dette er hovedsageligt nødvendigt, når du har en sekundær dns- eller dns-klynge, der skal kontrollere, om der er en opdatering på masterfilen og skal kopieres den seneste til de andre servere i klyngen. Gælder kun dem, der har sekundær dns eller klyngeopsætning.

Tid til at prøve igen: Det bestemmer, hvor længe en navneserver skal vente på at prøve igen opdateringen, hvis det sidste forsøg mislykkedes.Gælder kun dem, der har sekundær dns eller klyngeopsætning.

Tid til udløb: det bestemmer, hvor længe vi skal vente, før vi betragter dataene fra de sekundære eller andre klyngenavnservere som ugyldige og holder op med at svare på forespørgslerne for den respektive zone.

minimum-TTL: Hvor længe skal en nameserver eller resolvers cache et negativt svar.

2. TTL-værdi (Time to Live)

TTL-værdi er den tid i sekunder, hvor en dns-poster caches af en ekstern dns-server eller navneserver, og derefter skal den opdatere cachen og have den nyeste værdi . Den væsentligste betydning af dette er, mens du planlægger en migration, og har brug for dns-ændringer uden dns-down-tid. Ændringer af navneservere kan altid medføre nedetid, da vi ikke har kontrol over dem. Så før migrering ændrer vi normalt TTL-værdien til 300 sek 1 - 2 dage før sig selv, så efter migrering ændrer vi navneserver-ip'erne i registratorenden og ændrer også IP'erne for alle zonefiler i den gamle server til nye ip'er så det begynder at løse til ny server i begge tilfælde, dvs. hvis dns kommer til den gamle server, så vil det pege domænet fra den server til den nye server, og hvis de nyligt opdaterede navneservere tages, så begynder det også at indlæse fra ny server.

Hvis der ikke er nævnt nogen ttl-værdi, vil dette være den vigtigste standardværdi for alle dns-poster, medmindre vi har en anden værdi specificeret i records.

Prøveindtastning
$ TTL 14400

3. En post

En post er også kendt som Address Records eller Host Records. Dette bruges hovedsageligt til at pege domænet / underdomæne osv. Til serverens ip-adresse. En post løser kun en ip-adresse, og der er ingen andre argumenter / variabler i A-posten. A-poster bruges kun til at pege på en IPV4-adresse.

Prøve En post er nedenstående
domæne.com.   14400 I A 192.168.1.1

Vi kan også bruge en wildcard-dns-post, der indlæser alle underdomæner til en ip

*.domæne.com 14400 IN A 192.168.1.1

4. AAAA Record

AAAA-post er den samme som ovennævnte Record, og formålet med og brugen af ​​denne record er det samme. Eneste forskel er, at dette bruges til at pege domænet til en IPV6 IP, og hvis domænet også har en IPv6-version, så er vi nødt til at have denne A-post så godt peget .

Eksempel på AAAA-post er nedenstående

domæne.com 14400 IN AAAA 0133: 4237: 89bc: cddf: 0123: 4267: 89ab: cddf

5. NS (navneserver) -post

Den ideelle situation vil være, at både Nameserver på registrar-niveau og dns-zonefilen er den samme, og uoverensstemmende ns-poster kan forårsage nogle problemer med nogle internetudbydere, men normalt er denne mismatch ikke et problem. Så primære navneserverposter skal være der i både registrator- og dns-zonefilen på serveren, som er nævnt i registratoren.

Prøveindtastning
domæne.com.   86400 IN NS ns1.hoveddomæne.com.
domæne.com.   86400 IN NS ns2.hoveddomæne.com.

Når du har navneserverne til det samme domæne, skal du sørge for at tilføje A-poster for disse navneservere .I ovenstående eksempel bruger den en anden registerd navneserver som ns1.hoveddomæne.com. Men hvis du ønsker at bruge ns1.domæne.com selv som navneserver i registrator og server, skal du opsætte HOST-poster i registar (som er GLUE Record) og også tilføje nedenstående A-poster

ns1 14400 IN A 192.168.1.1
ns2 14400 IN A 192.168.1.1

6. MX (Mail Exchange) Record

Dette er en anden vigtig dns-post, der bestemmer skæbnen for dine indgående mails til et domæne. Når nogen sender en mail til en e-mail-konto under et domæne, sender fjernserveren mails til den server, der er nævnt i MX-posterne, og det til den laveste prioritetsværdi, der faktisk har den højeste prioritet

Eksempel på MX-poster

domæne.com 14400 IN MX 10 mail_1.domæne.com
domæne.com 14400 IN MX 20 mail_2.domæne.com
domæne.com 14400 IN MX 30 mail_3.domæne.com

I dette eksempel, hvis mail_1.domæne.com er nede, vil mail blive leveret til mail_2.domæne.com. Hvis mail_2.eksempel.com er også nede, mail vil blive leveret til mail_3.domæne.com.Dette bruges hovedsageligt når du har tilføjet domæne i flere servere og har mail konfigureret i dem. Men disse mails spredes til disse servere, og du skal muligvis kontrollere dem manuelt.

Hvis du bruger MX-poster med det samme domænenavn, skal du tilføje korrekte dns A-poster. Ligesom nedenstående . Men hvis du bruger google apps, outlook osv., Er det ikke nødvendigt at tilføje yderligere A-post for dem, da du ikke har kontrol over dem, og de skal tilføjes af disse udbydere.

mail_1 14400 IN A 192.168.1.1
mail_2 14400 IN A 192.168.1.2
mail_3 14400 IN A 192.168.1.3

7. TXT (tekst) -optagelse

En TXT-post eller tekstoptagelse har faktisk ingen rolle for domænes funktionalitet, og den bruges normalt til at vise nogle oplysninger eller bruges til nogle verifikationer, som når du tilmelder dig med google apps eller Outlook Mail-tjenesten, så beder de dig om at tilføje en TXT-post, som de beder om (en unik kode), så de kan verificere domæneejerskabet.  SPF / DKIM-poster er også baseret på TXT, men de har en funktionalitet at udføre. Disse kan også bruges som en mulighed for at godkende dit ejerskab, mens du også tilføjer til google webmasterkonto og andre google relaterede tjenester.

Nedenfor er et eksempel på en dns-post til Google-verifikation

domæne.com. 300 IN TXT google-site-verification = gBmnBtGTIz_esMKJBKT-PxLH50M

8. SPF (Sender Policy Framework) Record

SPF-post er grundlæggende en TXT-post, der normalt udgiver alle de udpegede mailservere til et domæne eller underdomæne. Hovedanvendelsen af ​​denne post er at bevise legitimiteten af ​​mails og forhindre falske mails. En destinations-mailserver kan afvise mails, hvis de ikke er fra de registrerede eller nævnte mailservere baseret på denne post.

Prøveindtastning
domæne.com. IN TXT "v = spf1 + a + mx + ip4: 192.168.1.5-alle "

Dette siger, at dette domæne kun sender legitime mails fra A-record, MX-record-servere og også fra ip 192.168.1.5 og alle andre kan afvises . Med ovenstående SPF-post vil den receving-server kontrollere alle servere og ipaddress, som er nævnt i SPF. Hvis ip-adresse matcher, vil kontrollen blive bestået, og hvis ikke, mislykkes den hårdt (meddelelsen afvises automatisk), og hvis vi bruger “~ all”, hvilket er en soft fail, som er meddelelsen, markeres som FAIL, men vil ikke blive afvist.

Du kan henvise mere sytanx fra dette link.

9. DKIM (DomainKeys Identified Mail) -post

Dette er også en TXT-post, som også er en e-mail-godkendelsesprotokol, som er lidt mere kompliceret end SPF. Denne post oprettes for et underdomæne, der har en unik vælger til nøglen og derefter vil have en “.”Ved at tilføje en sådan post vil den tilføje en digital signatur til overskrifterne på e-mail-beskeden. Denne signatur valideres ved hjælp af den offentliggjorte offentlige nøgle fra DKIM-posten. Dette er lidt kompliceret, og hvis du er i cpanel, viser de en mulighed for let at få dette gjort ved hjælp af et klik aktiveringsmulighed.

Prøveindtastning
Standard._domænetast 14400 IN TXT "v = DKIM1; k = rsa;
p = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmDb9e2q41oLc0ZDtSNo2Ik4khVMUMkv98N1Y0
FehUCcFUIUIUIUIUIuiuicfhfarvetrytrryuytytfyfyfytrytrytrtyrytrytrytrytrytdyBQ3XatuaEj
qGR0zfaY6RSU ++ gqGF8ZRpjJd + O3AcqRZT4ZT8d7Uhye6Ctgcv3kQEd5I2dTSpodIzWey8reysHJMdCvulRJYdP "
UWj5PrHfkwY7ec0ZNggTOpmlByXIPRx0Q / oBS9TLlAs785XJMNWjubyyjC6V5JUQ + tRyhwa28TWM / l6 / EIcYNBZE
fWx8oHQsBFLT0dNsRhq9ExX0UDMmbddD0zWoKtx + Wb7ItG0HPPVqne8jWkeXQIDAQAB \;

10. DMARC Record

DMARC-post fungerer kun, hvis der er korrekte SPF- og SKIM-poster. Det er en politik for dets mailgodkendelsesproces, og hvordan den modtagende server skal håndtere mailen, hvis dette overtræder politikken.  Når en indgående mail kommer i fjernserveren, vil den spørge efter sin DMARC-post og sørge for, at de spørger nedenstående spørgsmål

> Er de indgående mails DKIM-signaturen korrekt ?
> Kom meddelelsen fra et autoriseret ip / server-værtsnavn som nævnt i SPF-posten.
> Uanset om overskriften på de indgående mails har præoperatorjustering i henhold til RFC 5322.

Prøveindtastning

_dmarc.domæne.com. IN TXT "v = DMARC1 \; p = none \; rua = mailto: [email protected] \;
ruf = mailto: [e-mailbeskyttet] \; pct = 100 "

_dmarc.domæne.com: Underdomæne, der er konfigureret til godkendelse af DMARC Alone.

v = DMARC1: Dmarc-version i brug.

p = ingen: nævner om den foretrukne behandling af politikken

rua =mailto: [email protected] : Aggregrate rapporter sendes til denne

ruf =mailto: [email protected] : Foreincsic-rapporter skal sendes til denne e-mail-konto

pct = 100: dette er den procentdel af mails, som ejeren ønsker at kontrollere posten og bruge til politikopdateringer

DMARC / SPF / DKIM er alt sammen nødvendigt for en korrekt godkendelse af posttjenester

11. PTR (pointer) -optagelse

PTR-poster er også kendt som Reverse DNS til ip. PTR-poster er normalt opsat på hostingudbyder- eller serverudbyderniveau. PTR-poster hjælper os med at matche en ip-adresse til et domæne eller et underdomæne (normalt til et FQDN fuldt kvalificeret domænenavn), som hjælper med at fungere de omvendte dns-forespørgsler til at fungere korrekt.

Så som en forudsætning for at indstille omvendte dns til en ip, nu om dage beder hosting- / serverudbydere først om at oprette en post for domænet / underdomænet til den IP, og når det er gjort, vil datacenter opsætte RDNS (Reverse DNS optage).

12.CNAME (Canonical Name) Record

CNAME-post hjælper med at pege et domæne eller underdomæne til et andet domæne eller underdomæne.

Prøveindtastning:
nyt domæne.com 14400 I CNAME-domæne.com.
mail 14400 I CNAME-mail.domæne.com.

Eksempel 1 peger på det nye domæne.com til domæne.com hvor som det andet eksempel peger på mail.nyt domæne.com til mail.domæne.com.  Med dette registreres, når en anmodning kommer til nyt domæne.com, den finder en CNAME-post til domænet.com. Derefter starter det et nyt opslag efter domæne.com og det sender anmodningen til domænet.com og det samme er også tilfældet med den anden plade.

13.SRV (Service) Record

SRV-post hjælper os med at pege på en bestemt tjeneste, der kører på dit domæne eller underdomæne til et måldomæne. Dette hjælper os med at dirigere trafik for bestemte tjenester som Chat-server eller messaging-tjenester til en anden server.

Prøveindgang:

_sipfederationtls._tcp.  3600 IN SRV 100 1 5061 sipfed.online.lync.com.
_service._protokol.eksempel.com 3600 IN SRV 10 0 5060 service.eksempel.com
_service._proto.navn. TTL klasse SRV prioritetsmål for havneport.

Service : Tjenesternes navn skal startes med en understregning “_” og efterfølges af et “.”-Tjeneste kunne være enhver ting som _chat, _xmpp, _sipfederationtls (som bruges til Microsoft Exchange-servere) osv.

Protokol:Protokollens navn skal også begynde med en understregning og derefter et “.”I dette tilfælde er det“ _tcp.”Og det fortæller os, at det er en TCP-protokol, der er i brug.

Navn: Navn eller domænenavn er det domæne, der modtager den oprindelige trafik for denne tjeneste.

Prioritet : Det er det første nummer, der er nævnt i ovenstående eksempler (henholdsvis 100 og 10), hjælper dig med at indstille prioriteten for målserveren, og lavere antal betyder højere prioritet. Dette svarer til MX-postprioritet og fungerer på samme måde, da vi kan konfigurere en anden post, så de også falder tilbage med en anden prioritet.

Vægt : Hvis vi opretter lignende poster med samme prioritet, vil den afgørende faktor have denne særlige værdi. Vægt er henholdsvis 1 og 0 i ovenstående eksempler.

Havn : dette viser TCP- eller UDP-porten, som tjenesten kører på.

Mål : dette er det mål underdomæne eller domæne, som denne tjeneste omdirigeres til, og det skal have en gyldig A / AAAA-post for at få denne trafik omdirigeret til der.

14. RP (ansvarlig person) Record

Dette er normalt ikke nødvendigt nu om dage, da der er en e-mail-adresse tilknyttet SOA Record. Men hvis ethvert domæne specifikt har brug for at nævne bortset fra standard-SOA-post-e-mail-kontoen, kan vi tilføje en RP-post.

15. DNSKEY Record

DNSkey-post indeholder en offentlig nøgle, der vil blive brugt af resolverne til at verificere dnssec-signaturer.

Prøveindtastning

domæne.com. 300 I DNSKEY 257 3 5 Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPO
ipoEUofZcndFN2aVd ==
Navn ttl klasse RRtype flags_filed Protocol Algorithm public_key

Navn: det er normalt domænenavnet eller værtsnavnet

IN: Repræsenter postklassen, og standard er IN (hvilket betyder internet)

Optagetype: posttype er typen af ​​posten, og i dette tilfælde vil det være DNSKEY

Flag: Indsendte flag er i et kabelformat, der er en 2 byte lang karakter. Mulige værdier er 0, 256 og 257. Hvis værdien er 256, betyder det, at dnskey-post holder ZSK (Zone-signering nøgle) betalt, og hvis værdien er 257, så indeholder den KSK (key signering nøglekomponent. Kort sagt indeholder denne fielf et ODD-nummer, når det har et KSK-nøglepar.

Protokol: Dette har altid en værdi på 3 for DNSSEC.

Offentlig nøgle: offentlig nøgle er nøgledataene, og i dette tilfælde er det “Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd ==”

Algoritme:  Hjælper os med at identificere public_keys ved hjælp af forskellige algoritmer, og nedenfor er de mest anvendte

• 1 = RSA / MD5
• 2 = Diffie-Hellman (Dette understøttes ikke af BIND)
• 3 = DSA
• 4 = Reserveret
• 5 = RSA / SHA1
• 6 = DSA / SHA1 / NSEC3
• 7 = RSA / SHA1 / NSEC3
• 8 = RSA / SHA-256
• 10 = RSA / SHA-512

Konklusion

Jeg håber, at dette virkelig hjælper jer alle med at forstå DNS ​​og sikre, at din hosting er konfigureret korrekt.