Pregled DNS terminologije, komponenti i koncepata

DNS (Domain Name System) jedna je od ključnih komponenti koje pokreću internet. Ispravno razumijevanje načina na koji DNS radi može pomoći u dijagnosticiranju problema s konfiguracijom web stranice i proširiti vaše razumijevanje onoga što se događa iza kulisa.

U ovom vodiču govorit ćemo o nekim temeljnim konceptima DNS-a kako bismo vam pružili čvrste temelje pri radu s vašom DNS konfiguracijom. Ovaj vodič će vam također pomoći da postavite vlastiti naziv domene ili DNS poslužitelj.

Krenimo!

Terminologija domena

Najprije moramo uspostaviti razumijevanje pojmova koje ćemo koristiti. Možda ste s nekima od njih već upoznati iz drugih konteksta. Međutim, postoji mnogo specifičnih pojmova kada se govori o nazivima domena i DNS-u o kojima se ne raspravlja puno u drugim područjima računalstva.

• Sustav naziva domena

Sustav naziva domena (skraćeno DNS) je mrežni sustav koji pretvara ljudima prilagođene nazive domena u jedinstvene IP adrese.

• Naziv domene

Naziv domene odnosi se na ljudima prilagođen naziv koji se koristi za povezivanje s internetskim resursom. Na primjer, “cloudsigma.com” je naziv domene. Neki bi mogli tvrditi da je samo dio “cloudsigma” naziv domene, ali općenito se to odnosi na cjelinu.

URL “cloudsigma.com” povezan je s poslužiteljima u vlasništvu tvrtke CloudSigma. Prilikom unosa URL-a u web preglednik, on komunicira s DNS-om kako bi se povezao s IP adresom ciljanog poslužitelja.

• IP adresa

IP adresa djeluje kao mrežna adresa za uređaj spojen na mrežu. Svaka IP adresa mora biti jedinstvena unutar mreže. U kontekstu web stranica, mreža je, većinom, cijeli internet.

Postoje dvije vrste IP adresa:

• • IPv4: Ovo je najčešći oblik IP adrese. Piše se kao skup od četiri broja, pri čemu svaki skup ima do 3 znamenke. Svaki skup je odvojen točkom. Raspon IPv4 je od 0.0.0.0 do 255.255.255.255.

  • IPv6: To je moderniji standard koji je razvijen kako bi se riješio problem iscrpljivanja IPv4 adresa. IPv4 podržava do 232 jedinstvene adrese, dok IPv6 podržava do 2128 adresa. Svaka IPv6 adresa piše se heksadecimalnim znamenkama. Može sadržavati do 32 znamenke, podijeljene u 8 odjeljaka (po 4 znamenke u svakom odjeljku). Svaki odjeljak odvojen je dvotočkom (:).

Domena najviše razine

Domena najviše razine (skraćeno TLD) je najopćenitiji dio domene. Odnosi se na krajnji desni dio (odvojen točkom). Neke od uobičajenih domena najviše razine uključuju:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

U pogledu naziva domena, ove domene su na vrhu hijerarhije. ICANN (Internet Corporation for Assigned Names and Numbers) može izdati dozvolu za kontrolu određenih strana nad domenama najviše razine. Uz dopuštenje, te strane mogu distribuirati nazive domena pod TLD-om (obično putem registrara domena).

• Hostovi

Unutar domene, vlasnik može odrediti pojedinačne hostove, što se odnosi na zasebne strojeve/usluge dostupne putem domene. Na primjer, uobičajena je praksa da se web poslužitelji učine dostupnima putem same domene ( example.com) i definicije “hosta” “www  ( www.example.com).

Moguće je imati dodatne hostove pod općom domenom, na primjer, API pristup putem hosta “api” ( api.example.com), FTP pristup putem hosta “ftp” ili “files” ( ftp.example.com ili files.example.com).

Imajte na umu da nazivi domena mogu biti proizvoljni sve dok su jedinstveni unutar domene.

• Poddomena

Poddomena je pojam povezan s hostovima. DNS funkcionira u hijerarhiji. TLD može imati mnogo domena ispod sebe. Na primjer, “ example.com”, “ cloudsigma.com”, itd. svi su pod vršnom domenom (TLD) “com”. U tom smislu, poddomena je referenca na bilo koju domenu koja je dio ciljne domene. Stoga možemo reći da je “example.com” poddomena od “com”. Općenito, dio “example” naziva se SLD (domena druge razine).

Slično tome, domena može kontrolirati sve “poddomene” koje se nalaze pod njom. To je obično ono na što se pojam “poddomena” odnosi. Na primjer, “ history.example.com” je poddomena od “ example.com”.

Ključna razlika između hostnamea i poddomene je u tome što host definira računalo/resurs, dok poddomena proširuje nadređenu domenu. Kad god govorimo o poddomenama ili hostovima, u to se možete uvjeriti gledajući krajnji lijevi dio domene jer je on najspecifičniji. Tako DNS funkcionira: od najspecifičnijeg (krajnje lijeve strane) do najmanje specifičnog (krajnje desne strane).

• Potpuno kvalificirani naziv domene

Potpuno kvalificirani naziv domene (skraćeno FQDN) odnosi se na apsolutni naziv domene. U DNS sustavu domene se mogu navesti relativno jedna u odnosu na drugu. To može dovesti do određene dvosmislenosti. FQDN je, međutim, apsolutni naziv koji se odnosi na apsolutni korijen sustava naziva domena.

To znači da FQDN specificira svaku nadređenu domenu uključujući TLD. Pravi primjer bio bi “ mail.google.com”. U specifičnim slučajevima, FQDN možda ne završava točkom, ali mora imati završnu točku (što zahtijevaju standardi ICANN-a).

• Poslužitelj naziva

Poslužitelj naziva je namjensko računalo za prevođenje naziva domena u IP adrese. Poslužitelji naziva podnose najveći dio opterećenja u DNS sustavu. Budući da je ukupan broj zahtjeva za prevođenje domena prevelik da bi ga obradio jedan poslužitelj, zahtjevi se često preusmjeravaju na druge poslužitelje naziva kako bi se smanjio pritisak.

Poslužitelj naziva može biti “autoritativan”, što znači da daje odgovore samo na upite o domenama pod svojom kontrolom. Takvi poslužitelji mogu proslijediti zahtjev drugim poslužiteljima naziva ili poslužiti predmemoriranu kopiju podataka drugih poslužitelja naziva.

• Zonska datoteka

Zonska datoteka je tekstualna datoteka koja sadrži mapiranja između naziva domena i IP adresa. Služi kao baza podataka DNS sustava. To je katalog koji DNS koristi kako bi pronašao s kojom IP adresom treba uspostaviti kontakt prilikom ispunjavanja korisničkog zahtjeva za određeni naziv domene.

Općenito, poslužitelji naziva udomljuju zonske datoteke i definiraju resurse dostupne pod jednom domenom. Također mogu sadržavati informacije o tome kamo otići da bi se dobile te informacije.

• Zapisi

Zonska datoteka sastoji se od brojnih zapisa. Ovdje se zapis definira kao jedno mapiranje između resursa i naziva. Zapisi mogu biti mapiranje naziva domene u IP adresu, resursi dostupni pod određenom domenom ili reference na mjesta gdje se mogu dobiti informacije.

DNS na djelu

Do sada smo se upoznali s nekim uobičajenim terminima vezanim uz DNS. Međutim, kako sustav zapravo radi? Sustav se može činiti vrlo jednostavnim na visokoj razini. Unatoč tome, dublje ulaženje u detalje otkrit će njegovu stvarnu složenost. Općenito, DNS sustav je važan za široko usvajanje interneta.

• Korijenski poslužitelji

DNS u svojoj srži funkcionira u hijerarhiji. Na vrhu sustava nalaze se “korijenski poslužitelji”. Ti su poslužitelji pod kontrolom različitih organizacija. Ovlasti nad tim poslužiteljima delegira ICANN (Internet Corporation for Assigned Names and Numbers).

Trenutačno je u funkciji oko 13 korijenskih poslužitelja. Međutim, zbog opterećenja, svaki od tih poslužitelja ima svoje zrcalne poslužitelje. Važno je napomenuti da svi zrcalni poslužitelji dijele istu IP adresu kao i korijenski poslužitelj. Kad god se uputi zahtjev korijenskom poslužitelju, zahtjev se preusmjerava na najbliži zrcalni poslužitelj tog poslužitelja.

Koje su zadaće korijenskih poslužitelja? Oni pružaju informacije o vršnim domenama. Kad god poslužitelj naziva niske razine ne uspije razriješiti zahtjev, on se preusmjerava na korijenski poslužitelj domene.

Međutim, korijenski poslužitelj zapravo ne zna lokaciju domene. On samo preusmjerava zahtjev koji će obraditi specifično traženu vršnu domenu. Na primjer, ako se podnese zahtjev za “ blog.cloudsigma.com”, korijenski poslužitelj to neće imati u svojim zapisima. Pretražit će svoje zonske datoteke, ali za to neće biti nikakvog zapisa. Umjesto toga, prepoznat će “com” TLD i preusmjeriti entitet koji je podnio zahtjev na poslužitelj naziva koji upravlja “com” adresama.

• TLD poslužitelji

Nastavljajući se na naš prethodni primjer, entitet koji je podnio zahtjev sada će poslati zahtjev na IP adresu (koju je osigurao korijenski poslužitelj). U slučaju “ blog.cloudsigma.com”, poslužitelj naziva za “com” pretražit će svoje zapise u svojim zonskim datotekama.

Neće biti zapisa koji odgovara zahtjevu. Međutim, pronaći će zapis koji navodi IP adresu poslužitelja naziva odgovornog za “ cloudsigma.com”.

• Poslužitelj naziva na razini domene

Sada entitet koji je podnio zahtjev ima IP adresu poslužitelja naziva koji zapravo udomljuje informacije o “ blog.cloudsigma.com”. Sada će poslati novi zahtjev poslužitelju, tražeći razrješenje za “www.cloudsigma.com”.

Kao i prije, poslužitelj naziva provjerit će svoje zonske datoteke i pronaći onu povezanu s “ cloudsigma.com”. Unutar ove datoteke nalazit će se unos za poslužitelj “www”. Ovaj zapis opisuje gdje se poslužitelj nalazi. Konačni odgovor se zatim prenosi entitetu koji je podnio zahtjev.

• Poslužitelj naziva za razrješavanje

U primjeru smo spomenuli entitet koji podnosi zahtjev. Što je to? U većini slučajeva, podnositelj zahtjeva bit će “poslužitelj naziva za razrješavanje”. To je poslužitelj koji je konfiguriran za postavljanje pitanja drugim poslužiteljima. Djeluje kao posrednički poslužitelj za korisnike. Pohranjuje rezultate u privremenu memoriju kako bi se poboljšala brzina.

Svaki korisnik obično ima konfigurirano nekoliko poslužitelja naziva za razrješavanje na svom sustavu. Općenito, poslužitelje naziva za razrješavanje nude ISP ili druge organizacije. Na primjer, Google nudi javne DNS poslužitelje za razrješavanje za slanje upita. Možete ih ručno konfigurirati na svom sustavu.

Prilikom unosa URL-a u web preglednik, on traži lokaciju resursa. Prvo se pretraživanje obavlja lokalno. To uključuje datoteku “hosts” (i neke druge lokacije). Ako se ne pronađe, zahtjev se šalje poslužitelju naziva za razrješavanje. Nakon primitka zahtjeva, poslužitelj naziva za razrješavanje pretražuje svoju privremenu memoriju za odgovorom. Ako ga ne pronađe, prolazi kroz prethodno navedene korake.

Poslužitelji naziva za razrješavanje pojednostavljuju proces slanja zahtjeva za krajnjeg korisnika. Klijent samo mora pitati poslužitelje naziva za razrješavanje za lokaciju resursa. Poslužitelj naziva će to istražiti i vratiti konačni odgovor.

• Zonske datoteke

Već smo raspravljali o konceptima “zonskih datoteka” i “zapisa”. Pa, kako oni rade?

Zonske datoteke djeluju kao baza podataka za poslužitelje naziva, pohranjujući informacije o domenama koje su im poznate. Sve domene koje poslužitelj naziva poznaje bit će pohranjene u njegovoj zonskoj datoteci. Međutim, većina zahtjeva koji dolaze na poslužitelj naziva ne razrješava se putem zonske datoteke. Ako je konfiguracija poslužitelja takva da obrađuje rekurzivne upite (na primjer, poslužitelji naziva za razrješavanje), tada će vratiti odgovor. U suprotnom, preusmjerit će stranu koja je podnijela zahtjev na drugo mjesto za daljnje traženje.

Što više zonskih datoteka poslužitelj naziva udomljuje, to će njegovi odgovori biti mjerodavniji. Zonske datoteke opisuju DNS “zonu” (podskup cijelog DNS sustava imenovanja). Općenito, zonska datoteka sadrži konfiguracijske podatke samo jedne domene. Može imati brojne zapise koji definiraju lokaciju resursa dotične domene.

Parametar $ORIGIN zone jednak je najvišoj razini ovlasti zone. Na primjer, zonska datoteka za “ cloudsigma.com” imat će svoj $ORIGIN kao “ cloudsigma.com”. Vrijednost parametra može se pohraniti na početku zonske datoteke ili u konfiguraciji DNS poslužitelja. U svakom slučaju, parametar opisuje za koju je zonu datoteka mjerodavna.

Parametar $TTL postavlja informacije o “vremenu života” (time to live) rezultata koji pruža. Može se opisati kao brojač koji poslužitelj za predmemoriranje može koristiti za praćenje valjanosti predmemoriranih odgovora. Ako vrijednost TTL istekne, odgovor više nije valjan i odbacuje se.

• Vrste zapisa

Zonske datoteke sastoje se od brojnih zapisa. Postoje različite vrste zapisa. U nastavku ćemo proći kroz neke od najčešćih (i obveznih) vrsta zapisa:

SOA zapisi

Zapis Start of Authority (skraćeno SOA) obvezan je u svim zonskim datotekama. Mora biti prvi stvarni zapis u datoteci. Međutim, unosi poput $ORIGIN ili $TTL smiju se pojaviti prije toga.

SOA zapis jedna je od složenijih vrsta zapisa. Njegova struktura izgleda otprilike ovako:

Rastavimo ga na dijelove:

• • example.com: Ovaj dio definira korijen zone. U ovom primjeru, zonska datoteka je za domenu “ example.com”. Ponekad se vrijednost može zamijeniti s @ (rezerviranim mjestom za zamjenu vrijednosti $ORIGIN).

  • IN SOA: Pojam “IN” označava “internet”. Naći ćete ga u mnogim zapisima. Pojam “SOA” označava da se radi o SOA zapisu.

  • ns1.example.com: Ova vrijednost sadrži primarni poslužitelj naziva za domenu “ example.com”. Poslužitelji naziva mogu biti primarni ili sekundarni. Ako je konfiguriran s dinamičkim DNS-om, tada mora postojati jedan “primarni” poslužitelj. Ako dinamički DNS nije konfiguriran, tada će to biti jedan od primarnih poslužitelja naziva.

  • admin.example.com: Ovdje ide e-adresa administratora zone. Imajte na umu da je znak @ ovdje zamijenjen s .. Ako izvorna e-adresa sadrži točku, ona se zamjenjuje s \. Na primjer, “ my.domain@example.com” bi postalo “ my\domain.example.com”.

  • 12083: To je serijski broj zonske datoteke. Svaki put kada se zonska datoteka uređuje, broj se mora ažurirati kako bi se datoteka ispravno proširila. Sekundarni poslužitelji koriste ovaj serijski broj kako bi pratili jesu li njihove vlastite zonske datoteke ažurne.

  • 3h: Predstavlja interval osvježavanja za zonu. Sekundarni poslužitelji čekat će ovoliko vremena prije provjere ažuriranja zonske datoteke.

  • 30m: Ova vrijednost predstavlja interval ponovnog pokušaja zone. Ako se sekundarni poslužitelj ne uspije povezati s primarnim poslužiteljem nakon što istekne razdoblje osvježavanja, čekat će ovoliko vremena prije ponovnog upita primarnom poslužitelju.

  • 3w: Ova vrijednost predstavlja razdoblje isteka. Ako se sekundarni poslužitelj ne uspije povezati s primarnim poslužiteljem tijekom ovog vremenskog razdoblja, prestat će vraćati odgovore kao “mjerodavne”.

  • 1h: Ova vrijednost predstavlja količinu vremena tijekom kojeg će poslužitelj naziva predmemorirati pogrešku naziva ako on nije pronađen u njegovoj zonskoj datoteci.

A i AAAA zapisi

Ovi zapisi uspostavljaju mapiranje između hosta i IP adrese. Ovdje zapis “A” označava IPv4 mapiranje na host, a AAAA IPv6 mapiranje.

Ovo je temeljna struktura zapisa A i AAAA:

U primjeru SOA zapisa, poslužitelj naziva nazvali smo “ ns1.exampel.com”. Poslužitelj naziva spada pod domenu “ example.com”. Evo kako bi izgledao njegov A zapis:

Primijetite da nismo morali navesti puni naziv. Samo s nazivom računala (bez FQDN-a), DNS poslužitelj može popuniti ostatak vrijednošću iz $ORIGIN. Međutim, i dalje možemo koristiti FQDN:

Evo kako definirati web poslužitelj kao “www”:

Također bismo trebali uključiti mapiranje na osnovnu domenu. Zapis bi izgledao ovako:

Alternativno, možemo koristiti @ simbol za označavanje osnovne domene (umjesto njezinog punog naziva):

Dobra je praksa uključiti zamjenski (wildcard) zapis koji omogućuje opciju razrješavanja bilo čega pod ovom domenom što nije eksplicitno definirano:

Ista se struktura primjenjuje na AAAA zapise. Jedina razlika su IPv6 adrese.

CNAME zapisi

CNAME zapisi djeluju kao alias za kanonski naziv poslužitelja (definiran A ili AAAA zapisom). Pogledajte sljedeći primjer:

Ovdje smo upotrijebili “server1” kao alias za definiranje naziva “www”. Imajte na umu da takve prečice utječu na performanse jer poslužitelj mora pokrenuti dodatne upite kako bi dobio konačan odgovor. Ovisno o broju slojeva aliasa, to može lako uzrokovati značajan pad performansi. Međutim, postoji jedan specifičan slučaj koji ima koristi od CNAME aliasa, na primjer, pružanje resursa izvan trenutne zone.

MX zapisi

MX zapisi definiraju poslužitelje e-pošte za domenu. Pomažu da e-pošta ispravno stigne na poslužitelj. Za razliku od drugih zapisa, MX zapisi ne mapiraju računalo na nešto jer se primjenjuju na cijelu zonu. Zato MX zapisi izgledaju otprilike ovako:

Primijetite da na početku zapisa nema naziva računala. Također ćete primijetiti da u retku postoji dodatna vrijednost. To je broj prioriteta koji pomaže odlučiti na koji poslužitelj poslati e-poštu (ako je definirano više poslužitelja e-pošte). Što je broj manji, to je prioritet veći.

MX zapis trebao bi pokazivati na računalo definirano A ili AAAA zapisom (ne CNAME zapisom). Imajući to na umu, ako su konfigurirana dva poslužitelja e-pošte, zapisi bi izgledali ovako:

U ovom primjeru, sudeći prema broju prioriteta, “mail1” je poželjniji poslužitelj od “mail2”. Kod možemo dodatno skratiti izostavljanjem punog naziva domene:

NS zapisi

Ovi zapisi definiraju poslužitelje naziva (nameservere) za određenu zonu. Očito pitanje je: ako se zonska datoteka nalazi unutar poslužitelja naziva, zašto zahtijeva referencu na samu sebe? Jedan odgovor na to pitanje su višestruki mehanizmi predmemoriranja (caching) DNS sustava. Zonska datoteka zapravo može biti predmemorirana kopija na drugim poslužiteljima.

Slično kao i MX zapisi, NS zapisi se primjenjuju na cijelu zonu. Stoga prema zadanim postavkama nemaju određeno računalo. Zapisi NS-a izgledat će otprilike ovako:

Preporučuje se definirati dva poslužitelja naziva u slučaju da jedan poslužitelj ne radi ispravno. Štoviše, većina DNS poslužitelja odbit će zonsku datoteku ako sadrži samo jedan poslužitelj naziva.

Također biste trebali uključiti mapiranje računala s A ili AAAA zapisima:

PTR zapisi

PTR zapisi su suprotnost klasičnom A ili AAAA zapisu. Ovi se zapisi koriste za definiranje naziva povezanog s IP adresom. Ovi zapisi imaju jedinstveno svojstvo jer počinju na .arpa korijenu i predstavljaju vlasnika IP adrese. RIR-ovi (Regionalni internetski registri) su ti koji distribuiraju IP adrese organizacijama i pružateljima usluga. RIR-ovi uključuju APNIC, AFRINIC, LACNIC, RIPE NCC i ARIN.

Na primjer, a PTR zapis za 111.222.333.444 bi izgledao otprilike ovako:

U sljedećem primjeru PTR zapisa, pogledajte Googleov IPv6 DNS poslužitelj 2001:4860:4860::8888:

Možemo koristiti alat dig s oznakom -x za traženje reverznog DNS naziva IP adrese. Na primjer, pogledajte reverznu DNS IP adresu za 8.8.4.4:

Internetski poslužitelji koriste PTR zapise za praćenje naziva domena u zapisima dnevnika, donošenje informiranih odluka o rukovanju neželjenom poštom i prikazivanje lako čitljivih informacija o drugim uređajima.

Uobičajeno korišteni poslužitelji e-pošte potražit će PTR zapis IP adrese s koje je e-pošta poslana. Ako je PTR zapis prazan, postoji velika vjerojatnost da je e-pošta neželjena pošta (te se stoga odbija). Imajte na umu da podudaranje između FQDN-a i naziva domene PTR zapisa nije ključno. Važan čimbenik je je li valjani PTR zapis povezan s odgovarajućim i podudarajućim izravnim A zapisom.

Općenito, mrežni usmjeritelji na internetu imaju PTR zapise koji odgovaraju njihovoj fizičkoj lokaciji. Na primjer, “NYC” ili “CHI” su valjane reference za usmjeritelje koji se nalaze u New Yorku i Chicagu. Ova je tehnika korisna pri izvođenju traceroute-a ili MTR-a i pregledavanju putanje kojom paketi prolaze.

CAA zapisi

Ovi zapisi određuju CA-ove (izdavatelje certifikata) koji mogu izdati SSL/TLS certifikat za vašu domenu. Od 8. rujna 2017. svi CA-ovi dužni su provjeriti CAA zapise prije izdavanja certifikata. Ako CAA zapis ne postoji, bilo koji CA može izdati certifikat. U suprotnom, samo određeni CA-ovi smiju izdavati certifikate. CAA zapisi se mogu primijeniti na pojedinačna računala ili na cijelu domenu.

Evo primjera CAA zapisa:

Dio unosa specifičan za CAA je 0 issue "letsencrypt.org". U ovom dijelu sudjeluju tri dijela:

• Zastavice: To je cjelobrojna vrijednost koja označava kako bi CA trebao postupati s oznakama koje ne razumije. Ako je vrijednost zastavice postavljena na 0, tada će zapis biti zanemaren. Ako je vrijednost 1, tada CA mora odbiti izdavanje certifikata.
• Oznake: To su nizovi znakova koji označavaju svrhu CAA zapisa. Trenutačno valjane vrijednosti uključuju issue (ovlašćivanje CA-a za izdavanje certifikata za određenu domenu), issuewild (ovlašćivanje zamjenskih certifikata) i iodef (definiranje URL-a na kojem CA-ovi prijavljuju kršenja pravila).
• Vrijednosti: To su nizovi znakova povezani s oznakom zapisa. Ako je oznaka issue ili issuewild, vrijednost će obično biti domena CA-a kojem dajete dopuštenje. Ako je oznaka iodef, to će biti URL kontakt obrasca ili mailto: veza za povratne informacije e-poštom.

Možemo koristiti alat dig za dohvaćanje CAA zapisa:

Za detaljnije informacije o CAA zapisima, pogledajte RFC 6844.

Završne misli

Ovaj vodič opisuje različite pojmove povezane s DNS-om. Također opisuje kako se sve komponente spajaju. S ovim temeljitim pregledom na umu, trebali biste dobro razumjeti funkcionalnost DNS sustava. Iako je opća ideja jednostavna i lako razumljiva, pojedinosti vrlo brzo postaju složene. Neiskusnim administratorima može biti teško primijeniti ove koncepte i strategije.

Jeste li CloudSigma korisnik? Onda pogledajte upravljanje i ažuriranje reverznih DNS/PTR zapisa za vašu CloudSigma infrastrukturu.

Sretno računanje!