Hvad er DNS? Domænenavnssystem, DNS-server og IP-adressekoncepter forklaret

Introduktion

I slutningen af ​​denne artikel skal du have en bedre forståelse af:

  1. Hvad DNS er, og hvad det gør
  2. Hvad DNS-servere gør
  3. Sådan fungerer Internet Protocol (IP) -adresser i forbindelse med DNS

Vigtige begreber

Der er nogle vigtige mentale modeller at være fortrolige med, når man lærer om DNS, DNS-servere og IP-adresser. At gå over disse begreber nu, før du begynder at lære om DNS, vil

  • hjælpe med at forstå alle de forskellige udtryk, der bruges til at beskrive adfærd, der passer ind i disse modeller, og
  • hjælp til lagring af hukommelse.

Mentale modeller giver dig en referenceramme, når tingene bliver lidt underlige og ukendte.

Så lad os lægge grunden.

  • Forespørgsel og svar. Dette er når ting 1 beder ting 2 om noget, og ting 2 reagerer på den anmodning. Sådan her:
  • Forældre-barn-knudeforhold og grafer, der ser sådan ud (kun mere komplicerede).
  • Beskeder. Det er ikke en forespørgsel og et svar, fordi der ikke er noget svar. I DNS-verdenen varierer formateringen og indholdet af meddelelser alt efter brugen.
  • Forholdet mellem klient og server. Enkelt sagt er en server en software eller hardwareenhed, der giver funktionalitet til anden software eller hardwareenheder, kaldet "klienter".

    Forbered dig på en masse snak om servere. Som det viser sig, er der en hel masse servere, der går ind i denne ting, vi kalder DNS, og hvordan vi som mennesker bruger det, når vi opretter forbindelse til internettet.

Hvad er DNS?

Domain Name System (DNS) domænenavn (i URL'er eller i e-mail-adresse), der kan læses af mennesker, til IP-adresser. For eksempel oversætter DNS og kortlægger domænet freecodecamp.org til IP-adressen 104.26.2.33.

For at hjælpe dig med at forstå denne beskrivelse fuldt ud, beskriver dette afsnit:

  • Historisk kontekst for udvikling af DNS - hvilke problemer løste det og IP-adresser løste?
  • Domænenavne
  • IP-adresser

Historisk kontekst

I 1966 grundlagde det amerikanske forskningsagentur Advanced Research Projects Agency (ARPA) et computernetværk kaldet ARPAnet. Kort sagt, tænk på ARPAnet som den første iteration af det, vi nu kender i dag som Internettet.

De vigtigste mål for ARPAnet inkluderet

“(1) leverer pålidelig kommunikation selv i tilfælde af delvis udstyr eller netværksfejl, (2) at kunne oprette forbindelse til forskellige typer computere og operativsystemer og (3) være en samarbejdsindsats snarere end et monopol kontrolleret af en enkelt virksomhed. For at levere pålidelig kommunikation i lyset af udstyrssvigt blev ARPANET designet således, at intet punkt eller link var mere kritisk end nogen anden. Dette blev ledsaget af opførelsen af ​​overflødige ruter og brugen af ​​on-the-fly omdirigering af data, hvis nogen del af netværket mislykkedes. ”

Problemerne

DNS og TCP / IP var afgørende for at løse to problemer med ARPAnet:

For ARPAnet var der en enkelt placering (en fil kaldet HOSTS.TXT), der indeholdt al kortlægning af navn til adresse for hver vært på netværket.

“HOSTS.TXT blev vedligeholdt af SRI's Network Information Center (kaldet“ NIC ”) og distribueret fra en enkelt vært, SRI-NIC. NIC og greb den aktuelle HOSTS.TXT-fil. Deres ændringer blev samlet i en ny HOSTS.TXT- fil en eller to gange om ugen. ”

Der var tre udfordringer med denne opsætning:

  1. Trafik og belastning - distribution af filen blev for meget for den ansvarlige vært at håndtere.
  2. Navnekollisioner - hver vært måtte have et unikt navn, og der var ingen central autoritet, der forhindrede netværksbrugere i at tilføje en vært med et modstridende (ikke-entydigt) navn og derved "bryde hele skemaet."
  3. Konsistens - handlingen med at opdatere filen og sikre, at alle værter havde den mest opdaterede version, blev umulig eller i det mindste meget vanskelig.

I det væsentlige var HOSTS.TX et enkelt fejlpunkt, så hele processen her skaleres ikke godt forbi et bestemt antal værter. ARPAnet havde brug for en decentral og skalerbar løsning. DNS var det. Kilde

Kommunikation mellem vært og vært inden for det samme netværk var ikke pålidelig nok. TCP / IP hjalp med at løse dette problem.

  1. Transmission Control Protocol (TCP) giver kvalitetssikringsforanstaltninger til processen med at omdanne meddelelser (mellem værter) til pakker. TCP-protokollen er forbindelsesorienteret, hvilket betyder, at der skal oprettes en forbindelse mellem kildehost og destinationshost.
  2. Internetprotokol (IP) definerer, hvordan meddelelser (pakker) transporteres mellem kildehost og destinationshost. En IP-adresse er en unik identifikator for en bestemt sti, der fører til en vært på et netværk.
  3. TCP og IP arbejder tæt sammen, hvorfor der normalt henvises til dem som "TCP / IP."
  4. Mens jeg ikke dykker ned i det i denne artikel, bruges både TCP og User Datagram Protocol (UDP) i datatransportlaget af DNS. UDP er hurtigere, meget mindre pålidelig og kræver ikke forbindelser; TCP er langsommere, meget mere pålidelig, men har brug for forbindelser. De bruges efter behov og passende i DNS; det er overflødigt at sige, at inkluderingen af ​​TCP i APRAnet var en værdifuld tilføjelse til datatransportlaget.

I begyndelsen af ​​1980'erne var DNS og TCP / IP (og derfor IP-adresser) standardprocedurer for ARPAnet.

Denne historie er meget forkortet. Hvis du vil lære mere om disse emner, skal du henvise til afsnittet Ressourcer i slutningen af ​​denne artikel.

Nu hvor vi har en vis historisk sammenhæng, lad os gå videre til at lære mere om domænenavne og IP-adresser.

Domænenavne

I forbindelse med DNS giver et domænenavn en brugervenlig måde at pege på ikke-lokale ressourcer. Dette kan være et websted, et mailsystem, printserver eller enhver anden server, der er tilgængelig på Internettet. Et domænenavn kan være mere end bare et websted!

"Målet med domænenavne er at tilvejebringe en mekanisme til navngivning af ressourcer på en sådan måde, at navnene kan bruges i forskellige værter, netværk, protokolfamilier, internets og administrative organisationer."

Et domænenavn er meget lettere at huske og gå ind i en terminal eller internetbrowser end en IP-adresse.

Et domænenavn er en del af en Uniform Resource Locator (URL), men vilkårene er ikke synonyme . En URL er den komplette webadresse for en ressource, mens domænenavnet er navnet på et websted og er en underkomponent af enhver URL.

Mens der er tekniske forskelle mellem URL'er og domænenavne, behandler webbrowsere dem normalt på samme måde, så du kommer til webstedet, hvis du skriver den komplette webadresse eller bare domænenavnet.

Topdomæner og domæner på andet niveau

Der er to dele til et givet domæne: topdomæne (TLD) og andet niveau domæne (SLD). Delene af et domænenavn bliver mere specifikke, når de bevæger sig fra højre (slutning) til venstre (begyndelse).

Dette kan være forvirrende i starten. Lad os for eksempel se på “freecodecamp.org”

  • URL: //www.freecodecamp.org
  • Domænenavn: freecodecamp.com
  • TLD: org
  • SLD: freecodecamp

I de tidlige dage af ARPAnet var der et begrænset antal TLD'er til rådighed, herunder com, edu, gov, org, arpa, mil og landekodedomæner med 2 bogstaver. Disse topdomæner var oprindeligt forbeholdt institutioner, der deltog i ARPAnet, men nogle blev senere tilgængelige på kommercielle markeder.

I dag er der en sammenlignende rigdom af tilgængelige TLD'er, herunder net, aero, biz, coop, info, museum, navn og andre.

Anden niveau domæner er de domæner, der er tilgængelige for individuelt køb gennem domæneregistratorer (for eksempel Namecheap).

IP-adresser

Mens IP-adresser er relateret til DNS i deres funktion, er selve internetprotokollen teknisk adskilt fra DNS. Jeg har allerede givet historisk kontekst til denne sondring, så nu forklarer jeg, hvordan IP-adresser fungerer.

En IP-adresse er, som tidligere nævnt, en unik identifikator for en bestemt sti, der fører til en vært på et netværk. Jeg vil gerne henvise til analogien mellem et telefonnummer og en telefon: et telefonnummer repræsenterer ikke selve telefonen, det er bare en måde at nå personen med telefonen.

Denne analogi er med rimelighed passende (i det mindste på overfladeniveau) med IP-adresser. En IP-adresse repræsenterer et slutpunkt, men det er ikke selve slutpunktet. IP-tildelinger kan være faste (permanente) eller dynamiske (fleksible og kan tildeles igen).

Ligesom et domænenavn følger organisationen af ​​IP-adresser en hierarkisk struktur. I modsætning til domænenavne bliver IP-adresser mere specifikke fra venstre mod højre. Dette er et IPv4-eksempel nedenfor:

Diagram viser, at 129.144 er netværksdelen, og 50.56 er værtsdelen af ​​en IPv4-adresse.
  • Netværk: det unikke nummer, der er tildelt dit netværk
  • Vært: identificerer værten (maskinen) på netværket

Hvis der er behov for større specificitet, kan netværksadministratorer subnet adresseområdet og delegere yderligere numre.

Hvor mange IP-adresser er der?

IPv4 var den allerførste iteration af IP, som ARPAnet brugte i produktionen. Implementeret i begyndelsen af ​​80'erne er det stadig den mest udbredte IP-version. Det er en 32-bit ordning og kan derfor understøtte lidt over 4 milliarder adresser.

Men vent, er det nok? Nix.

IPv6 har et 128-bit-skema, som gør det muligt at understøtte 340 undecillion-adresser. Det tilbyder også ydeevne forbedringer på IPv4.

Eksempel på IPv4-adresse:

  • 104.26.2.33 (freeCodeCamp)

Eksempel på IPv6-adresse:

  • 2001: db8: a0b: 12f0 :: 1 (det komprimerede format og ikke peger på freeCodeCamp)

Hvordan fungerer domænenavnssystemet?

Så vi har lært om domænenavne! Vi har lært om IP-adresser! Hvordan forholder de sig nu til domænenavnsystemet?

Først og fremmest passer de ind i navneområdet.

Domænenavnsområdet

Som antydet af sproget "top" -domæne og "andet" -domæne er navneområdet baseret på et hierarki

“... med hierarkiet omtrent svarende til organisationsstruktur og navne ved hjælp af". " som tegnet for at markere grænsen mellem hierarkiniveauer. ” Kilde.

Denne trægraf med roden øverst illustrerer strukturen bedst:

Lad os nedbryde dette og starte øverst.

Toppen af ​​denne graf, bemærket med et "." kaldes “rod”.

“De autoritative navneservere, der betjener DNS-rodzonen, almindeligvis kendt som“ rodserverne ”, er et netværk af hundredvis af servere i mange lande rundt om i verden. De er konfigureret i DNS-rodzonen som 13 navngivne myndigheder. ”

Roddomænet har en nul-længdemærke.

Herfra og ned har hver node (prik) i grafen en unik etiket på op til 63 tegn.

Det første niveau ned fra roden er TLD'erne: com, org, edu og gov. Bemærk, at denne graf ikke indeholder en komplet liste over TLD'er.

Nedenfor TLD'er er SLD'erne, domænerne på andet niveau. Børnene til hver knude kaldes "underdomæner", som stadig betragtes som en del af det overordnede domæne. For eksempel i freecodecamp.org er freecodecamp (SLD) et underdomæne af org (TLD).

Afhængig af hierarkiet på hjemmesiden kan der være domæner på tredje, fjerde, femte niveau. For eksempel er hypotetisk-underdomæne det tredje niveau domæne og underdomænet for freecodecamp i hypotetisk-underdomæne.freecodecamp.org. Så videre og så videre, i det mindste op til 127 niveauer, hvilket er det maksimale tilladte af DNS.

Hvem administrerer navneområdet?

Ville det ikke være nødt til at prøve at få en person eller organisation til at administrere alt? Ja, det ville det. Især fordi et af DNS's vigtigste designmål var at fremme distribueret, decentral styring af systemet generelt.

Jeg ville ønske jeg kunne fortælle dig, at de ansvarlige kaldes "Namespace Kings", men ak.

Hvert domæne (eller underdomæne) i domænenavnområdet er eller er en del af en zone , "et autonomt administreret stykke af navneområdet." Så navneområdet er opdelt i zoner.

Ansvaret for disse zoner styres gennem delegering og administration.

Processen med at tildele underdomænernes ansvar til andre enheder kaldes delegering.

For eksempel administrerer Public Interest Registry domænenavnet org og har siden 2003. Public Interest Registry kan delegere ansvaret til andre parter for at administrere underdomæner af org, siger freecodecamp. Og så kan den, der administrerer freecodecamp, tildele ansvaret for underdomænerne i freecodecamp (for eksempel hypotetisk-subdomæne.freecodecamp.com) til en anden part.

Hvis nogen (en organisation, et team eller en person) administrerer en zone, administrerer den navneserver, der er ansvarlig for zonen, hvad de laver.

Dette bringer os ind i et af de mest grundlæggende koncepter i Domain Name System.

Domain Name Servers

"Programmerne, der gemmer oplysninger om domænenavnsområdet, kaldes navneservere."

På dette tidspunkt er det at tænke på et klient-serverforhold, i det mindste indledningsvis, nyttigt. Domænenavneservere er “server” -siden af ​​klient-serverforholdet. Navneservere kan indlæse en, hundreder eller endda tusinder af zoner, men de indlæser aldrig hele navneområdet. Når en navneserver har indlæst totaliteten af ​​en zone, siges den at være autoritativ for den zone.

For at forstå hvorfor navneservere fungerer som de fungerer, er det nyttigt at forstå ”klient” -delen af ​​forholdet.

Resolvere

I DNS kaldes klienten (anmoderen om oplysninger) “resolver”, som i starten måske virker bagud. Ville den server, der løser anmodningen, ikke kaldes "resolver?" Det troede jeg også, men det er det ikke. Bedst at bare huske det og komme videre.

Resolvere er typisk inkluderet, de facto, i de fleste operativsystemer, så applikationerne installeret på OS behøver ikke at finde ud af, hvordan man laver DNS-forespørgsler på lavt niveau.

DNS-forespørgsler og deres svar er typer af DNS-meddelelser og har deres egen datatransportprotokol (normalt UDP). Resolvere er ansvarlige for at hjælpe applikationer installeret på OS med at oversætte anmodninger om DNS-relaterede data til DNS-forespørgsler.

Alt i alt er resolvere ansvarlige for emballering og afsendelse af anmodninger om data. Når resolveren modtager svaret (hvis overhovedet), sender det det tilbage til den oprindelige anmodende applikation i et format, der kan forbruges til den anmodende applikation.

Tilbage til navneservere

Nu hvor vi er lidt mere fortrolige med klientsiden af ​​forholdet, er vi nødt til at forstå, hvordan domænenavnservere reagerer på resolverforespørgsler.

Navneservere svarer på DNS-forespørgsler gennem opløsning . Opløsning er den proces, hvor navneservere finder datafiler i navneområdet. Afhængigt af typen af ​​forespørgsel reagerer navneservere forskelligt på forskellige forespørgsler, men det endelige mål er opløsning.

Forespørgselstyper

Forespørgselstype? Ja, der er flere typer DNS-forespørgsler. Men først, hvad er der normalt i en DNS-forespørgsel? Det er en anmodning om information, specifikt til IP-adressen, der er knyttet til et domænenavn.

  • Rekursiv : rekursive forespørgsler gør det muligt at henvise forespørgslen til flere navneservere, der kan løses. Hvis den første forespurgte navneserver ikke har de ønskede data, sender den navneserver forespørgslen videre til den mest passende næste navneserver, indtil navneserveren med de ønskede datafiler findes og sender et svar til opløseren.
  • Iterativ : iterative forespørgsler kræver, at den forespurgte navneserver reagerer enten med de ønskede data eller med en fejl. Svaret kan indeholde IP-adressen på den mest passende navneserver, som anmodningen skal sendes til næste; Opløseren kan derefter sende en anden anmodning til den, mere passende navneserver.

Hvis du har brug for det, kan du også søge på domænenavnet, hvis alt hvad du har er IP-adressen. Dette kaldes et omvendt DNS-opslag.

Når forespørgslen når en navneserver, der indeholder de ønskede datafiler, kan forespørgslen løses. Navneservere har et antal datafiler tilknyttet, hvoraf alle eller nogle kan bruges til at løse forespørgslen.

Ressourceoptegnelser (RR'er)

Dette er datafiler i domænenavnsområdet. Disse datafiler har specifikke formater og indhold.

De mest almindelige RR'er:

  • En post: hvis du ikke har hørt om andre RR'er undtagen denne, ville det give mening. Det er sandsynligvis den mest kendte RR og indeholder IP-adressen på det givne domæne.
  • CNAME Record: Hvis du ikke har hørt om andre RR'er undtagen denne og A-posten, ville det også give mening. "C" står for "kanonisk" og bruges i stedet for en A-post til at tildele et alias til et domæne.
  • SOA Record: denne post indeholder administrative oplysninger om den, inklusive administratorens e-mail-adresse. Tip: Hvis du administrerer en zone, skal du sørge for, at der er en gyldig e-mail-adresse her, så folk kan komme i kontakt med dig, hvis det er nødvendigt.
  • Andre vigtige Resource Record (RR) typer er PR, NS, SRV og MX. Læs om dem her.

Caching og tid til live (TTL)

Når den lokale navneserver modtager et svar fra en forespørgsel, cachelager den dataene (gemmer dem i hukommelsen), så næste gang den modtager den samme forespørgsel, kan den bare besvare forespørgslen direkte i stedet for at gennemgå den oprindelige, længere opløsningsproces.

Men når disse oplysninger er cachelagret, er de både statiske og isolerede og risikerer derfor at blive forældede. Derfor har ressourceposter alle det, der kaldes en TTL-værdi ( time to live ), som dikterer, hvor længe disse data kan caches. Når den tid løber ud (når nul), sletter navneserveren posten.

Vigtig note: TTL gælder ikke for de navneservere, der er autoritative for den zone, der indeholder ressourceposten. Det gælder kun navneserveren, der cachelagrede ressourceoptegnelsen.

En dag i en forespørgsels liv

Vi har dækket meget grund i denne artikel, og det har været tungt for koncepterne. For at binde det hele sammen og gøre det rigtigt, her er en dag (figurativ dag) i en forespørgsels liv.

Så hvorfor har jeg brug for at vide alt dette?

Der er så mange grunde til at være fortrolige med DNS- og IP-adresserelaterede begreber.

  • For det første er det en rygrad på Internettet, den ting mange af os bruger, udvikler følelser for (kærlighed / had / you-name-it) og tager for givet hver dag. Det er vigtigt at være fortrolig med de strukturer, der gør det muligt for os at udrette store ting i dag med teknologi og internettet i dag.
  • Utroligt smarte mennesker brugte årtier af deres liv på at bygge disse ting! Lad os anerkende og værdsætte deres bidrag.
  • Nu hvor jeg fik de sprudlende ting ud af vejen, er det vigtigt at være fortrolig med DNS-koncepter, hvis du er ansvarlig for noget, der vedrører infrastruktur i din virksomhed eller dit team eller din egen virksomhed. At have en referenceramme, når vigtige problemer dukker op, giver dig mulighed for at handle så meget hurtigere og finde løsninger meget hurtigere.

Konklusion

På dette tidspunkt skal du forstå, hvad DNS er, og hvad en navneserver er, samt være fortrolig med tekniske begreber, der vedrører IP-adresser.

Mange bøger er blevet skrevet om og dykker dybere ned i den fascinerende verden af ​​DNS, og der er så meget mere at lære. De emner, der ikke var inkluderet i denne artikel, men som enten er en del af DNS eller meget relaterede, inkluderer:

  • Navneserverimplementeringer
  • Videresendelse
  • (Mere om) node-etiketter
  • Primære og sekundære navneserverforhold
  • Genudsendelsesalgoritmer
  • Belastningsafbalancering
  • Plus andre mere generelle emner om, hvordan Internettet fungerer, som:
  • Internettet
  • HTTP
  • FTP
  • Kommunikationsprotokollag: linklag, IP-lag, transportlag, internetlag osv.

For dem af jer, der stadig læser ogønsker at lære mere om DNS, anbefaler jeg først og fremmest “DNS and BIND, 5th Ed.”, skrevet af Cricket Liu og udgivet af O'Reilly Media. Det er uvurderligt.

Jeg opfordrer også alle til at stikke rundt i den oprindelige anmodning om kommentarer (RFC'er) linket nedenfor. Der er ikke kun punkter til læsning af primære kilder, men de er også usædvanligt velorganiserede og forståelige dokumenter, hvorfor jeg citerede dem i denne artikel.

Ressourcer

  1. RFC 1034: DOMÆNENAVNE - KONCEPTER OG FACILITETER
  2. RFC 1035: DOMÆNENAVNE - GENNEMFØRELSE OG SPECIFIKATION
  3. RFC 1122: Krav til internetværter - kommunikationslag
  4. Mere om DNS-designmål fra Connected: An Internet Encyclopedia
  5. Hvordan Internettet blev født fra ARPAnet til fortolkningen, fra samtalen
  6. Learning DNS Video Course, af Cricket Liu, fra O'Reilly Media

Lidt om mig

Jeg er Chloe Tucker, kunstner og udvikler i Portland, Oregon. Som tidligere underviser søger jeg løbende efter skæringspunktet mellem læring og undervisning eller teknologi og kunst. Kontakt mig på Twitter @_chloetucker og tjek min hjemmeside på chloe.dev.