DNS-protokollen brukes til å lage verbale adresser til IP-adresser (som er noe som indikerer at hver datamaskin unike Internet) - slik at vi kan bruke enkle navn til minne, samt lagre oss trenger for å få hver gang endringer i IP-adresser tilhørende de systemene som vi ønsker å koble . Du kan si at DNS er faktisk i Gule sider "av Internett.
DNS-systemet består av et hierarki tre, separert greiner dem markere poenget. Roten av treet, er at hans sentralt punkt, også markert med en prikk, og kalles roten. Ved roten av treet, er store domener (gTLD - global toppdomene) - vet vi webadressene eksempel com, net, org og nasjonale domener (ccTLD - landkode toppnivådomene), som for eksempel IL for Israel. Teknisk er det ingen forskjell mellom de to typer - både - som forklart nedenfor - (.) Totalt poster i roten domenenavnet.
Hver gren i DNS treet er definert som en sone (sone) - og innenfor hvert slikt område definert ulike typer ressurs poster. Blant annet er det poster som konverterer domenenavn (domenenavn) eller vertsnavn i domene (vertsnavn) som en referanse til versjon 4 IP-adresse (eller IPv4) - såkalt plata "A", henvisning til e-postserveren som mottar e-post for domenenavnet (MX record - Mail eXchange), henvisning til IP versjon 6 (eller IPv6) - Record "AAAA", eller til og med slå til - området under treet, som ledes av den DNS-serveren Annet (record "NS" - en forkortelse for Name Server "), og selv - Hvem er ansvarlig for området (rekord RP - Ansvarlig Person).
I tillegg til ressurspersoner poster, inneholder området også informasjon om seg selv. Slike som - versjonsnummer endring (Serial) - som vanligvis definerer formatet for dato og tid for enkelhets skyld, intervallet i sekunder mellom oppdateres informasjon (Refresh) sekundære DNS-servere, tidsforsinkelse mellom forsøk som ovenfor i tilfelle av svikt
(Retry), og hvor lang tid det DNS-serveren til å anta at opplysningene er ikke gyldig hvis han ikke kunne få oppdateringer til da (utløper). Et annet svært viktig tema som kan konfigureres på hver region globalt (Du kan også sette en individuell rekord i regionen) - er "levende time", eller engelsk TTL - Time To Live. Denne verdien, definert som en måleenhet av sekunder, sier hvor lang gyldighet for en oppføring, og som holder informasjon om lokale cache kopier record (cache) dersom gikk denne gangen. Grunnen til at det generelle bør holde en lokal kopi og ikke bare få en oppdatert kopi av informasjon om gangen direkte fra DNS autoritative - vil bli forklart nedenfor.
For å kunne "se med øynene" Hva er definisjonen på en region, er et eksempel på et filformat for området du ser på nå, DNS-serveren til felles - BIND - Berkeley Internet Name Daemon. Dette er ikke en anbefaling på denne serveren, og vice versa, tror jeg tinydns gjør en mye bedre jobb, ikke pedant manisk, og alvorlige økonomiske ressurser. Dette er bare ett eksempel:
$ TTL 86400 @ IN SOA shimi.net. hostmaster.shimi.net. ( 2007040808; Serial 28800; Refresh 14400; Retry 3.600.000; Utløp 86 400) Minimum shimi.net. I NS ns2.powweb.com. shimi.net. I NS ns3.powweb.com. shimi.net. I MX 30 mx.shimi.net. shimi.net. I 65.254.250.106 A www IN CNAME shimi.net. MX i A 65.254.254.50 MX i A 65.254.254.51
Du kan legge merke til følgende viktige tingene: TTL definerte regler for regionen, som er 86400 sekunder (en hel dag ikke tro Multipliser - 60 * 60 * 24 og se selv ....?). Dette betyr at enhver klient DNS verden ville bestemme seg for å opprettholde dette nettstedet, forbudt å "huske" hva han har lært i mer enn 24 timer. Og hvorfor det er viktig for oss? Fordi hvis jeg en dag bestemmer seg for å overføre nettstedet mitt eller min mail server, en annen datamaskin, vil jeg alle besøkende til området vil motta en oppdatering på den nye datamaskinen adressen kort tid, og vil fortsette i lang tid (la oss si - en uke ...) prøve å få til serveren gammel, som ikke kunne inneholde nettstedet mitt eller min e-postkasse, og deretter mister besøkende og / eller e-post. Jeg sa før jeg forklare hvorfor selv holde denne informasjonen oppdatert og finn ut fra kilden data er trygt sant? Vel, er grunnen enkel. Først av alt, et spørsmål om belastning på sentrale servere. Siden alle nettsøk DNS starter fra roten av treet ned, hvis det var en tilbakekalling mekanisme for spørringsresultatene, deretter eventuelle søk DNS, etter ett for millioner (eller milliarder?) Bruker Internett, ville komme til DNS-serverne av de viktigste - og det er ingen sjanse for at de skulle møtes denne byrden, ikke i form av databehandling hastighet, og ganske muligens ikke i form av båndbredde tildelt dem. Derfor er det viktig å huske at data som allerede er innsamlet. En annen grunn er effektiviteten for sluttbrukeren. Når resultatet er lagret i den lokale DNS-klienten (som vanligvis er plassert i ISP-server som sluttbrukeren er tilkoblet), mens tilgang til data mye raskere. Gjennomsnittlig Internett-tilkobling, er det ikke mer enn -50 mill - sekunder mellom sender en forespørsel om kommentar. Hvis forespørselen er nødvendig hver gang for å spørre alle DNS-serverne som utgjør treet (forklart senere), kan brukeren vente tiden var enda sekunder av perfeksjon som skal besvares.
Fra ovennevnte teori, vil vi nå Lt'acls - Hva skjer, for eksempel når du går til www.cnn.com.
Anta jeg er en kunde av selskapet NetVision. Når jeg kobler til Internett, systemer Netvision fortelle datamaskinen (eller på min hjemme ruter) som bruker DNS-serverne for følgende: 194.90.1.5 og 194.90.1.49 å spørre DNS.
Jeg er interessert, som nevnt, bla til www.cnn.com. For dette formålet, må jeg finne IP adressen til serveren www.cnn.com. Min datamaskin vil slå til DNS serveren Netvision og spør ham: Gi meg en oversikt over www.cnn.com. Anta servering av Netvision ingen tidligere informasjon om emnet. Hva kommer til å gjøre? Han vil finne ut for seg selv hva adressen til www.cnn.com, og at han vil be en av DNS servere sjef for Internett, for eksempel server a.root-servers.net:
; << >> DIGIC 9.2.5 << >> @ a.root-servers.net www.cnn.com ; (1 server found) ;; Globale alternativer: printcmd ;; Got svar: ,, - >> HEADER << - opcode: QUERY, status: NOERROR, id: 23611 ;; Flags: QR rd; QUERY: 1, SVAR: 0, AUTHORITY: 13, EKSTRA: 14 ,, SPØRSMÅL DEL: ; Www.cnn.com. IN A ,, Myndighet §: com. 137 834 i NS d.gtld-servers.net. com. 137 834 i NS e.gtld-servers.net. com. 137 834 i NS f.gtld-servers.net. com. 137 834 i NS g.gtld-servers.net. com. 137 834 i NS h.gtld-servers.net. com. 137 834 i NS i.gtld-servers.net. com. 137 834 i NS j.gtld-servers.net. com. 137 834 i NS k.gtld-servers.net. com. 137 834 i NS l.gtld-servers.net. com. 137 834 i NS m.gtld-servers.net. com. 137 834 i NS a.gtld-servers.net. com. 137 834 i NS b.gtld-servers.net. com. 137 834 i NS c.gtld-servers.net. ,, Ekstra del: a.gtld-servers.net. 171 837 IN A 192.5.6.30 a.gtld-servers.net. 171759 IN AAAA 2001:503: a83e :: 02:30 b.gtld-servers.net. 161 282 IN A 192.33.14.30 b.gtld-servers.net. 165361 IN AAAA 2001:503:231 d :: 02:30 c.gtld-servers.net. 171 159 IN A 192.26.92.30 d.gtld-servers.net. 161 282 IN A 192.31.80.30 e.gtld-servers.net. 171 159 IN A 192.12.94.30 f.gtld-servers.net. 171 159 IN A 192.35.51.30 g.gtld-servers.net. 171 159 IN A 192.42.93.30 h.gtld-servers.net. 171 159 IN A 192.54.112.30 i.gtld-servers.net. 170 422 IN A 192.43.172.30 k.gtld-servers.net. 171 159 IN A 192.52.178.30 l.gtld-servers.net. 171 159 IN A 192.41.162.30 m.gtld-servers.net. 171 159 IN A 192.55.83.30 ,, Query tid: 190 msek ,, SERVER: 198.41.0.4 # 53 (198.41.0.4) ,, NÅR: Søn 8 april 15:20:24 2007 ;; MSG STØRRELSE rcvd: 493
Det vil si informasjon om ressurspotensialet Records com, holdt et komplett sett av andre DNS-servere under domenenavnet gTLD-servers.net. For å gjøre livene våre "enklere", forutsatt «limet postene" som gir oss denne forespørselen har IP-adressene til disse serverne, slik at vi må sjekke dem selv. Nå slår den DNS-serveren til Netvision randomisert til en av de IP-adressene han fikk som svar på DNS-servere på Internett høvdingen, og spurte ham: "www.cnn.com - hva da?" - Og vil få følgende svar:
; << >> DIGIC 9.2.5 << >> @ a.gtld-servers.net www.cnn.com (2 servere funnet) ;; Globale alternativer: printcmd ;; Got svar: ,, - >> HEADER << - opcode: QUERY, status: NOERROR, id: 408 ;; Flags: QR rd; QUERY: 1, SVAR: 0, AUTHORITY: 4, Ekstra: 4 ,, SPØRSMÅL DEL: ; Www.cnn.com. IN A ,, Myndighet §: cnn.com. 172 800 i NS twdns-01.ns.aol.com. cnn.com. 172 800 i NS twdns-02.ns.aol.com. cnn.com. 172 800 i NS twdns-03.ns.aol.com. cnn.com. 172 800 i NS twdns-04.ns.aol.com. ,, Ekstra del: twdns-01.ns.aol.com. 172 800 IN A 149.174.213.151 twdns-02.ns.aol.com. 172 800 IN A 152.163.239.216 twdns-03.ns.aol.com. 172 800 IN A 207.200.73.85 twdns-04.ns.aol.com. 172 800 IN A 64.12.147.120 ,, Query tid: 233 msek ,, SERVER: 192.5.6.30 # 53 (192.5.6.30) ,, NÅR: Søn 8 april 15:30:53 2007 ;; MSG STØRRELSE rcvd: 192
Også her, forteller a.gtld-servers.net faktum: "Hva vil du gjøre fra mitt liv - Jeg vet ikke noe om www.cnn.com, hvis du vil ha noe for alt nedenfor til cnn.com, kontakt en av tjenere DNS følgende: twdns-01.ns.aol.com, twdns-02.ns.aol.com, twdns-03.ns.aol.com, twdns-04.ns.aol.com ", og igjen, vi også frivillig IP-adressene til disse serverne som et supplement for et svar, ikke å måtte lete etter dem. "Great", sier selve serveren av Netvision, tilfeldig velger en av disse fire servere, og spør ham: "Vel, noen å fortelle meg hva IP-adressen www.cnn.com!", Og her er svaret han fikk:
; << >> DIGIC 9.2.5 << >> @ twdns-02.ns.aol.com www.cnn.com ; (1 server found) ;; Globale alternativer: printcmd ;; Got svar: ,, - >> HEADER << - opcode: QUERY, status: NOERROR, id: 6714 ;; Flags: QR rd; QUERY: 1, SVAR: 0, AUTHORITY: 2, EKSTRA: 2 ,, SPØRSMÅL DEL: ; Www.cnn.com. IN A ,, Myndighet §: www.cnn.com. 3600 i NS dmtns01.turner.com. www.cnn.com. 3600 i NS dmtns02.turner.com. ,, Ekstra del: dmtns01.turner.com. 3608 IN A 64.236.29.150 dmtns02.turner.com. 3608 IN A 64.236.22.150 ,, Query tid: 163 msek ,, SERVER: 152.163.239.216 # 53 (152.163.239.216) ,, NÅR: Søn 8 april 15:33:16 2007 ;; MSG STØRRELSE rcvd: 112
Hva skjer? Vi bør ha et svar på denne serveren allerede! Oh well. Så CNN besluttet å bytte DNS-serverne til deres - men hva de vil oppdatere domenenavn registrert på DNS-servere kan være ny hvis kundene rett og slett føre til flere forsinkelser, og sende dem til en annen DNS-server og unødvendig? I en klemme, går DNS serveren Netvision på, og snur seg mot dmtns01.turner.com å få endelig ønsket informasjon, og det ser slik ut:
; << >> DIGIC 9.2.5 << >> @ dmtns01.turner.com www.cnn.com ; (1 server found) ;; Globale alternativer: printcmd ;; Got svar: ,, - >> HEADER << - opcode: QUERY, status: NOERROR, id: 44943 ;; Flags: QR aa rd; QUERY: 1, SVAR: 8, AUTHORITY: 0, EKSTRA: 0 ,, SPØRSMÅL DEL: ; Www.cnn.com. IN A ,, SVAR DEL: www.cnn.com. 600 i A 64.236.29.120 www.cnn.com. 600 i A 64.236.91.21 www.cnn.com. 600 i A 64.236.91.22 www.cnn.com. 600 i A 64.236.91.23 www.cnn.com. 600 i A 64.236.91.24 www.cnn.com. 600 i A 64.236.16.20 www.cnn.com. 600 i A 64.236.16.52 www.cnn.com. 600 i A 64.236.24.12
Holy shit, hvor mange servere de har! Brukerens nettleser sannsynligvis vil måtte velge en av åtte tilfeldig å motta fra siden! Merk at en annen interessant faktum - deres TTL er det totalt 600 sekunder, eller ti minutter. Hvorfor så lav? Å spørre om de oppdaterte data hvert tiende minutt. Og hvorfor så mye belastning på DNS? Sannsynligvis fordi tilgjengeligheten er viktig for dem, og ønsker at serveren ut av åtte høsten, vil DNS bli oppdatert umiddelbart etter en automatisert prosess for å fjerne serveren fra listen, og ingen området vil være utilgjengelig for lenger enn ti minutter, som er maksimal tid til å få lov kundene å holde informasjonen om konvertering av IP-adressen til denne.
Endelig poeng for å klargjøre: Alle de trinnene som er nevnt ovenfor, også beholder den mottatte informasjonen som et resultat av søket til en lokal kopi (antar det er i caching name server - og vanligvis gjør det), så dersom opplysningene var tilgjengelig lokalt, ville ikke serveren har giddet å reise hele Earth for å finne ham, men hevder at den lokale kopien, og dermed spare tid og nettverkstrafikk. I tillegg, hvis noen DNS-server, klienten nivå, og dekoding prosess servere som hjalp langs veien, var ikke tilgjengelig, da søkeren ville nærme en annen tilfeldig server liste, og få svar fra ham. Det ville ta mer tid, men var vellykket på slutten. Dette er alltid den mest brukte DNS-server en for hver region - overlevelse.