DNS-protokollen bruges til at gøre verbale adresser til IP-adresser (som angiver, at hver computer unikke Internet) - så vi kan bruge de nemme navne i hukommelsen, samt spare os brug for at få, hver gang de ændringer der er foretaget i IP-adresser, der tilhører de systemer, som vi ønsker at tilslutte . Man kan sige, at DNS er faktisk i De Gule Sider "på internettet.
DNS-systemet består af et hierarki træ, grene adskilt dem markere punktet. Roden af træet, som er hans afgørende punkt, også markeret med en prik, og kaldes roden. Ved roden af træet, er store domæner (gTLD - global Top Level Domain) - vi kender de webadresser, såsom com, net, org og nationale domæner (ccTLD - landekode Top Level Domain), såsom for eksempel il for Israel. Teknisk er der ingen forskel mellem de to typer - både - som forklaret nedenfor - (.) En samlet poster i roden domænenavnet.
Hver gren i DNS-træet er defineret som en zone (zone) - og inden for hvert enkelt område som defineret forskellige typer af ressource records. Blandt andet er der optegnelser, der konverterer domænenavn (domænenavn) eller værtsnavn i det domæne (værtsnavn), som en henvisning til version 4 IP-adresse (eller IPv4) - såkaldte record "A", henvisning til den mailserver modtager post for domænenavnet (MX record - Mail eXchange), henvisning til IP version 6 (eller IPv6) - Record "AAAA", eller endda slå til - området under træet, som forvaltes af DNS-server Andet (record "NS" - en forkortelse for Name Server "), og endda - Hvem er ansvarlig for området (rekord RP - Ansvarlig person).
Ud over ressource optegnelser, også det område, indeholder oplysninger om sig selv. Såsom - versionsnummer ændring (Serial) - som typisk definerer formatet for dato og tid for nemheds skyld, intervallet i sekunder mellem opdateres oplysninger (Refresh) sekundære DNS-servere, tidsforsinkelse mellem forsøgene, som oven i tilfælde af svigt
(Prøv igen), og tiden efter, som DNS-server til at antage, at oplysningerne ikke er gyldig, hvis han ikke kunne få opdateringer indtil da (Udløb). Et andet meget vigtigt emne, der kan konfigureres på hver region globalt (Du kan også indstille en individuel rekord inden for regionen) - er "levende tid", eller engelsk TTL - Time To Live. Denne værdi, der defineres som en måleenhed sekunder, sige, hvad længden af gyldigheden af enhver indrejse, og som holder oplysninger om lokale cache kopier rekord (cache), hvis bestået denne gang. Grunden til den generelle bør holde en lokal kopi, og ikke bare få en aktuel kopi af information på et tidspunkt direkte fra DNS autoritativ - vil blive forklaret nedenfor.
At være i stand til at "se med øjnene" Hvad er definitionen på en region, er et eksempel på et sådant filformat til det websted, du kigger på nu, DNS-server til fælles - BIND - Berkeley Internet Name Daemon. Dette er ikke en anbefaling på denne server, og vice versa, jeg tror tinydns gør et meget bedre job, ikke pedant manically, og alvorlige økonomiske ressourcer. Dette er blot et eksempel:
$ TTL 86400 @ IN SOA shimi.net. hostmaster.shimi.net. ( 2007040808; Serial 28800; Opdater 14400; Prøv igen 3.600.000; Udløb 86.400) Minimum shimi.net. I NS ns2.powweb.com. shimi.net. I NS ns3.powweb.com. shimi.net. IN MX 30 mx.shimi.net. shimi.net. I EN 65.254.250.106 www IN CNAME shimi.net. mx I EN 65.254.254.50 mx I EN 65.254.254.51
Du kan opleve følgende vigtige ting: TTL definerede regler for regionen, som er 86400 sekunder (en hel dag ikke tro Gang - 60 * 60 * 24 og se for dig selv. ...?). Det betyder, at en given klient DNS verden ville beslutte at opretholde denne hjemmeside, forbudt at "huske", hvad han har lært i mere end 24 timer. Og hvorfor det er vigtigt for os? Fordi hvis jeg en dag beslutter at overføre min hjemmeside eller min mail-server, en anden computer, jeg ønsker, at alle besøgende på sitet, vil modtage en opdatering på den nye computer adressen kort tid, og vil fortsætte i lang tid (lad os sige - en uge ...) forsøger at komme til serveren gamle, der ikke kunne indeholde mit websted eller min e-mail boks, og derefter mister besøgende og / eller e-mail. Jeg sagde før jeg forklare, hvorfor selv holde disse oplysninger opdateret og finde ud af fra kilden data er sikkert rigtigt? Nå, årsagen er enkel. Først et spørgsmål om belastning på centrale servere. Da alle de Web Search DNS starter fra roden af træet ned, hvis der var en tilbagekaldelse mekanisme til forespørgsel resultater, så enhver søgning DNS, af nogen for millioner (eller milliarder?) Bruger internettet, ville komme til DNS-servere af de vigtigste - og der er ingen chance for at de skulle mødes denne byrde, ikke i form af databehandling hastighed, og muligvis ikke i form af båndbredde er afsat til dem. Derfor er det vigtigt at huske, at data, der allerede indsamles. En anden grund er effektivitet for slutbrugeren. Når resultatet gemmes i den lokale DNS klient (som normalt er placeret i ISP server, som slutbrugeren er tilsluttet), mens adgang til data langt hurtigere. Gennemsnitlig internetforbindelse, er det ikke mere end -50 milli - sekunder mellem at sende en anmodning om kommentarer. Hvis anmodningen er nødvendig, hver gang at bede alle de DNS-servere, der gør op i træet (forklaret senere), kan brugeren vente tiden var endda sekunder af perfektion skal besvares.
Fra ovennævnte teori, vil vi nu Lt'acls - Hvad sker der, for eksempel, når du går til www.cnn.com.
Antag Jeg er kunde hos selskabet NetVision. Når jeg opretter forbindelse til internettet, systemer Netvision fortælle computeren (eller på mit hjem router), som bruger DNS-servere til følgende: 194.90.1.5 og 194.90.1.49 til at forespørge DNS.
Jeg er interesseret, som førnævnte, browse til www.cnn.com. Til dette formål har jeg brug for at finde IP-adressen på den server www.cnn.com. Min computer vil henvende sig til DNS-serveren for Netvision og spørge ham: Giv mig et referat af www.cnn.com. Antag servering af Netvision ingen forudgående information om emnet. Hvad skal gøre? Han vil finde ud af for sig selv, hvad adressen www.cnn.com, og at han vil bede en af de DNS-servere chef for internettet, for eksempel server a.root-servers.net:
; << >> DiG 9.2.5 << >> @ a.root-servers.net www.cnn.com; (1 server fundet), globale muligheder: printcmd;; Got svar:; - >> HEADER < <- opcode: Query status: noerror, id: 23611,, flag: qr rd; QUERY: 1, SVAR: 0, MYNDIGHED: 13, YDERLIGERE: 14;; SPØRGSMÅL DEL:; www.cnn.com. I A, MYNDIGHED DEL: com. 137834 IN NS d.gtld-servers.net. com. 137834 IN NS e.gtld-servers.net. com. 137834 IN NS f.gtld-servers.net. com. 137834 IN NS g.gtld-servers.net. com. 137834 IN NS h.gtld-servers.net. com. 137834 IN NS i.gtld-servers.net. com. 137834 IN NS j.gtld-servers.net. com. 137834 IN NS k.gtld-servers.net. com. 137834 IN NS l.gtld-servers.net. com. 137834 IN NS m.gtld-servers.net. com. 137834 IN NS a.gtld-servers.net. com. 137834 IN NS b.gtld-servers.net. com. 137834 IN NS c.gtld-servers.net. ;, Afsnittet Yderligere: a.gtld-servers.net. 171837 I EN 192.5.6.30 a.gtld-servers.net. 171759 IN AAAA 2001:503: a83e :: 2:30 b.gtld-servers.net. 161282 I EN 192.33.14.30 b.gtld-servers.net. 165361 IN AAAA 2001:503:231 d :: 2:30 c.gtld-servers.net. 171159 I EN 192.26.92.30 d.gtld-servers.net. 161282 I EN 192.31.80.30 e.gtld-servers.net. 171159 I EN 192.12.94.30 f.gtld-servers.net. 171159 I EN 192.35.51.30 g.gtld-servers.net. 171159 I EN 192.42.93.30 h.gtld-servers.net. 171159 I EN 192.54.112.30 i.gtld-servers.net. 170422 I EN 192.43.172.30 k.gtld-servers.net. 171159 I EN 192.52.178.30 l.gtld-servers.net. 171159 I EN 192.41.162.30 m.gtld-servers.net. 171159 IN A 192.55.83.30;, Query tid: 190 ms,, SERVER: 198.41.0.4 # 53 (198.41.0.4),, HVORNÅR: Sun April 8 15:20:24 2007; MSG SIZE rcvd: 493
Det er oplysninger om den ressource records com, holdt et komplet sæt af andre DNS-servere under domænenavnet gtld-servers.net. For at gøre vores liv "nemmere", forudsat at "lim Records", som giver os denne anmodning har IP - adresser på disse servere, så vi bliver nødt til at kontrollere dem selv. Drej nu DNS-server Netvision randomiseret til en af de IP-adresser, han fik som svar på DNS-servere på internettet chef, og spurgte ham: "www.cnn.com - hvad så?" - Og får følgende svar:
; << >> DiG 9.2.5 << >> @ a.gtld-servers.net www.cnn.com (2 servere fundet) ;, Globale muligheder: printcmd ;; Got svar: , - >> HEADER << - opcode: Query status: noerror, id: 408 ;; Flag: QR Rd; QUERY: 1, SVAR: 0, myndighed: 4 personer, ekstra: 4 ;; SPØRGSMÅL DEL: ; Www.cnn.com. I EN ;; MYNDIGHED DEL: cnn.com. 172800 IN NS twdns-01.ns.aol.com. cnn.com. 172800 IN NS twdns-02.ns.aol.com. cnn.com. 172800 IN NS twdns-03.ns.aol.com. cnn.com. 172800 IN NS twdns-04.ns.aol.com. ;, Afsnittet Yderligere: twdns-01.ns.aol.com. 172800 IN A 149.174.213.151 twdns-02.ns.aol.com. 172800 IN A 152.163.239.216 twdns-03.ns.aol.com. 172800 I EN 207.200.73.85 twdns-04.ns.aol.com. 172800 IN A 64.12.147.120 ;, Query tid: 233 ms ,, SERVER: 192.5.6.30 # 53 (192.5.6.30) ,, HVORNÅR: Sun April 8 15:30:53 2007 ;; MSG SIZE rcvd: 192
Også her, fortæller a.gtld-servers.net faktum: "Hvad vil du fra mit liv - jeg ved ikke noget om www.cnn.com, hvis du vil have noget for alt under til cnn.com, bedes du kontakte en af de 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 igen, vi også frivilligt IP-adresserne på disse servere som et supplement til et svar, for ikke at have til at lede efter dem. "Great," siger serveren sig af Netvision, tilfældigt vælger en af disse fire servere, og spørger ham: "Nå, nogen fortælle mig, hvad IP-adresse www.cnn.com!" Og her er det svar, han fik:
; << >> DiG 9.2.5 << >> @ twdns-02.ns.aol.com www.cnn.com ; (1 server fundet) ;, Globale muligheder: printcmd ;; Got svar: , - >> HEADER << - opcode: Query status: noerror, id: 6714 ;; Flag: QR Rd; QUERY: 1, SVAR: 0, MYNDIGHED: 2, YDERLIGERE: 2 ;; SPØRGSMÅL DEL: ; Www.cnn.com. I EN ;; MYNDIGHED DEL: www.cnn.com. 3600 i NS dmtns01.turner.com. www.cnn.com. 3600 i NS dmtns02.turner.com. ;, Afsnittet Yderligere: dmtns01.turner.com. 3608 I EN 64.236.29.150 dmtns02.turner.com. 3608 I EN 64.236.22.150 ;, Query tid: 163 ms ,, SERVER: 152.163.239.216 # 53 (152.163.239.216) ,, HVORNÅR: Sun April 8 15:33:16 2007 ;; MSG SIZE rcvd: 112
Hvad sker der? Vi bør have et svar til denne server allerede! Nå ja. Så CNN besluttede at skifte DNS-servere i deres - men hvad de vil opdatere domænenavne registreret på DNS-servere kan være nyt, hvis deres kunder blot skabe mere forsinkelse, og sende dem til en anden DNS-server og unødvendige? I en knivspids, går DNS server Netvision om, og vender sig til dmtns01.turner.com at få endelig de ønskede oplysninger, og det ser sådan ud:
; << >> DiG 9.2.5 << >> @ dmtns01.turner.com www.cnn.com ; (1 server fundet) ;, Globale muligheder: printcmd ;; Got svar: , - >> HEADER << - opcode: Query status: noerror, id: 44943 ;; Flag: QR aa rd; QUERY: 1, SVAR: 8, MYNDIGHED: 0, YDERLIGERE: 0 ;; SPØRGSMÅL DEL: ; Www.cnn.com. I EN ;; SVAR DEL: www.cnn.com. 600 om 64.236.29.120 www.cnn.com. 600 om 64.236.91.21 www.cnn.com. 600 om 64.236.91.22 www.cnn.com. 600 om 64.236.91.23 www.cnn.com. 600 om 64.236.91.24 www.cnn.com. 600 om 64.236.16.20 www.cnn.com. 600 om 64.236.16.52 www.cnn.com. 600 om 64.236.24.12
Holy shit, hvor mange servere, de har! Brugerens browser vil sandsynligvis nødt til at vælge en af otte tilfældigt til at modtage fra webstedet! Bemærk, at et andet interessant faktum - deres TTL er i alt 600 sekunder, eller ti minutter. Hvorfor så lave? At spørge om de opdaterede data hvert tiende minut. Og hvorfor så meget belastning på DNS? Sandsynligvis fordi tilgængeligheden er vigtig for dem, og ønsker, at server ud af de otte efteråret, vil DNS blive opdateret umiddelbart af en automatiseret proces til at fjerne serveren fra listen, og ingen hjemmeside vil være tilgængelig i mere end ti minutter, hvilket er den maksimale tid at få lov til kunderne at holde oplysningerne om konvertering af IP-adresse til dette.
Endelig point til præcisere: alle trinene nævnt ovenfor, bevarer også oplysninger, der modtages som et resultat af forespørgslen til en lokal kopi (forudsat det er i caching navneserver - og som regel gør det), så hvis oplysningerne var tilgængelige lokalt, vil serveren ikke har ulejliget sig med at rejse alle Jorden for at finde ham, men hævder, at den lokale kopi, og dermed spare tid og netværkstrafik. Hertil kommer, at eventuelle DNS-server, klient-niveau, og dekodningsprocessen servere, der hjalp undervejs, ikke var tilgængelig da ansøgeren skulle nærme sig en anden tilfældig server listen, og få svar fra ham. Det vil tage mere tid, men lykkedes til sidst. Det er altid den mest brugte DNS-serveren en for hver region - overlevelse.