Mis on DNS? Domeeninimede süsteemi, DNS-serveri ja IP-aadressi mõisted on selgitatud

Sissejuhatus

Selle artikli lõpuks peaksite paremini mõistma järgmist:

  1. Mis on DNS ja mida see teeb
  2. Mida teevad DNS-serverid
  3. Kuidas toimivad Interneti-protokolli (IP) aadressid DNS-i kontekstis

Olulised mõisted

DNS-i, DNS-serverite ja IP-aadresside tundmaõppimiseks peavad olema mõned olulised vaimsed mudelid. Enne DNS-i tundma õppimist on nende mõistete üle minek

  • aidata mõtestada kõiki erinevaid mudeleid sobiva käitumise kirjeldamiseks kasutatavaid mõisteid ja
  • abi mälu säilitamisel.

Vaimsed mudelid annavad teile võrdlusraami, kui asjad muutuvad veidi imelikuks ja harjumatuks.

Nii et paneme aluse.

  • Päring ja vastus. See on siis, kui Thing 1 küsib Thing 2-lt midagi ja Thing 2 vastab sellele taotlusele. Nagu nii:
  • Vanema ja lapse sõlmede suhted ja graafikud, mis näevad välja sellised (ainult keerulisemad).
  • Sõnumid. See pole päring ja vastus, sest vastust pole. DNS-i maailmas on sõnumite vormindus ja sisu vastavalt kasutusele erinev.
  • Kliendi-serveri suhe. Kõige lihtsamalt öeldes on server tarkvara- või riistvaraseade, mis pakub funktsionaalsust teistele tarkvara- või riistvaraseadmetele, mida nimetatakse klientideks.

    Valmistuge serveritest palju rääkima. Nagu selgub, on palju servereid, mis tegelevad selle asjaga, mida kutsume DNS-iks, ja kuidas me inimestena seda Interneti-ühenduse loomisel kasutame.

Mis on DNS?

Domeeninimede süsteem (DNS) kaardistab inimestele loetavad domeeninimed (URL-ides või e-posti aadressides) IP-aadressidena. Näiteks tõlgib ja kaardistab DNS domeeni freecodecamp.org IP-aadressile 104.26.2.33.

Selle kirjelduse täielikuks mõistmiseks on selles jaotises üksikasjad:

  • Ajalooline kontekst DNS-i arendamiseks - milliseid probleeme see lahendas ja IP-aadresse lahendati?
  • Domeeninimed
  • IP-aadressid

Ajalooline kontekst

1966. aastal asutas USA valitsusasutus Advanced Research Projects Agency (ARPA) arvutivõrgu nimega ARPAnet. Lihtsamalt öeldes mõelge ARPAnetist kui esimesest kordusest sellest, mida me täna Internetina teame.

ARPAneti peamised eesmärgid on lisatud

„(1) usaldusväärse side pakkumine isegi seadme osalise või võrgutõrke korral, (2) võimalus luua ühendust erinevat tüüpi arvutite ja operatsioonisüsteemidega ning (3) olla pigem koostöö kui monopool, mida kontrollib üks korporatsioon. Usaldusväärse side pakkumiseks seadmete rikete korral kujundati ARPANET nii, et ükski punkt ega link poleks kriitilisem kui ükski teine. Sellega kaasnes üleliigsete marsruutide rajamine ja andmete otsesuunalise marsruudi kasutamine, kui mõni võrguosa ebaõnnestus. "

Probleemid

DNS ja TCP / IP olid ARPAnetiga kahe probleemi lahendamisel kriitilised:

ARPAneti jaoks oli olemas üks asukoht (fail nimega HOSTS.TXT), mis sisaldas kõigi võrgus olevate hostide kogu nime-aadressi vastendamist.

"HOSTS.TXT-i haldas SRI võrguinfokeskus (dubleeritud" NIC- iks ") ja seda levitati ühelt hostilt, SRI-NIC. NIC ja haaras praeguse faili HOSTS.TXT. Nende muudatused koondati üks või kaks korda nädalas uueks failiks HOSTS.TXT . "

Selle seadistusega oli kolm väljakutset:

  1. Liiklus ja koormus - faili levitamine muutus vastutustundlikul hostil liigseks käsitsemiseks.
  2. Nimede kokkupõrked - igal hostil pidi olema unikaalne nimi ja puudus tsentraliseeritud asutus, mis ei takistaks võrgukasutajaid vastuolulise (mitte kordumatu) nimega masina lisamisest, rikkudes seeläbi kogu skeemi.
  3. Järjepidevus - faili värskendamine ja kõigi hostide kõige uuema versiooni tagamine muutus võimatuks või vähemalt väga raskeks.

Sisuliselt oli HOSTS.TX üks ebaõnnestumispunkt, nii et kogu siinne protsess ei ulatunud teatud hosti kaugemale. ARPAnet vajas detsentraliseeritud ja skaleeritavat lahendust. DNS oli see. Allikas

Host-to-host suhtlus samas võrgus ei olnud piisavalt usaldusväärne. TCP / IP aitas selle probleemi lahendada.

  1. Edastusjuhtimise protokoll (TCP) pakub kvaliteedi tagamise meetmeid sõnumite (hostide vahel) pakettideks muutmise protsessiks. TCP protokoll on ühendusele orienteeritud, mis tähendab, et tuleb luua ühendus lähte- ja sihtkoha hosti vahel.
  2. Interneti-protokoll (IP) määratleb, kuidas sõnumeid (pakette) kantakse lähte- ja sihtkoha hostide vahel. IP-aadress on konkreetse tee kordumatu identifikaator, mis viib võrgus oleva hostini.
  3. TCP ja IP teevad tihedat koostööd, mistõttu viidatakse neile tavaliselt näiteks „TCP / IP”.
  4. Kuigi selles artiklis ma sellesse ei süvene, kasutatakse DNS-i andmeedastuskihis nii TCP-d kui ka User Datagram Protocol (UDP). UDP on kiirem, palju vähem usaldusväärne ja ei vaja ühendusi; TCP on aeglasem, palju usaldusväärsem, kuid vajab ühendusi. Neid kasutatakse DNS-is vastavalt vajadusele ja sobivusele; Ütlematagi selge, et TCP lisamine APRAnetesse oli väärtuslik täiendus andmeedastuskihile.

1980. aastate alguseks olid DNS ja TCP / IP (ja seega ka IP-aadressid) ARPAneti tavapärased tööprotseduurid.

See ajalugu on väga lühike. Kui soovite nende teemade kohta lisateavet, lugege palun selle artikli lõpus jaotist Ressursid.

Nüüd, kui meil on ajalooline kontekst, liigume edasi domeeninimede ja IP-aadresside kohta lisateabe saamiseks.

Domeeninimed

DNS-i kontekstis pakub domeeninimi kasutajasõbralikku viisi osutamiseks mitte-kohalikele ressurssidele. See võib olla veebisait, meilisüsteem, prindiserver või mõni muu Internetis saadaval olev server. Domeeninimi võib olla midagi enamat kui lihtsalt veebisait!

"Domeeninimede eesmärk on pakkuda ressursside nimetamise mehhanism nii, et nimed oleksid kasutatavad erinevates hostides, võrkudes, protokolliperekondades, Interneti-ühendustes ja haldusorganisatsioonides."

Domeeninime on palju lihtsam meelde jätta ja terminali või Interneti-brauserisse sisestada kui IP-aadressi.

Domeeninimi on osa ühtsest ressursilokaatorist (URL), kuid need terminid pole sünonüümid . URL on ressursi täielik veebiaadress, domeeninimi aga veebisaidi nimi ja on iga URL-i alamkomponent.

Kuigi URL-idel ja domeeninimedel on tehnilisi erinevusi, kohtlevad veebibrauserid neid tavaliselt samamoodi, nii et jõuate veebisaidile, kui sisestate täieliku veebiaadressi või lihtsalt domeeninime.

Tipptaseme domeenid ja teise taseme domeenid

Igas antud domeenis on kaks osa: tipptasemel domeen (TLD) ja teise taseme domeen (SLD). Domeeninime osad muutuvad täpsemaks, kui liigutakse paremalt (lõpult) vasakule (algus).

See võib esialgu segadust tekitada. Vaatame näiteks veebisaiti “freecodecamp.org”

  • URL: //www.freecodecamp.org
  • Domeeninimi: freecodecamp.com
  • TLD: org
  • SLD: freecodecamp

ARPAneti algusaegadel oli saadaval piiratud arv tippdomeene, sealhulgas com, edu, gov, org, arpa, mil ja kahetähelised riigikoodidomeenid. Need tippdomeenid olid algselt reserveeritud ARPAnetis osalevatele asutustele, kuid mõned said hiljem kommertsturgudel kättesaadavaks.

Praegu on saadaval olevate tippdomeenide võrdlev arvukus, sealhulgas net, aero, biz, coop, info, muuseum, nimi ja teised.

Teise taseme domeenid on domeenid, mida saab domeeni registreerijate kaudu eraldi osta (näiteks Namecheap).

IP-aadressid

Kuigi IP-aadressid on oma funktsiooniga seotud DNS-iga, on Interneti-protokoll ise DNS-ist tehniliselt eraldatud. Olen selle eristamise jaoks juba ajaloolise konteksti esitanud, nii et nüüd selgitan, kuidas IP-aadressid toimivad.

Nagu eelnevalt mainitud, on IP-aadress unikaalne identifikaator konkreetsele teele, mis viib võrgus oleva hostini. Tahaksin viidata telefoninumbri ja telefoni analoogiale: telefoninumber ei tähenda telefoni ennast, see on lihtsalt viis telefoniga inimeseni jõudmiseks.

See analoogia on mõistlikult asjakohane (vähemalt pinnatasandil) koos IP-aadressidega. IP-aadress tähistab lõpp-punkti, kuid see pole lõpp-punkt ise. IP-määrangud võivad olla fikseeritud (püsivad) või dünaamilised (paindlikud ja neid saab uuesti määrata).

Nagu domeeninimi, järgib IP-aadresside korraldus hierarhilist struktuuri. Erinevalt domeeninimedest saavad IP-aadressid vasakult paremale liikudes täpsemad. See on allpool toodud IPv4 näide:

Diagramm näitab, et 129.144 on IPv4-aadressi võrguosa ja 50.56.
  • Võrk: teie võrgule määratud kordumatu number
  • Host: tuvastab võrgus oleva hosti (masina)

Kui on vaja suuremat täpsust, saavad võrguadministraatorid alamvõrgu aadressiruumi ja delegeerida täiendavaid numbreid.

Mitu IP-aadressi on olemas?

IPv4 oli esimene IP kordus, mida ARPAnet tootmisel kasutas. 80-ndate alguses juurutatud on see endiselt kõige levinum IP-versioon. See on 32-bitine skeem ja võib seetõttu toetada veidi üle 4 miljardi aadressi.

Aga oota, kas sellest piisab? Ei.

IPv6-l on 128-bitine skeem, mis võimaldab tal toetada 340 undecillioni aadressi. Samuti pakub see IPv4 jõudluse täiustusi.

Näide IPv4-aadressist:

  • 104.26.2.33 (freeCodeCamp)

Näide IPv6-aadressist:

  • 2001: db8: a0b: 12f0 :: 1 (tihendatud formaat ja ei osuta freeCodeCampile)

Kuidas domeeninimede süsteem töötab?

Nii oleme õppinud domeeninimede kohta! Oleme õppinud IP-aadresside kohta! Kuidas on need siis domeeninimede süsteemiga seotud?

Esiteks sobivad need nimeruumi.

Domeeninimeruum

Nagu osutab keel "ülemise" taseme ja "teise" taseme domeen, põhineb nimeruum hierarhial

"... hierarhiaga, mis vastab ligikaudu organisatsioonilisele struktuurile, ja nimed" "abil. tähemärgina, mis tähistab piiri hierarhiatasandite vahel. " Allikas.

See puu graafik, mille juur on ülaosas, illustreerib struktuuri kõige paremini:

Jaotame selle, alustades ülaosast.

Selle graafiku ülaosa, tähistatud tähega. nimetatakse juureks.

„Autentsed nimeserverid, mis teenindavad DNS-i juurtsooni, on üldtuntud kui„ juurserverid “, on sadade serverite võrk paljudes maailma riikides. Need on DNS-i juurvööndis konfigureeritud 13 nimega asutuseks. "

Juurdomeenil on nullpikk silt.

Siit edasi on graafiku igal sõlmel (punktil) ainulaadne silt, mille pikkus on kuni 63 tähemärki.

Esimene juurest allpool asuv tase on TLD-d: com, org, edu ja gov. Pange tähele, et see graafik ei sisalda tippdomeenide täielikku loendit.

TLD-de all on SLD-d, teise taseme domeenid. Iga sõlme lapsi nimetatakse “alamdomeenideks”, mida peetakse endiselt vanemdomeeni osaks. Näiteks saidil freecodecamp.org on freecodecamp (SLD) org (TLD) alamdomeen.

Sõltuvalt veebisaidi hierarhiast võib olla kolmanda, neljanda, viienda taseme domeene. Näiteks hüpoteetilises-alamdomeenis.freecodecamp.org on hüpoteetiline-alamdomeen kolmanda taseme domeen ja vabakoduliku alamdomeen. Nii edasi ja nii edasi, vähemalt kuni 127 taset, mis on DNS-i maksimaalne lubatud.

Kes haldab nimeruumi?

Kas poleks pähkel proovida lasta ühel inimesel või organisatsioonil kõike hallata? Jah, oleks. Eelkõige seetõttu, et DNS-i üks peamisi disainieesmärke oli kogu süsteemi hajutatud, detsentraliseeritud haldamise edendamine.

Ma soovin teile öelda, et vastutavaid inimesi nimetatakse "nimeruumi kuningateks", kuid kahjuks.

Iga domeen (või alamdomeen) domeeninimeruumis on või on osa tsoonist , "autonoomselt hallatavast nimeruumi tükist". Niisiis, nimeruum on jaotatud tsoonideks.

Vastutust nende tsoonide eest juhitakse delegeerimise ja halduse kaudu.

Alamdomeenide vastutuse teistele üksustele määramise protsessi nimetatakse delegeerimiseks.

Näiteks haldab avaliku huvi register domeeninime org ja on alates 2003. aastast. Avalike huvide register võib delegeerida teistele osapooltele vastutuse org-alamdomeenide haldamise eest, näiteks freecodecamp. Ja siis see, kes haldab freecodecampi, võib määrata vastutuse freecodecampi alamdomeenide (näiteks hüpoteetiline-domeenid.freecodecamp.com) eest teisele osapoolele.

Kui keegi (organisatsioon, meeskond või üksikisik) haldab tsooni, haldab ta tsooni eest vastutavat nimeserverit.

See viib meid domeeninimede süsteemi kõige põhilisemate mõistete juurde.

Domeeninimede serverid

"Programme, mis salvestavad teavet domeeninimeruumi kohta, nimetatakse nimeserveriteks."

Siinkohal on kasulik vähemalt esialgu mõelda kliendi ja serveri suhtele. Domeeninimeserverid on kliendi-serveri suhte serveri pool. Nimeserverid võivad laadida ühte, sadu või isegi tuhandeid tsoone, kuid nad ei laadi kunagi tervet nimeruumi. Kui nimeserver on laadinud tsooni kogu, on see selle tsooni jaoks autoriteetne .

Selleks, et mõista, miks nimeserverid toimivad nii, nagu on, on kasulik mõista suhte “klient” osa.

Lahendajad

DNS-is nimetatakse klienti (teabe taotlejat) lahendajaks, mis võib alguses tunduda tagurlik. Kas seda päringut lahendavat serverit ei nimetata lahendajaks? Ma arvasin ka nii, aga see pole nii. Parim on see lihtsalt meelde jätta ja edasi minna.

Lahustid on tavaliselt de facto kaasatud enamikku opsüsteemidesse, nii et OS-ile installitud rakendused ei pea välja mõtlema, kuidas teha madalama taseme DNS-päringuid.

DNS-päringud ja nende vastused on teatud tüüpi DNS-sõnumid ja neil on oma andmeedastusprotokoll (tavaliselt UDP). Resolvers vastutab selle eest, et OS-ile installitud rakendused aitaksid DNS-iga seotud päringuid DNS-päringuteks teisendada.

Kokkuvõttes vastutavad lahendajad andmete taotluste pakkimise ja saatmise eest. Kui lahendaja on vastuse kätte saanud (kui seda üldse on), edastab ta selle tagasi algsele taotlevale rakendusele taotleva rakenduse jaoks tarvitatavas vormingus.

Tagasi nimeserverite juurde

Nüüd, kui oleme suhte kliendipoolega veidi paremini kursis, peame mõistma, kuidas domeeninimeserverid lahendaja päringutele reageerivad.

Nimeserverid vastavad DNS-päringutele lahenduse abil . Resolutsioon on protsess, mille käigus nimeserverid leiavad andmeruumid nimeruumist. Sõltuvalt päringu tüübist vastavad nimeserverid erinevatele päringutele erinevalt, kuid lõppeesmärk on lahutus.

Päringute tüübid

Päringu tüüp? Jah, DNS-päringuid on mitut tüüpi. Esiteks, mis tavaliselt on DNS-päringus? See on teabepäring, täpsemalt domeeninimega seotud IP-aadressi kohta.

  • Rekursiivsed : rekursiivsed päringud võimaldavad lahendada päringu suunamise mitmele nimeserverile. Kui esimesel küsitletud nimeserveril pole soovitud andmeid, siis saadab see nimeserver päringu kõige sobivamale järgmisele nimeserverile, kuni soovitud andmefailidega nimeserver on leitud ja lahendajale vastuse saadab.
  • Iteratiivne : iteratiivsed päringud nõuavad, et päritud nimeserver vastaks kas soovitud andmetega või veaga. Vastus võib sisaldada järgmisele päringule saatmiseks kõige sobivama nimeserveri IP-aadressi; lahendaja võib seejärel saata sellele teisele taotlusele sobivama nimeserveri.

Kui teil seda vaja on, võite päringu teha ka domeeninime kohta, kui teil on ainult IP-aadress. Seda nimetatakse DNS-i pöördotsinguks.

Kui päring jõuab soovitud andmefaile sisaldavasse nimeserverisse, saab päringu lahendada. Nimeserveritel on nendega seotud mitu andmefaili, millest kõiki või mõnda võib kasutada päringu lahendamiseks.

Ressursikirjed (RR)

Need on domeeninimeruumis olevad andmefailid. Nendel andmefailidel on konkreetsed vormingud ja sisu.

Kõige tavalisemad RR-id:

  • Rekord: kui te pole veel ühtegi muud RR-i kuulnud, välja arvatud see, oleks mõistlik. See on tõenäoliselt tuntuim RR ja sisaldab antud domeeni IP-aadressi.
  • CNAME-kirje: kui te pole veel ühtegi muud RR-i kuulnud, välja arvatud see ja A-rekord, oleks see ka mõistlik. "C" tähistab "kanoonilist" ja seda kasutatakse A-kirje asemel domeenile varjunime määramiseks.
  • SOA-kirje: see kirje sisaldab selle üksuse haldusteavet, sealhulgas administraatori e-posti aadressi. Vihje: kui haldate tsooni, veenduge, et siin oleks kehtiv e-posti aadress, et inimesed saaksid teiega vajadusel ühendust võtta.
  • Teised olulised ressursikirje (RR) tüübid on PR, NS, SRV ja MX. Loe nende kohta siit.

Vahemällu salvestamine ja aeg elada (TTL)

Kui kohalik nimeserver saab päringult vastuse, salvestab ta need andmed vahemällu (salvestab need mällu), nii et järgmine kord, kui ta saab sama päringu, saab ta lihtsalt päringule otse vastata, mitte läbida algse pikema eraldusvõime.

Kuid kui see teave on vahemällu salvestatud, on see nii staatiline kui ka isoleeritud ning seetõttu on oht, et see aegub. Seetõttu on kõigil ressursikirjetel nn aeg elada (TTL), mis määrab, kui kaua neid andmeid vahemällu salvestada saab. Kui see aeg saab otsa (jõuab nulli), kustutab nimeserver kirje.

Oluline märkus: TTL ei kehti nimeserverite kohta, mis on ressursikirjet sisaldava tsooni jaoks autoriteetsed. See kehtib lihtsalt selle ressursikirje vahemällu salvestatud nimeserveri kohta.

Päev päringu elus

Selles artiklis oleme käsitlenud palju maad ja see on mõistetele raske olnud. Selle kõige sidumiseks ja reaalseks muutmiseks on siin üks päev (kujundlik päev) päringu elus.

Miks ma pean seda kõike teadma?

DNS-i ja IP-aadressiga seotud mõistete tundmiseks on nii palju põhjuseid.

  • Esiteks on see Interneti selgroog, asi, mida paljud meist kasutavad, tekitavad tundeid (armastus / vihkamine / nimetate-seda) ja võtavad iga päev enesestmõistetavaks. Oluline on olla kursis struktuuridega, mis võimaldavad meil täna tehnoloogia ja Interneti abil suurepäraseid asju saavutada.
  • Uskumatult targad inimesed veetsid oma kraami ehitades aastakümneid oma elust! Tunnustagem ja hindagem nende panust.
  • Nüüd, kui mul on ebameeldiv värk eemal olnud, on oluline teada DNS-i kontseptsioone, kui vastutate oma ettevõtte või meeskonna või oma ettevõtte infrastruktuuriga seotud asjade eest. Kui teil on oluliste probleemide ilmnemisel raamistik, saate tegutseda palju kiiremini ja leida lahendusi palju varem.

Järeldus

Siinkohal peaksite mõistma, mis on DNS ja mis on nimeserver, samuti tundma IP-aadressidega seotud tehnilisi mõisteid.

Paljudest raamatutest on kirjutatud ja sukeldutakse sügavamale DNS-i põnevasse maailma ning seal on veel palju õppida. Teemad, mida see artikkel ei sisaldanud, kuid mis on kas osa DNS-ist või on väga seotud, hõlmavad järgmist.

  • Nimeserveri juurutused
  • Edastamine
  • (Lisateave) sõlmesiltide kohta
  • Esmase ja teisese nimeserveri suhted
  • Edasisaatmise algoritmid
  • Koormuse tasakaalustamine
  • Lisaks muud üldisemad teemad Interneti toimimise kohta, näiteks:
  • Veeb
  • HTTP
  • FTP
  • Sideprotokolli kihid: lingikiht, IP-kiht, transpordikiht, Interneti-kiht jne.

Neile teist, kes veel loete jasoovid DNS-i kohta lisateavet, soovitan kõigepealt Cricket Liu kirjutatud ja O'Reilly Media välja antud "DNS and BIND, 5. väljaanne". See on hindamatu.

Samuti soovitan kõigil allpool lingitud algsetes kommentaaritaotlustes (RFC-d) ringi torgata. Lisaks esmaste allikate lugemisele on punkte, kuid need on ka erakordselt hästi korraldatud ja arusaadavad dokumendid, mistõttu tsiteerisin neid selles artiklis.

Ressursid

  1. RFC 1034: Domeeninimed - kontseptsioonid ja võimalused
  2. RFC 1035: Domeeninimed - rakendamine ja spetsifikatsioon
  3. RFC 1122: nõuded Interneti-hostidele - sidekihid
  4. Lisateavet DNS-i disainieesmärkide kohta leiate saidilt Connected: Internet Encyclopedia
  5. Kuidas sündis Internet ARPAnetist tõlgendamiseni, vestlusest
  6. Cricket Liu DNS-videokursuse õppimine O'Reilly Mediast

Natuke minust

Olen Chloe Tucker, kunstnik ja arendaja Portlandis, Oregonis. Endise koolitajana otsin pidevalt õppimise ja õpetamise või tehnoloogia ja kunsti ristmikku. Võtke minuga ühendust Twitteris @_chloetucker ja vaadake minu veebisaiti aadressil chloe.dev.