Domain Name System (DNS) spiller en viktig rolle på Internett. Den konverterer kanoniske navn til IP -adresser og er viktig i trafikkruting på nettet. DNS -oppløsning er et stort tema, og det vil ikke kunne dekkes fullstendig i denne artikkelen. I stedet vil jeg nevne de viktigste trinnene for å lage et nettsted live fra en server der du har kjøpt en hostingskonto.

DNS -oppløsning

1. Du må registrere et nettsted som Newdomain.com, newdomain.org, newdomain.Biz, Newdomain.hosting osv. I dag er det mange nye tld som .arbeid, .hosting osv. fra noen av domene -registrarene. Vanligste er som guddag.com, domene.com, namecheap.com, bluehost.com
2. Når du har kjøpt domenenavnet fra ovennevnte registrator, må vi nå finne en hostingkonto (enten kan det være en delt hosting/ forhandler hosting eller en VPS/ dedikert server) . Hvis du har en delt/forhandlerkonto, vil de stort sett gi oss et par navneservere som bør brukes til å peke domenet til serverne deres. Hvis du kjøper en VPS/dedikerte servere, kan det hende at vi må konfigurere serveren med DNS -server som vi hovedsakelig bruker navngitte eller binder pakker.
3. Hvis du bruker Registrar Name -servere selv, må du opprette alle DNS -poster manuelt i det panelet. Hvis du bruker en Cpanel / Plesk delt hosting, vil de mest ha alle DNS -poster opprettet mens du oppretter kontoen, og du trenger bare å peke navneserverne til hostingleverandøren på Registrar End.
4. Når det er pekt, kan det ta opptil 24 - 72 timer å få endringene forplantet over hele Internett.

Forstå DNS ​​-postene

DNS -poster er innstillinger som hjelper oss med å peke et domene og det utvalg av tjenester til de riktige serverne eller IP -adressen. DNS -poster fungerer som en instruktør som det domenet peker på den IP -en, at underdomenet peker på en annen IP osv. Uten riktig DNS -poster vil mennesker måtte huske IP -adressen og å huske en iPaddress vil være en kjedelig oppgaver og det er hvordan viktigheten av DNS kommer inn for å spille.

Vi trenger ikke å huske en IP -adresse, da det alltid vil være et problem for mennesker å bruke IP -adresse for å gå til nettstedet. Det er grunnen til at vi registrerer domenenavnet og bruker DNS for å få det riktig pekt på hostingserveren. Før DNS -servere eller pakker ble opprettet, må man skrive IP -adressen i nettleseren og må huske det samme også. Med introduksjonen av IPv6 er det bokstavelig talt umulig å huske IP -adressen selv for de som har den beste minnekapasiteten.

Det er mer enn 70 + DNS -poster, og du kan lese lenken nedenfor for alle mulige DNS -poster og dens detaljer

https: // www.Iana.org/oppgaver/DNS-parametere/DNS-parametere.XML

Jeg diskuterer postene nedenfor som er mest nødvendig for en lekmann for å få nettstedet hans vert og e -poststrøm jevnt.

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

1. SOA (Start of Authority) Record

SOA -plate er den viktigste og likevel ikke så populære platen. Det er et must å registrere for en DNS Zone -fil å fungere og gi resultater til oss. Denne spesielle posten vil ha navnet på sonen, e -postadressen til den ansvarlige personen som håndterer domenets sonefil, gjeldende serienummer, primær eller hovednameserver for sonen, og noen tidselementer som blir målt og vises i sekunder.

Nedenfor er en prøve SOA -post

domene.com. 86400 i SOA NS1.domene.com. OwnerEmail.domene.com. (
2017100505; serienummer
3600; oppdater
7200; prøv på nytt
1209600; utløper
86400)
Nøyaktig format for dette er nedenfor
@ I SOA primærnavn-server hostMaster-e-post (
serienummer
Time-to-Refresh
Time-to-Retry
Time-to-expire
Minimum-TTL)

Primærnavn-server: Den viser navneserveren som inneholder de originale DNS -postene.

Hostmaster-e-post: E -postadressen til eieren som er ansvarlig for domenet. En periode ".”Vil bli brukt og erstatte et @ symbol. For e -postadresse som har en ".”Allerede i det vil bli rømt med en“/”.

Serienummer : Det er versjonsnummeret til sonen, og det vil fortsette å øke med hver oppdatering av sonefilen.

Time-to-Refresh: Denne verdien viser tiden til å vente på å sjekke for en serienummeroppdatering. Dette er hovedsakelig nødvendig når du har en sekundær DNS eller DNS -klynge som må se etter en oppdatering på hovedfilen og må kopieres den siste til de andre serverne i klyngen. Gjelder bare de som har sekundær DNS eller klyngeoppsett.

Tid-til-retry: Det avgjør hvor lenge en navneserver skal vente på å prøve på nytt hvis det siste forsøket mislyktes.Gjelder bare de som har sekundær DNS eller klyngeoppsett.

Time-to-expire: Det avgjør hvor lenge vi trenger å vente før vi vurderer dataene fra sekundær- eller andre klynge -navneserver ugyldige og slutter å svare på spørsmålene for den respektive sonen.

Minimum-TTL: Hvor lenge skal en navneserver eller oppløsere cache en negativ respons.

2. Ttl (tid til å leve) verdi

TTL -verdien er tiden på sekunder at en DNS -poster vil bli bufret av en ekstern DNS -server eller navneserver, og etter det skal den oppdatere den cache og ha den nyeste verdien . Hoved viktigheten av dette er mens du planlegger en migrasjon, og trenger DNS -endringer uten noen DNS -tid. Endringer i navneservere kan alltid forårsake driftsstans, da vi ikke har kontroll på dem. Så før migrasjon endrer vi normalt TTL -verdien til 300 sek 1 - 2 dager før i seg selv, slik at vi etter migrasjon vil endre navneserveren IP -er i Registrar -enden og også vil endre IP -ene til alle sonefiler i Old Server til nye IP -er Slik at den vil begynne å løse seg til ny server i begge tilfeller, er det hvis DNS kommer til Old Server, så vil den peke domenet fra den serveren til ny server, og hvis de nylig oppdaterte navneserverne blir tatt, vil den også begynne å laste fra fra Ny server.

Hvis ingen TTL -verdi ikke er nevnt, vil dette være den viktigste standardverdien for alle DNS -poster med mindre vi har en annen verdi som er spesifisert i postene.

Prøveoppføring
$ TTL 14400

3. En rekord

En post er også kjent som adressejournaler eller vertsoppføringer. Dette brukes hovedsakelig til å peke domenet/underdomenet osv. Til serverens IP -adresse. En post løser bare en IP -adresse, og ingen andre argumenter /variabler er der i en post. En poster brukes bare til å peke på en IPv4 -adresse.

Eksempel på en post er den nedenfor
domene.com. 14400 i en 192.168.1.1

Vi kan også bruke en Wildcard DNS -post som vil laste alle underdomener til en IP

*.domene.com 14400 i en 192.168.1.1

4. AAAA Record

AAAA -posten er den samme som posten ovenfor og formål og bruk av denne posten er helt samme. Bare forskjell brukes dette til å peke domenet til en IPv6 IP, og hvis domenet også har en IPv6 -versjon, må vi også ha dette en plate også spiss .

Eksempel på AAAA -posten er nedenfor

domene.COM 14400 i AAAA 0133: 4237: 89BC: CDDF: 0123: 4267: 89AB: CDDF

5. NS (Name Server) Record

Ideell situasjon vil være både navneserver på registrarnivå og DNS Zone -filen er samme, og uoverensstemmede NS -poster kan forårsake noen problemer med noen ISP, men normalt er ikke misforhold som et problem. Så primære navneserveroppføringer bør være der i både registrator og DNS -sonefil på serveren som er nevnt i Registrar.

Prøveoppføring
domene.com. 86400 i NS NS1.Maindomain.com.
domene.com. 86400 i NS NS2.Maindomain.com.

Når du har navnene for det samme domenet, må du sørge for å legge til poster for disse navneserverne .I eksemplet ovenfor bruker det en annen registerdnameserver som NS1.Maindomain.com. Men hvis du ønsker å bruke NS1.domene.com seg selv som nameeserver i registrator og server, du må konfigurere vertsoppføringer i registaren (som også er limprotokollen) og må legge til de nedenfor postene også

NS1 14400 i en 192.168.1.1
NS2 14400 i en 192.168.1.1

6. MX (Mail Exchange) Record

Dette er en annen viktig DNS -post som bestemmer skjebnen til dine innkommende post til et domene. Når noen sender en e -post til en e -postkonto under et domene, vil den eksterne serveren sende e -post til serveren som er nevnt i MX -postene, og det med den laveste verdien i prioritet som faktisk har den høyeste prioritet

Eksempel på MX -poster

domene.com 14400 i mx 10 mail_1.domene.com
domene.com 14400 i mx 20 mail_2.domene.com
domene.com 14400 i mx 30 mail_3.domene.com

I dette eksemplet, hvis Mail_1.domene.com er nede, post vil bli levert til mail_2.domene.com. Hvis mail_2.eksempel.com er også nede, post vil bli levert til mail_3.domene.com.Dette brukes hovedsakelig når du har lagt til domene i flere servere og har e -post konfigurert i disse. Men disse postene vil bli spredt til disse serverne, og du må kanskje sjekke de manuelt.

Hvis du bruker MX -postene med samme domenenavn, må du legge til riktige DNS A -poster. Som nedenfor . Men hvis du bruker Google -apper, Outlook osv.

Mail_1 14400 i en 192.168.1.1
Mail_2 14400 i en 192.168.1.2
Mail_3 14400 i en 192.168.1.3

7. Txt (tekst) post

En TXT -post eller tekstpost har faktisk ingen rolle på domenfunksjonaliteten, og den brukes vanligvis til å vise litt informasjon eller brukes til noen bekreftelser som når du registrerer deg med Google Apps eller Outlook Mail -tjenesten, så vil de be deg om å legge til en Txt -post som de spør (en unik kode) slik at de kan bekrefte domeneeieren. SPF/DKIM -poster er også basert på TXT, men de har en funksjonalitet å utføre. Disse kan også brukes som et alternativ for å autentisere eierskapet ditt mens du legger til Google WebMaster -konto og andre Google -relaterte tjenester også.

Nedenfor er et eksempel på DNS ​​-oppføring for Google Verification

domene.com. 300 i txt Google-Site-Verification = GBMNBTGTIZ_ESMKJBKT-PXLH50M

8. SPF (Sender Policy Framework) Record

SPF -post er i utgangspunktet en TXT -post, som normalt publiserer alle IT -utpekte postservere for et domene eller underdomen. Hovedbruk av denne posten er å bevise legitimiteten til postene og forhindre forfalskede post. En destinasjons -postserver kan avvise e -post hvis de ikke er fra de registrerte eller nevnte e -postservere basert på denne posten.

Prøveoppføring
domene.com. I txt "V = SPF1 +A +MX +IP4: 192.168.1.5 -all

Dette sier at dette domenet vil sende legitime poster bare fra en post, MX Record -servere, og også fra IP 192.168.1.5 og alle andre kan avvises . Med ovennevnte SPF -post sjekker Receving -serveren alle servere og ipadress som er nevnt i SPF. Hvis IP -adressen samsvarer, vil sjekken bli bestått, og hvis ikke vil den hardt mislykkes (meldingen vil bli avvist automatisk), og hvis vi bruker "~ all", noe som er en myk mislykkes som er meldingen vil bli merket som mislykket, men ikke vil være avvist.

Du kan henvise til mer sytanx fra denne lenken.

9. DKIM (Domainkeys Identified Mail) -post

Dette er også en TXT -post som også er en e -postgodkjenningsprotokoll som er litt mer komplisert enn SPF. Denne posten er opprettet en for et underdomen som har en unik velger for nøkkelen og deretter vil ha en ".”Ved å legge til en slik post, vil den legge til en digital signatur til overskriftene til e -postmeldingen. Denne signaturen er validert ved hjelp av DKIM -posten publisert offentlig nøkkel. Dette er litt komplisert, og hvis du er i cpanel, provde et alternativ for å få dette til å bruke ett klikk -aktiveringsalternativ.

Prøveoppføring
misligholde._Domainkey 14400 i txt "V = DKIM1; K = RSA;
p = miiBijanbgkqhkig9w0baqefaaocaq8amiiBcgkcaqeamdb9e2q41olc0zdtsno2ik4khvmumkv98n1y0
FehuccfuiuiuiuiuiuiuiCfhdyytrytRryUytyTfyfyfytrytrytrytrytrytrytrytrytdybq3xatuaej
QGR0ZFAY6RSU ++ GQGF8ZRPJJD+O3ACQRZT4ZT8D7UHYE6CTGCV3KQED5I2DTSPODIZWEY8REYSHJMDCVULRJYDP "
UWJ5PRHFKWY7EC0ZNGGTOPMLBYXIPRX0Q/OBS9TLLAS785XJMNWJUBYYJC6V5JUQ+TRYHWA28TWM/L6/EICYNBZE
fwx8ohqsbflt0dnsrhq9xx0udmmbddd0zwoktx+wb7itg0hppvqne8jwkexqidaqab \;

10. DMARC Record

DMARC -posten fungerer bare hvis det er riktig SPF- og skim -poster. Det er en policy for e -postgodkjenningsprosessen og hvordan mottakerserveren skal håndtere posten hvis dette bryter policyen. Når en innkommende e -post kommer på den eksterne serveren, vil den spørre om DMARC -posten og sørge for at de spør på spørsmålene nedenfor

> Er de innkommende e -postene DKIM -signaturens riktige ?
> Kom meldingen fra et autorisert IP/server vertsnavn som nevnt av SPF -posten.
> Enten overskriften til de innkommende postene har PRPOPer -justering i henhold til RFC 5322.

Prøveoppføring

_dmarc.domene.com. I txt "v = dmarc1 \; p = ingen \; rua = mailto: [email protected] \;
RUF = mailto: [email protected] \; PCT = 100 "

_dmarc.domene.com: Underdomen som er satt opp for autentisering av DMARC alene.

V = DMARC1: DMARC -versjon i bruk.

P = ingen: nevner om den foretrukne behandlingen av policyen

rua =Mailto: [email protected] : Aggregrerte rapporter sendes til denne

RUF =Mailto: [email protected] : Forincsic rapporter skal sendes til denne e -postkontoen

PCT = 100: Dette er prosentandelen av e -poster som eieren ønsker å få sjekket posten og brukt til policyoppdateringer

DMARC/SPF/DKIM er alt nødvendig for en riktig autentisering for e -posttjenester

11. PTR (peker) post

PTR -poster er også kjent som omvendt DNS for IP. PTR -poster er normalt konfigurert på hostingleverandøren eller serverleverandørnivå. PTR -poster hjelper oss å matche en IP -adresse til et domene eller et underdomen (normalt til et FQDN fullt kvalifisert domenenavn) som vil bidra til å fungere omvendt DNS -spørsmål for å fungere ordentlig.

Så som en forhåndsinnstilling for å angi omvendt DNS for en IP, ber nå en dagers hosting / serverleverandører først om å sette opp en post for domenet / underdomenet til den IP -en, og når det er gjort, vil datasenteret sette opp RDNS (omvendt DNS ta opp).

12.CNAME (Canonical Name) Record

CNAME -post hjelper til med å peke et domene eller underdomen til et annet domene eller underdomenet.

Prøveoppføring:
Newdomain.com 14400 i CNAME -domenet.com.
Mail 14400 i CNAME Mail.domene.com.

Eksempel 1, peker newdomenet.com til domene.com hvor som det andre eksemplet peker post.Newdomain.com to mail.domene.com. Med dette poster, når en forespørsel kommer til Newdomain.com, den vil finne en cname -post til domenet.com. Etter det vil det starte et nytt oppslag for domene.com og den vil sende forespørselen til domenet.com og det samme er også med den andre rekorden.

1. 3.SRV (Service) Record

SRV -post hjelper oss å peke på en bestemt tjeneste som kjører på domenet eller underdomenet til et måldomene. Dette hjelper oss å lede trafikk for bestemte tjenester som chat -server eller meldingstjenester til Anothr -serveren.

Prøveoppføring:

_sipfederationTls._tcp. 3600 i SRV 100 1 5061 Sipfed.på nett.Lync.com.
_service._Protocol.eksempel.com 3600 i SRV 10 0 5060 Service.eksempel.com
_service._proto.Navn. TTL -klasse SRV prioritert vektportmål.

Service : Navn på tjenestene må startes med en understreking “_” og vil bli fulgt av en “.”Tjeneste kan være noe som _chat, _xmpp, _sipfederationTls (som brukes til Microsoft Exchange -servere) osv.

Protokoll:Navnet på protokollen bør også starte med en understrekning og deretter en ".”I dette tilfellet er det“ _TCP.”Og det forteller oss at det er en TCP -protokoll som er i bruk.

Navn : Navn eller domenenavn er domenet som vil motta original trafikk for denne tjenesten.

Prioritet: Det er det første nummeret som er nevnt i de ovennevnte eksemplene (henholdsvis 100 og 10) hjelper deg å sette prioritet for målserveren og lavere antall betyr høyere prioritet. Dette ligner på MX Record Prioritet og fungerer på samme måte som vi kan konfigurere en annen post som Fall Back også med en annen prioritet.

Vekt: Hvis vi lager lignende poster med samme prioritet, vil den avgjørende faktoren denne verdien. Vekten er henholdsvis 1 og 0 i eksemplene ovenfor.

Havn : Dette viser TCP- eller UDP -porten som tjenesten kjører.

Mål : Dette er målunderdomenet eller domenet som denne tjenesten vil bli omdirigert, og den skal ha en gyldig A / AAAA -post for å få denne trafikken omdirigert der.

14. RP (ansvarlig person) post

Dette er normalt ikke nødvendig nå om dagen, da det er en e -postadresse tilknyttet SOA -posten. Men hvis noe domene ønsker å ha spesifikt behov for å nevne bortsett fra standard SOA -post -e -postkonto, kan vi legge til en RP -post.

15. DnSkey Record

DNSkey Record inneholder en offentlig nøkkel som vil bli brukt av oppløserne for å bekrefte DNSSEC -signaturer.

Prøveoppføring

domene.com. 300 i DnSkey 257 3 5 Z10WDRIHGJGGIUGIUGKUOIKHPOUPTYRYRYRDFYTPOPO
ipoeuofzcndfn2Avd ==
Navn TTL -klasse RRType Flags_Filed Protocol Algorithm Public_Key

Navn : det er domenenavnet eller vertsnavnet normalt

I: Representere postklassen og standard en er i (som betyr internett)

Registreringstype: Registreringstype er typen av posten, og i dette tilfellet vil den være DnSkey

Flagg: Flaggte flagg er i et kablet format som er en 2 byte lang karakter. Mulige verdier er 0, 256 og 257. Hvis verdien er 256, betyr det at DnSkey-posten har ZSK (sonesignerende nøkkel) betalt, og hvis verdien er 257, inneholder den KSK (nøkkelsignende nøkkelkomponent. Kort sagt, dette følelsen inneholder et oddetall når det holder et KSK -nøkkelpar.

Protokoll: Dette har alltid en verdi på 3, for DNSSEC.

Offentlig nøkkel: Offentlig nøkkel er nøkkeldataene, og i dette tilfellet er det “Z10WDrihgjgiugiugkuoikhpouptyrsysyrdfytpopoipoeuofzcndfn2Avd ==”

Algoritme: Hjelper oss med å identifisere offentlige_keyer ved hjelp av forskjellige algoritmer og nedenfor er de mest brukte

• 1 = RSA/MD5
• 2 = Diffie-Hellman (dette støttes ikke av bind)
• 3 = DSA
• 4 = reservert
• 5 = RSA/SHA1
• 6 = DSA/SHA1/NSEC3
• 7 = RSA/SHA1/NSEC3
• 8 = RSA/SHA-256
• 10 = RSA/SHA-512

Konklusjon

Jeg håper dette virkelig hjelper alle dere til å forstå DNS ​​og sikre at hostingen din er konfigurert riktig.