DNS priručnik - download.tutoriali.orgdownload.tutoriali.org/Tutorials/Server/DNS_prirucnik.pdf · D. Korunić: DNS priručnik, v1.5 1.Uvod Na današnjem Internetu je tzv. DNS jedan

D. Koruni: DNS prirunik, v1.5

DNS prirunikDinko Koruni

verzija 1.5

Licenca: Imenovanje-Nekomercijalno-Bez prerada 3.0 SAD

Slobodno smijete: umnoavati, distribuirati i javnosti priopavati djelo

Pod sljedeim uvjetima: Imenovanje. Morate priznati i oznaiti autorstvo djela na nain kako je

specificirao autor ili davatelj licence (ali ne nain koji bi sugerirao da Vi ili Vae koritenje njihova djela ima njihovu izravnu podrku).

Nekomercijalno. Ovo djelo ne smijete koristiti u komercijalne svrhe. Bez prerada. Ne smijete mijenjati, preoblikovati ili preraivati ovo djelo.

U sluaju daljnjeg koritenja ili distribuiranja morate drugima jasno dati do znanja licencne uvjete ovog djela.

Od svakog od tih uvjeta mogue je odstupiti, ako dobijete doputenje nositelja autorskog prava.

Nita u ovoj licenci ne naruava ili ograniava autorova moralna prava.

Prethodno ni na koji nain ne utjee na zakonska ogranienja autorskog prava.

Zagreb, srpanj 2008.

1/90

http://creativecommons.org/licenses/by-nc-nd/3.0/


Sadraj

1. Uvod...............................................................................................................41.1. Domensko ime........................................................................................41.2. Domene...................................................................................................51.3. Domenski registri.....................................................................................61.4. DNS rezolucija.........................................................................................81.5. DNS meuspremnici.............................................................................101.6. Reverzna rezolucija...............................................................................111.7. DNS protokol i komunikacija.................................................................121.8. DNS klase i zapisi.................................................................................151.9. Primarni i sekundarni NS, prijenos zone...............................................171.10. Prijenos zone i poboljanja.................................................................191.11. Delegacija............................................................................................211.12. DNS dodaci i neki detalji.....................................................................231.13. DNS sigurnost.....................................................................................24

2. DNS alati......................................................................................................272.1. Naredba host.........................................................................................272.2. Naredba dig...........................................................................................282.3. Naredba dnswalk...................................................................................302.4. Naredba fpdns.......................................................................................312.5. Naredba nslint.......................................................................................322.6. Naredba zonecheck..............................................................................322.7. Naredba dnstop.....................................................................................33

3. Bind9 posluitelj...........................................................................................353.1. Konfiguracija openito...........................................................................353.2. Komentari..............................................................................................363.3. Parametri rada servisa..........................................................................363.4. Pristupne liste........................................................................................393.5. Odjeljak za zapisnike............................................................................403.6. Odjeljak kontrole....................................................................................413.7. Odjeljak kljueva...................................................................................423.8. Server odjeljak.......................................................................................423.9. Odjeljak konfiguracije pogleda..............................................................433.10. Umetnuta konfiguracijska datoteka.....................................................443.11. Odjeljak za zone..................................................................................453.12. Konfiguracija zona...............................................................................47

4. Djbdns posluitelj.........................................................................................524.1. Dnscache..............................................................................................534.2. Tinydns..................................................................................................554.3. Tinydns zone.........................................................................................574.4. Axfrdns..................................................................................................624.5. Pravila za tcpserver...............................................................................634.6. Walldns..................................................................................................654.7. Rbldns...................................................................................................65

5. MaraDNS.....................................................................................................665.1. CSV1 format zone.................................................................................675.2. CSV2 format zone.................................................................................705.3. Mararc konfiguracijska datoteka...........................................................77

6. PowerDNS...................................................................................................78

2/90


7. Unbound.......................................................................................................798. Dnsmasq......................................................................................................809. NSD..............................................................................................................8110. Primjeri konfiguracija.................................................................................82

10.1. Bind9 konfiguracija - named.conf........................................................8210.2. Bind9 forward zona - hosts_fsb.db.....................................................8410.3. Bind9 reverse zona - db.127...............................................................8410.4. Bind9 wildcard zona - blockeddomain.hosts.......................................8510.5. Bind9 prazna zona - db.empty............................................................8510.6. Bind9 reverse zona - hosts_116.rev...................................................8510.7. Bind9 MS Active Directory kompatibilna zona....................................8610.8. TinyDNS zona.....................................................................................8710.9. MaraDNS CSV1 zona.........................................................................8710.10. MaraDNS CSV2 zona.......................................................................87

11. Literatura....................................................................................................89

Primjer 1: Domenska imena, FQDN, labele......................................................5Primjer 2: TLD-ovi..............................................................................................6Primjer 3: TLD, SLD i 3LD.................................................................................6Primjer 4: Meunarodni TLD-ovi........................................................................6Primjer 5: Lista vrnih ICANN DNS posluitelja................................................7Primjer 6: Rekurzivni DNS upit..........................................................................9Primjer 7: Standardne i reverzne adrese.........................................................12Primjer 8: Razliiti RR-ovi u svijetu i kod nas..................................................15Primjer 9: SOA polja u praksi...........................................................................20Primjer 10: Reverzna delegacija bez klasa.....................................................22Primjer 11: Kruno posluivanje......................................................................23Primjer 12: Koritenje naredbe host................................................................27Primjer 13: Koritenje naredbe dig..................................................................29Primjer 14: Koritenje naredbe dnswalk..........................................................30Primjer 15: Koritenje naredbe fpdns..............................................................31Primjer 16: Koritenje naredbe nslint...............................................................32Primjer 17: Koritenje naredbe zonecheck......................................................32Primjer 18: Komentari u named.conf datoteci.................................................36Primjer 19: Options odjeljak iz named.conf datoteke......................................38Primjer 20: Definiranje pristupnih listi u named.conf.......................................39Primjer 21: Koritenje logging direktive...........................................................41Primjer 22: Controls odjeljak iz named.conf datoteke.....................................42Primjer 23: Klju za rndc program i za Bind servis..........................................42Primjer 24: Koritenje server odjeljka..............................................................43Primjer 25: Razdijeljeni DNS kroz view direktive.............................................44Primjer 26: Umetnute konfiguracijske datoteke...............................................44Primjer 27: Koritenje parametara unutar zonskih datoteka...........................48Primjer 28: Kratice za dnscache......................................................................54Primjer 29: Podruje djelovanja u tinydns zoni................................................62Primjer 30: Zamjenski zapisi u tinydns zoni.....................................................62Primjer 31: Tcpserver pravila za axfrdns.........................................................64Primjer 32: CSV1 konfiguracija za MaraDNS..................................................67Primjer 33: CSV2 konfiguracija za MaraDNS..................................................71

3/90


1. UvodNa dananjem Internetu je tzv. DNS jedan od osnovnih servisa, te se praktiki podrazumijeva njegovo shvaanje i ispravna uporaba - ije emo temelje postaviti u ovoj kratkoj kuharici. Kako svaki prirunik poinje sa teoretskim uvodom, tako e i ovo uvodno poglavlje sadravati neke osnovne pojmove nune za razumijevanje i kasniju praktinu primjenu u iduim poglavljima.

DNS (Domain Name System) je strogo hijerarhijski distribuirani sustav u kojem se mogu nalaziti razliite informacije, prvenstveno one o IP adresama i slovnim nazivima za raunala. Slovni naziv raunala (engl. hostname) je jedinstveno simboliko ime unutar pojedine mree kojim se koriste neki protokoli (SMTP, NNTP) za elektroniku identifikaciju nekog raunala. Takvi slovni nazivi mogu biti samo jedna rije, ako se recimo radi o lokalnoj mrei; ili nekoliko rijei odvojenih tokama. U potonjem sluaju rije je o domenskom imenu (engl. domain name) o kojem emo detaljnije neto kasnije. Klijentima DNS informacije pruaju DNS posluitelji koristei DNS protokol za komunikaciju kako sa klijentima tako i meusobno.

Svrha DNS sustava je pojednostavljivanje komunikacije meu raunalima u smislu lakeg pamenja slovnih naziva kao i mogunosti tematskih i inih grupiranja raunala koja nisu nuno fiziki blizu (fiziki blizu u smislu slijednih IP adresa). Oito je bitno ugodnije u svakodnevnom radu koristiti i pamtiti slovna, simbolika imena umjesto odgovarajuih IP adresa.

Sam DNS sustav je naravno puno iri, te obuhvaa tri osnovne funkcije sa razliitim segmentima koje emo definirati u daljnjem tekstu:

1. DNS imeniki prostor, problematiku imenovanja i pravila: karakteristike su hijerarhijska struktura, imenika struktura i pravila imenovanja te specifikacije domena,

2. registraciju domena i ine administrativne probleme: hijerarhijsku strukturu nadlenih tijela, hijerarhiju vrnih nadlenih tijela (TLD), procedure registracije sekundarnih domena, administraciju DNS zona i administraciju hijerarhije,

3. posluitelje i proces rezolucije: DNS zapisi i zone, tipovi DNS posluitelja sa razliitim ulogama, procesi rezolucije, DNS poruke, formati i zapisi.

1.1.Domensko imeDomensko ime je simboliko ime raunala na Internetu koje ga uglavnom (postoji mogunost da vie raunala dijeli jedno domensko ime) jedinstveno oznauje. DNS sustav vri preslikavanje domenskog imena u jednu ili vie IP adresa te obrnuto, preslikavanje jedne ili vie IP adrese u jedno domensko ime. Na veini modernih operacijskih sustava se DNS sustav koristi implicitno, pa je mogue nekom raunalu na Internetu pristupiti kako kroz odgovarajuu IP adresu, tako i kroz domensko ime - ako ono postoji.

4/90


Domensko ime se esto naziva i labela (engl. label). Po strogoj definiciji labela je alfanumeriki niz znakova sa maksimalno 63 znaka. Jedini dakle ispravni i dozvoljeni znakovi u pojedinoj DNS labeli su:

Slova od A do Z, odnosno od a do z, Brojevi od 0 do 9, Znak "-".

Oigledan je manjak podrke za lokalizaciju domena, a naalost ista problematika nije ni dan danas u potpunosti rijeena odgovarajuim opeprihvaenim standardom.

Vie takvih labela se meusobno odvaja tokama, a sve one zajedno tvore domensko ime, koje se u takvoj potpunoj formi (navedene su sve labele) zove i FQDN (Fully Qualified Domain Name). Takvo ime je ukupne maksimalne duine od 255 znakova, a razliito je od obinog domenskog imena (koje moe biti i kratkog oblika, sadravajui svega dio labela) po tome to predstavlja apsolutnu stazu unutar DNS hijerarhije.

Primjer 1: Domenska imena, FQDN, labele

FQDN: www.srce.hr., jagor.srce.hrlabele: www, jagor, srce, hrime raunala: www, regoc, jagor, kosjenkadomensko ime: jagor.srce, www

Napomenimo jo jednom - svaka labela se sastoji od iskljuivo alfanumerikih znakova i znaka "-" (dakle ASCII znakovi od A do Z i znak "-"), pri emu se labele ne razlikuju po velikim i malim slovima. Danas je u procesu prihvaanja novi sustav koji bi trebao dozvoliti i ne-ASCII znakove u labelama, tzv. IDNA (engl. Internationalizing Domain Names in Applications) baziran na Punycode enkodiranju Unicode nizova. Da bi se FQDN dodatno razlikovao od labela odnosno standardnih (ne nuno potpunih) domenskih imena, esta je konvencija dodavanja dodatne toke (znaka ".") na kraj domenskog imena.

Da ponovimo: domensko ime se sastoji od dvije ili vie labela odvojenih tokama. Krajnje desna labela se naziva TLD (vie o TLD-ovima u nastavku), a svaka druga labela lijevo je poddomena - domena koja je hijerarhijski ispod prethodne. Ukupno maksimalno podjela moe biti 127, dok se drimo zadane granice od 255 znakova za FQDN. Na kraju, labela koja je krajnje lijeva je kratko ime raunala (ve spomenuti slovni naziv raunala, dakle bez domene).

1.2.DomeneU pojedinoj domeni, odnosno domenskom prostoru ne mogu postojati dvije iste labele - to znai niti dvije poddomene niti dva raunala. Domenska imena su obino grupirana; ona zavravaju pojedinom grupom labela za koje postoje tono definirana pravila. Takve zavrne labele se nazivaju TLD (engl. Top-Level Domain) imena, kojih postoje dva tipa:

5/90


Geografski bazirane domene, tzv. ccTLD (engl. country code TLD) domene koje predstavljaju dravni dvoznakovni kod temeljen oko ISO-3166 standarda, a danas ih ima preko 243 u upotrebi,

Generike domene, tzv. gTLD (engl. generic TLD) domene koje se obino sastoje od 3 ili vie znakova.

Primjer 2: TLD-ovi

gTLD: .com, .net, .org, .biz, .info, .name, .museum, .travel, .xxxccTLD: .us, .fr, .es, .de, .it, .jp, .ie, .co.uk, ...ccTLD izvan ISO 3166-1: .ac, .su, .tp, .uk, .yu, .euZa dodjelu i upravljanje problematikom domena, zadueno je ICANN (Internet Corporation for Assigned Names and Numbers) neprofitno tijelo. Ova relativno mlada organizacija je preuzela poslove koje je nekad obavljala IANA (Internet Assigned Numbers Authority). Specifino, rije je o upravljanju dodjeljivanjem domena i IP adresa, pri emu se lokalna registracija IP adresa u predaje pojedinanim RIR-ovima (Regional Internet Registries). Svaki RIR alocira adrese za razliiti dio svijeta. Osim TLD-ova, u DNS terminologiji se jo koriste i SLD (engl. Second-Level Domain) odnosno domene drugog stupnja te 3LD (engl. Third-Level Domain), domene treeg stupnja. Ukupno u svijetu trenutno postoji 258 TLD-ova (zajedno ccTLD i gTLD).

Primjer 3: TLD, SLD i 3LD

TLD: .hrSLD: .fer.hr3LD: .esa.fer.hr

1.3.Domenski registriSlino kao i za IP adrese, postoje domenski registri, baze podataka o domenama i odgovarajuim IP adresama, po jedan za svaku TLD. Oni kao uslugu daju domenska imena za vlastitu TLD te omoguavaju ostatku svijeta pregled informacija o registracijama pojedinih domena. Domenski registri se inae nazivaju NIC (Network Information Centre), te su najee neprofitne ili dravne organizacije. Informacije o registracijama su dostupne kroz Whois sustav, pa je tako za Europu nadlean whois.ripe.net posluitelj (primjer dobrog Whois klijenta je Jwhois, sa ugraenim bazama lokalnih registara). Same registracije se najee deavaju na principu "tko prvi, njemu djevojka", iako pojedini mogu formirati sloene politike zbog zatienih imena, itd. Svaki registar upravlja DNS posluiteljima za specifini TLD, pa je to za Hrvatsku (.HR) dns.srce.hr kojim upravlja HR-DNS sluba za CARNet, sa 28 tisua registriranih domena u 2004. Dakle, za ccTLD-ove su obino nadlene vlade pojedine drave, dok je za gTLD nadlean iskljuivo ICANN.

Primjer 4: Meunarodni TLD-ovi

6/90


TLD opis URLAC ccTLD - Ascension Island Network Information Center (AC Domain

Registry) (http://www.nic.ac/)AD ccTLD - Andorra Servei de Telecommunications dAndorra

(http://www.nic.ad)AE ccTLD - United Arab

EmiratesEmirates Telecommunications Corporation (http://www.nic.ae)

AERO

gTLD - AERO (Aviation Community)

Societe Internationale de Telecommunications Aeronautique S.C. (http://www.information.aero)

... ... ...HR ccTLD - Croatia/Hrvatska CARNet - Croatian Academic and

Research Network (http://www.dns.hr)... ... ...

Naravno, za osnovnu domenu je takoer nadlean ICANN, koji regulira upravljanjem 13 vrnih DNS posluitelja (engl. root servers). Reeni DNS posluitelji su uglavnom fiziki smjeteni u USA. Dio adresa vrnih posluitelja se distribuira anycast tehnologijom koristei BGP protokol kako bi se omoguila decentralizacija - na taj nain se veliki broj distribuiranih vorova u svijetu pojavljuje kao jedinstveni vor odnosno servis. Trenutno je na 13 vrnih posluitelja rasporeeno ukupno stotinjak (svibnja 2007. bilo je 117 vrnih posluitelja) fizikih posluitelja diljem svijeta. Uzgred, zanimljivo je spomenuti da se smatra kako je prosjeno 98% prometa (a prosjean vor prima oko 2000 DNS upita u sekundi) koje vrni DNS posluitelji primaju zapravo nepotreban promet, rezultat razliitih konfiguracijskih i inih greaka.

Primjer 5: Lista vrnih ICANN DNS posluitelja

ime operator lokacija IP adresa ASNA VeriSign Naming

and Directory Services

Dulles, Virginia, USA

IPv4: 198.41.0.4 19836

B Information Sciences Institute

Marina Del Rey, California, USA

IPv4: 192.228.79.201IPv6: 2001:478:65::53

tba

C Cogent Communications

anycast IPv4: 192.33.4.12 2149

D University of Maryland

College Park, Maryland, USA

IPv4: 128.8.10.90 27

E NASA Ames Research Center

Mountain View, California, USA

IPv4: 192.203.230.10 297

F Internet Systems Consortium, Inc.

anycast IPv4: 192.5.5.241IPv6: 2001:500::1035

3557

G U.S. DOD NetworkInformation Center

Columbus, Ohio, USA

IPv4: 192.112.36.4 568

H U.S. Army Research Lab

Aberdeen Proving Ground, Maryland, USA

IPv4: 128.63.2.53IPv6: 2001:500:1::803f:235

13

7/90


ime operator lokacija IP adresa ASNI Autonomica/NORDU

netanycast IPv4: 192.36.148.17 2921

6J VeriSign Naming

and Directory Services

anycast IPv4: 192.58.128.30 26415

K Reseaux IP Europeens -Network Coordination Centre

anycast IPv4: 193.0.14.129IPv6: 2001:7fd::1

25152

L Internet Corporation forAssigned Names and Numbers

Los Angeles, California, USA

IPv4: 198.32.64.12 20144

M WIDE Project anycast IPv4: 202.12.27.33IPv6: 2001:dc3::35

7500

Postoje i razliite organizacije koje nude alternativne vrne DNS posluitelje, nudei najee i vlastiti skup TLD-jeva, nekompatibilan sa ICANN-ovom listom. Neki primjeri su ORSC (Open Root Server Confederation), OpenNIC, Pacific Root, New.Net; no najorganiziraniji je ORSN (Open Root Server Network) koji ima direktnu kompatibilnost sa ICANN-ovom bazom - to u praksi znai dodatnu redundanciju posebice pogodnu za Europske TLD-jeve.

Jedan od glavnih problema sa vornim posluiteljima je njihova nejednolika geografska distribucija. Naime, lokacija posluitelja direktno odgovara sa financijskom situacijom regije to je oiti posljedak cijena pristupa ostatku Interneta, odravanja vornog posluitelja i potrebne infrastrukture. Ovo pak uzrokuje da siromane zemlje nemaju lokalni vorni posluitelj (npr. Sri Lanka i Pakistan), ime se bitno poveava latencija i smanjuje pouzdanost pristupa Internet resursima i unutar vlastite zemlje. ak i ccTLD posluitelji esto nisu unutar vlastite zemlje: tek ih je dvije treine unutar vlastitih zemalja, a postoji i dobar dio koji je izvan centralnog i dobro povezanog dijela Interneta. Ispadom takvog ccTLD, sve za to je on bio zaduen postaje nedostupno ma gdje god to bilo (geografski ili po Internet spojenosti).

1.4.DNS rezolucijaSvaki se funkcionalni DNS sustav nuno sastoji se od tri dijela:

DNS klijent (engl. resolver), program koji se izvrava na klijentskom raunalu i koji formira odreeni DNS zahtjev. Takav program ne mora biti nuno samostojei servis, on je na veini Unixoida najee ugraen u standardnoj biblioteci u formi sistemskih poziva koje pozivaju razliiti korisniki programi,

Rekurzivni (engl. recursive) DNS posluitelj, koji nakon dobivenih upita za klijenta obavlja pretraivanje kroz DNS stablo i vraa nazad odgovore klijentima,

8/90


Autoritativni (engl. authoritative) DNS posluitelj, koji odgovara na upite rekurzivnih posluitelja te vraa ili zavrni odgovor ili zbog delegiranja vraa referencu na neki drugi autoritativni DNS posluitelj.

Sam proces primanja zahtjeva i njihove obrade te vraanja odgovora se naziva DNS rezolucija (engl. name resolution). Pojednostavljeno, osnovna rezolucija je proces pretvorbe domenskog imena u IP adresu: prvo traimo autoritativni DNS posluitelj, a zatim mu aljemo upit za adresom, na koji on odgovara sa traenom adresom. Budui da je DNS strogo distribuirana baza, ona je raspodijeljena po mnogo razliitih posluitelja. No, oigledno je da zbog raspodijeljenosti rezolucija obino ne moe biti obavljena kroz samo jedan upit i odgovor, ve najee zahtijeva duu komunikaciju i niz upita i odgovora. Najea je situacija da klijent alje zahtjeve lokalnom DNS posluitelju (nadlean za klijentsko raunalo, obino dodijeljen od ISP-a ili ustanove u kojoj se nalazi klijentsko raunalo), koji predstavlja rekurzivni posluitelj i obavlja upite te zatim vraa odgovor klijentu. Dakle, najvei i najkompliciraniji dio procedure predstavlja traenje autoritativnog posluitelja u sloenoj DNS hijerarhiji.

to se samih tipova DNS rezolucije tie, postoje dva osnovna tipa prolaska kroz DNS hijerarhiju da bi se otkrio toan zapis. Oni se razlikuju po tome tko obavlja veinu posla oko saznavanja podataka i njihove obrade, a prvenstveno se pojavljuju kad obrada odreenog DNS upita zahtijeva nekoliko koraka (dakle, lokalni DNS posluitelj nema sve informacije):

Iterativni - kada klijent alje dotine upite, posluitelj mora odgovoriti jednim od dva mogua odgovora: a) odgovorom na zahtjev ili b) imenom drugog DNS posluitelja (vri se delegiranje) koji ima vie podataka o traenom upitu. U ovakvom tipu upita najvei dio posla obavlja klijent iterirajui akcije upit-odgovor i prolazei kroz DNS hijerarhiju.

Rekurzivni - kada klijent alje rekurzivni upit, posluitelj preuzima posao pronalaenja informacija o traenom upitu. Dakle, ono to je u iterativnom obavljao klijent, kod rekurzivnih upita obavlja posluitelj - obrauje informacije i alje nove upite drugim posluiteljima sve dok ne pronae traeno. Dakle, klijent alje svega jedan zahtjev te dobiva ili tonu informaciju koju je traio ili poruku o greci.

Oigledno je rekurzivan nain pretraivanja vrlo povoljan za klijente, ali moe znatno opteretiti DNS posluitelje (na stranu i potencijalni problem trovanja DNS posluitelja o kojem e kasnije biti rijei), pa se takve forme upita obino eksplicitno dozvoljavaju samo raunalima iz lokalne mree, dakle raunalima kojima je dotini DNS posluitelj nadlean. I iskljuivo njima.

Primjer 6: Rekurzivni DNS upit

Kao primjer, pokazat emo razrjeavanje rekurzivnog upita u potrazi za "www.carnet.hr":

1. lokalni DNS posluitelj dobiva rekurzivni zahtjev,2. pretrauje lokalnu listu vrnih DNS posluitelja,

9/90


3. rekurzivni proces zapoinje iterativnim upitom jednom (sluajni odabir) od vrnih DNS posluitelja za www.carnet.hr adresom,

4. odabrani vrni DNS posluitelj odgovara na upit sa delegacijom na ccTLD posluitelj za hr domenu,

5. lokalni DNS posluitelj zatim alje iterativni upit hr DNS posluitelju (primjerice dns.srce.hr odnosno 161.53.3.7) za www.carnet.hr adresom,

6. hr DNS posluitelj odgovara sa delegacijom na carnet.hr DNS posluitelj (dns.carnet.hr, odnosno 161.53.123.3)

7. lokalni DNS posluitelj alje iterativni upit carnet.hr DNS posluitelju (dns.carnet.hr) za www.carnet.hr adresom

8. carnet.hr DNS posluitelj (dns.carnet.hr) odgovara sa autoritativnim odgovorom, odnosno IP adresom za www.carnet.hr (primjerice 161.53.160.25)

9. lokalni DNS posluitelj odgovara klijentu sa odgovorom dobivenim od autoritativnog posluitelja (u naem sluaju 161.53.160.25).

10. ovime proces zavrava.

Ve smo spomenuli da je DNS vrlo strogo hijerarhijski baziran - praktiki svaka pretraga za nekom DNS informacijom poinje od vornog DNS raunala, od vrha DNS stabla. Prolazak kroz DNS stablo je silazak po granama stabla, gdje je svaki vor jedan DNS posluitelj, nadlean za svoj dio DNS prostora. Osnovni preduvjet pronalaenja vora stabla je lokalna lista 13 vrnih DNS posluitelja, koji dalje delegiraju pretragu po zapisima. DNS stablo je dakle hijerarhijski sloen skup DNS posluitelja, gdje svaka domena i poddomena ima jednog ili vie autoritativnih DNS posluitelja. Dotini posluitelji (vorovi stabla) su nadleni (ili mogu delegirati dalje) za "sve" domene ispod njih, servirajui podatke drugima na upit. Hijerarhijski raspored posluitelja upravo mora odgovarati rasporedu domena i odgovarajueg domenskog prostora.

U svakodnevnoj upotrebi, osim domena i labela pojavljuje se i pojam zona. Zona kao takva predstavlja dio ukupnog domenskog prostora, te se prostire od jedne toke - jednog DNS posluitelja zaduenog za tu zonu, odnosno autoritativnog za tu zonu - dalje do krajnjih vorova ili do poetaka neke druge zone. Tehniki zona je dakle dio domene, iako se moe prostirati i na cijelu domenu.

1.5.DNS meuspremniciDNS je sustav sa ovim osnovnim nainima pretraivanja (iterativni i rekurzivni silazak kroz DNS stablo) vrlo neefikasan, budui da svaki upit implicitno znai novi prolazak po stablu, poevi od vrnih DNS posluitelja. Jasno, kada bi se u stvarnom svijetu nuno svaki put prolazilo od poetka DNS stabla do kraja, do traenog zapisa - proces DNS rezolucije bi trajao i trajao, a optereenje DNS posluitelja bi postalo pretjerano veliko, sve vee i vee sa porastom

10/90


broja raunala na Internetu. No, eskalaciju ovog problema prilino je smanjio jednostavan princip spremanja kako pozitivnih (uspjenih) tako i negativnih (neuspjenih) rezultata DNS upita na DNS posluiteljima. Naime, formiranje meuspremnika (engl. cache) DNS rezultata je odgovor na dva jednostavna fenomena prisutnim u raunalnim mreama i raunalima openito:

Vee su anse da se e pristupati nekom resursu ako se nedavno pristupalo nekom drugom (prostorno) bliskom resursu - to je tzv. prostorna lokalnost reference,

Ako se samom tom resursu nedavno pristupalo, to su vee anse da e mu se ponovno pristupati - to je tzv. vremenska lokalnost reference.

Praksa pokazuje da se vrlo esto alju slini ili isti DNS upiti u vremenski bliskim periodima. Stoga svi moderni DNS posluitelji imaju interne meuspremnike o nedavnim DNS upitima koji im omoguavaju da pribave odgovor ili dio odgovora iz meuspremnika (obino u privremenoj memoriji). DNS spremnici se nalaze i na veini DNS klijenata, obavljajui isti posao kao i na DNS posluiteljima. Na taj nain se spremaju rezultati ve obavljenih upita i na klijentskim raunalima, smanjujui na taj nain promet prema posluiteljima i njihovo optereenje. Tako spremljeni odgovori e biti "due" spremljeni kod klijenata, budui da je svaki spremnik ograniene veliine i dovoljan broj upita "istiskuje" stare ili nekoritene odgovore (po FIFO, LRU, GDSF ili nekom drugom principu). Meuspremnici kao takvi vie poboljavaju performanse to su blie klijentu, ali daju bolju pokrivenost to su dalje od klijenta. Podaci spremljeni u spremnicima imaju svoja vremena ivota, TTL (Time To Live), pa se time osigurava da zastarjeli podaci nuno nestaju iz spremnika.

Dananji moderni DNS posluitelji e pri prihvatu DNS upita obaviti pretraivanje vlastitih spremnika kao i lokalne DNS baze, pokuavajui to vie skratiti vremenski "skup" prolazak kroz DNS stablo. Naalost, sekundarni efekt postojanja TTL vremena za DNS zapise je da utie i na vrijeme irenja podataka (engl. propagation time) po DNS stablu, budui da se promjene izmeu ne vide - sve do eksplicitnog nestajanja zapisa zbog TTL-a. Stoga je razumijevanje koncepta TTL-a apsolutna nunost ne samo za ispravan rad pojedinog DNS posluitelja ve i globalno: primjerice za popularne adrese je poeljno koristiti visoke TTL vrijednosti zbog smanjenja optereenja na cijeli DNS sustav.

1.6.Reverzna rezolucijaDo sada smo samo spominjali standardnu unaprijednu (engl. forward) rezoluciju kod koje se DNS imena pretvaraju u IP adrese. U standardnoj komunikaciji na Internetu nuno je moi vriti rezoluciju u oba smjera, to e rei i u unazadnom obliku (engl. reverse) - primjerice za provjeru spada li odreena adresa u kakvu domenu i sl. No, problem kod reverzne DNS rezolucije je da se posluitelji razlikuju prvenstveno po labelama odnosno po domenama za koje su nadleni, a ovdje imamo samo IP adresu kao poetnu informaciju.

11/90


Kako bi se pojednostavio (nekad se koristio neefikasni inverzni upit IQUERY koji danas uglavnom vie nije u upotrebi) i uope omoguio ovaj proces, formirana je dodatna hijerarhija u vidu IN-ADDR.ARPA domene. Rije je o domenskom prostoru koji se sastoji od etiri nivoa poddomena, a svaki nivo odgovara jednom dijelu IP adrese. Reverznom DNS rezolucijom odnosno prolaskom kroz dotina etiri nivoa, dolazi se do vora za traenu IP adresu koji pokazuje na odgovarajue domensko ime.

Svaki nivo unutar in-addr.arpa domene se sastoji od 256 poddomena (0, 1, ..., 255). Reverzna DNS adresa se formira od vorova unutar reverzne domene, a identina je obrnuto zapisanoj IP adresi sa in-addr.arpa sufiksom, pa upiti nad takvom adresom daju kao povratnu informaciju "standardnu" DNS adresu:

Primjer 7: Standardne i reverzne adrese

fly.srk.fer.hr A 161.53.74.6666.74.53.161.in-addr.arpa PTR fly.srk.fer.hr

1.7.DNS protokol i komunikacijaDNS posluitelj koristi standardne portove dodijeljene od IANA-e: TCP/53 i UDP /53. Na njima oslukuje zahtjeve, te moe bilo sa dotinih bilo sa nekog visokog porta (port vei od 1024, ovisno o konfiguraciji posluitelja) poslati odgovor u vidu traenih zapisa odnosno RR-ova (engl. resource record). Standardno se uvijek koristi UDP za upite, a komunikacija se uglavnom svodi na jedan UDP upit i jedan UDP odgovor. TCP komunikacije se koristi jedino kad veliina odgovora prelazi 512 bajtova ili za grupne prijenose DNS informacija, tzv. prijenos zone (engl. zone transfer).

Standardni DNS upit je obino vrlo jednostavan, sadri uglavnom samo adresu koja se eli razrijeiti - no odgovori su vrlo komplicirani budui da sadre sve adrese i zamjenske adrese koje su rezultat upita. Stoga se odgovori obino saimaju posebnim algoritmima, eliminirajui nepotrebne podatke i smanjujui samu veliinu UDP datagrama. U sluaju da i dalje veliina paketa prelazi 512 bajtova, alje se parcijalna poruka u obliku UDP paketa sa posebnim bitom postavljenim (TC=1), koji oznauje da se upit mora ponoviti koristei TCP. Reena maksimalna veliina paketa je ujedno i odgovor zato postoji svega 13 vrnih DNS posluitelja: upravo se lista od 13 IP adresa odgovarajue sprema u jedan paket od 512 bajtova.

Za DNS upite i odgovore se koristi tzv. opi oblik poruke, koji se sastoji od 5 odjeljaka. Dotini se popunjavaju kako upitom od klijenta, tako i odgovorom od posluitelja i u oba sluaja i podacima u zaglavlju koji su nuni da se proces obavi ispravno i uspjeno. Dotini odjeljci sa sadrajem su:

Zaglavlje (engl. header) - nuna polja koja definiraju tip poruke i pruaju klijentu ili posluitelju vane informacije o poruci. Takoer, u zaglavlju se nalaze i brojai zapisa u drugim odjeljcima poruke. Zaglavlje je prisutno u svim porukama i fiksne je veliine od 12 bajtova.

12/90


Jedna od vanijih zastavica u zaglavlju je i QR koja oznaava da li je poruka upit ili odgovor,

Pitanje (engl. question) - jedan ili vie upita klijenta prema DNS posluitelju,

Odgovor (engl. answer) - jedan ili vie RR-ova koji su odgovor na klijentov upit,

Autoritet (engl. authority) - jedan ili vie RR-ova koji predstavljaju delegaciju na autoritativne posluitelje, odnosno pokazuju na autoritativne DNS posluitelje koji se mogu koristiti za nastavak DNS rezolucije,

Dodatno (engl. additional) - jedan ili vie RR-ova koji sadre razliite dodatne informacije vezane uz upit, ali dotine nisu nune za potpunost odgovora ili upita; primjerice IP adresa DNS posluitelja spomenutog u polju za autoritet.

Mogue zastavice u zaglavlju DNS poruke su sljedee: ID (engl. identifier) - rije je o 16bitnom identifikacijskom broju koje

stvara raunalo ili ureaj koji alje DNS upit. Posluitelj u poruci mora odgovoriti sa istim takvim brojem, to omoguava klijentu da prepozna par upit-odgovor,

QR (engl. query/response flag) - slui za razlikovanje upita i odgovora. Postavljena je na 0 za upit od klijenta, a 1 za odgovor od posluitelja,

Opcode - oznaava tip operacije koji se nalazi u poruci: 0 je standardni upit (QUERY), 1 je zastarjeli tip inverznog upita (IQUERY) koji se vie ne koristi, 2 je upit za statusom posluitelja (STATUS), 3 se ne koristi, 4 je posebna poruka upozorenja koja se koristi u grupnom prijenosu DNS zapisa (NOTIFY), 5 je poruka za osvjeenje DNS zapisa koja se koristi u dinamikom DNS-u (UPDATE),

AA (engl. authoritative answer flag) - zastavica e biti postavljena na 1 ako je posluitelj koji alje odgovor autoritativan za zonu koja je dana u odjeljku pitanja, a u suprotnom e biti 0,

TC (engl. truncation flag) - zastavica koja kad je postavljena na 1 oznaava da je poruka nepotpuna budui da je bi ukupna veliina UDP poruke bila vea od 512 bajtova. Klijent tada moe poslati novi zahtjev da bi dobio potpun odgovor, pa se najee ostvaruje novi zahtjev-odgovor koristei TCP,

RD (engl. recursion desired) - kada je dotina zastavica postavljena, oznaava da bi bilo poeljno da posluitelj obavi rekurzivnu rezoluciju, ako to posluitelj podrava. Odgovor koji posluitelj alje e zadrati isto stanje zastavice kao i u upitu,

RA (engl. recursion available) - kada je postavljena zastavica, znai da posluitelj koji alje odgovor podrava rekurzivne upite, to klijenti najee "zapamte" za buduu komunikaciju sa dotinim posluiteljem,

Z (engl. zero) - bitovi koji su uvijek postavljeni na 0, Rcode (engl. response code) - zastavica koja je u upitima uvijek na 0,

ali u odgovorima indicira na tip greke koji se desio, odnosno da li je uspjeno dolo do odgovora: 0 ukazuje da nije dolo do greke (engl. NoError), 1 znai da posluitelj nije mogao odgovoriti zbog neispravnog oblika upita (engl. Format Error), 2 znai da je posluitelj pretrpio

13/90


internu greku u radu (engl. Server Failure), 3 indicira da objekt upita ne postoji u traenoj domeni - to moe odgovoriti ili autoritativni posluitelj ili lokalni posluitelj iz negativnog meuspremnika (engl. Name Error), 4 ukazuje da posluitelj ne podrava dotini tip upita (engl. Not Implemented), 5 znai da je posluitelj odbio izvriti upit, najee zbog pristupnih listi i konfiguracije (engl. Refused), 6 znai da domensko ime postoji kad ne bi trebalo (engl. YX Domain), 7 znai da RR postoji kad ne bi trebao (engl. YX RR Set), 8 znai da ne postoji RR koji bi trebao postojati (engl. NX RR Set), 9 ukazuje da DNS posluitelj koji je primio zahtjev nije autoritativan za dotini prostor (engl. Not Auth), 10 ukazuje da zatraeni objekt u zoni/prostoru specificiranom u upitu (engl. Not Zone),

QDCount (engl. question count) je broja upita u odjeljku pitanja poruke,

ANCount (engl. answer record count) je broja RR-ova u odjeljku odgovora poruke,

NSCount (engl. authority record count) je broja RR-ova u odjeljku autoriteta poruke,

ARCount (engl. additional record count) je broja RR-ova u dodatnom odjeljku poruke.

I jo emo pokazati kako izgleda oblik zaglavlja upita, koje definira sadraj upita poslanog od klijenta prema posluitelju. Ono se sastoji od nekoliko polja:

QName (engl. question name) - sadri objekt, domenu ili zonu koji su predmet upita,

QType (engl. question type) - sadri tip samog upita za upit koji dolazi od klijenta. Isti moe sadravati specifini broj koji odgovara tipu RR-a koji se trai ili pak neki od posebnih brojeva za posebne vrste upita: 251 odgovara zahtjevu za inkrementalni zonski prijenos (IXFR), 252 odgovara standardnom zahtjevu za prijenos zone (AXFR), 253 i 254 odgovaraju zastjerjelim upitima za zapise vezane uz e-mail (MAILA i MAILB upiti za MB, MG i MR zapisma), te 255 koji odgovara upitu za svim zapisima ("*").

QClass (engl. question class) - oznaava koji se tip RR trai i moe poprimiti vrijednost od 0 do 65535. Standardno je se koristi svega pet vrijednosti: 1 za Internet (IN) zapis, 3 za CHAOS, 4 za Hesiod (HS), 254 za prazni (NONE) tip i 255 za ANY upit. ANY klasa je zamjenski ("*"), dok se NONE obino koristi u dinamikom DNS-u.

Poruka od DNS klijenta je primjerice sljedeeg oblika: klijent alje UDP upit (QR=0, to oznaava upit, a ne odgovor) kao standardni upit (OPCODE=0) sa jednim zapisom u upitu (QDCOUNT=1). Upit uglavnom ne sadri dodatne zapise niti u polju za odgovor, niti za autoritativni dio niti u polju za dodatne zapise (ANCOUNT=0, NSCOUNT=0, ARCOUNT=0). QNAME zapis oznaava primjerice domenu za kojom klijent pretrauje (QNAME = www.google.com.). Tip i klasa zapisa za kojom klijent pretrauje su QTYPE=1 (adresa raunala) i QCLASS=1 (Internet adresa). Budui da veliina odgovora unutar 512 bajtova, TC=0.

14/90


Odgovor (QR=1) od posluitelja na standardni upit (OPCODE=0) je primjerice sljedei: posluitelj je autoritativan za traenu domenu (AA=1), a podrava i rekurzivne upite (RA=1). Tijekom pretrage nisu utvrene nikakve greke u upitu (RCODE=0) koji je sadravao samo jedan zapis (QDCOUNT=1). Odgovor sadrava 3 RR-a (ANCOUNT=3) u polju odgovora, 6 zapisa u odjeljku za autoritet (ARCOUNT=6). Oigledno je da se originalni upit koristi za formiranje odgovora, pa se polje zaglavlja i polje pitanja kopiraju iz originalnog upita u odgovor, sa ve navedenim promjenama.

1.8.DNS klase i zapisiKao to je ve spomenuto, RR je jedan zapis, jedna jedinica u DNS sustavu. Svaki RR sadri odreene atribute, odgovarajue za vlastiti tip; to mogu biti IP adresa, adresa za isporuku elektronike pote, niz teksta, DNS labela ili neto tree. Svaki RR se sastoji od sljedeih komponenti, redom kojim se pojavljuju:

Ime domene - uglavnom se koristi FQDN, a ako je zapisano kratko ime onda se automatski dodaje ime zone na kraj imena,

TTL u sekundama, standardna vrijednost je minimalna vrijednost navedena u SOA zapisu (o ovome kasnije),

klasa zapisa koji moe biti Internet, Hesiod i Chaos, Tip zapisa: CNAME, PTR, A, MX, TXT, AAAA, A6, itd. Podaci za dotini tip zapisa - odgovaraju odreenom tipu, ako

sadravaju ime domene koje nije FQDN, automatski se dodaje ime zone na kraj imena,

Opcionalni komentar (dodan u ovisnosti o vrsti posluiteljskog softvera).

Primjer 8: Razliiti RR-ovi u svijetu i kod nas

esa.fer.hr. 22h30m57s IN A 161.53.71.180carnet.hr. 23h17m31s IN NS dns2.carnet.hr.carnet.hr. 4h15m27s IN MX 30 mx2.carnet.hr.www.l.google.com. 5M IN A 66.249.93.104www.l.google.com. 5M IN A 66.249.93.99130.2.53.161.in-addr.arpa 86377 IN PTR jagor.srce.hrversion.bind. 0S CHAOS TXT "9.2.2"

Klase zapisa (engl. resource record classes) su u osnovi povijesna ostavtina, bez stvarne koristi danas. Budui da je DNS inicijalno vrlo generiki oformljen, ideja je bila da e se kroz DNS nuditi imenike usluge za vie od jednog protokola (dakle, osim IP-a). Stoga svaki RR zapis ima i klasu, te openito reeno ona mora biti specificirana za svaki RR unutar lokalne zone. Danas se u praksi koristi jedino Internet klasa, pa se ona implicitno podrazumijeva kad u lokalnoj zoni nije eksplicitno navedena IN klasa.

to se pak tie tipova zapisa, postoji nekoliko osnovnih tipova: A (engl. address) - povezuje odgovarajue domensko ime (labelu ili niz

labela) sa IPv4 adresom (32bitna adresa). Danas je esto mogue nai da vie A zapisa pokazuje na istu IP adresu, to je sasvim legalno.

15/90


CNAME (engl. canonical name) - omoguava da jedno domensko ime bude zamjensko ime za drugo. Takvo zamjensko ime dobiva sve osobine originala, ukljuujui i IP adrese i poddomene. No, ilegalno je u zoni imati ijedan zapis koji dijeli isto ime (labelu) kao i CNAME zapis; dakle, CNAME ne moe koegzistirati niti s jednim drugim tipom za istu labelu, ukljuujui i praznu labelu. Takoer, niti jedan tip zapisa osim CNAME ne smije pokazivati na zamjensku adresu (odnosno na CNAME), budui da bi to omoguilo petlje i neispravne zapise u zoni.

MX (engl. mail exchange) - oznaava koji su sve e-mail posluitelji nadleni za dotinu domenu. U sluaju da ovaj zapis ne postoji, e-mail se isporuuje koristei A zapis dobiven rezolucijom iz odredine domene. Osnovna funkcionalnost ovog mehanizma je pruiti mogunost da postoji vie e-mail posluitelja za jednu domenu i da se definira toan redoslijed prema kojem ih se mora kontaktirati. Time se na jednostavan nain omoguava usmjerivanje maila (engl. mail routing) kao i mogunost raspodjele optereenja izmeu vie posluitelja. No, naalost MX zapis ne omoguava e-mail servis na alternativnim portovima niti ne omoguava postavljanje teinskih vrijednosti za posluitelje koji su istog prioriteta - kao to recimo SRV zapis omoguava. MX zapis funkcionira tako da klijent pri MX zahtjevu dobiva listu e-mail posluitelja, te je on zapoinje isporuku pote na nain da je MX zapis sa najmanjim pripadnim brojem (engl. preference) onaj sa najveim prioritetom. Klijent tako prolazi listu posluitelja sve dok ne isporui e-mail uspjeno. Svi posluitelji koji imaju isti MX broj se tretiraju jednakog prioriteta, pa se stoga nad njima svima iskuava isporuka - dok ne uspije.

PTR (engl. pointer record) - povezuje IPv4 adresu sa odgovarajuim domenskim imenom (FQDN). Obino PTR zapisi trebaju pokazivati na ime koje se moe nazad razrijeiti u polaznu IPv4 adresu. Naravno, PTR zapis kao takav nije IPv4 adresa, ve obrnuto zapisana 4 okteta adrese sa dodatnom IN-ADDR.ARPA. domenom.

NS (engl. name server record) - oznaava da je za dotinu zonu treba posluivati upravo dotini DNS posluitelj. Svaki NS zapis je ili oznaka autoriteta ili oznaka za delegaciju: naime, ako je naziv NS zapisa jednak zoni u kojoj se NS zapis pojavljuje, onda je rije o autoritativnom zapisu; ako je pak rije o nazivu koji sadri neku od poddomena, onda je rije o delegaciji.

SOA (engl. start of authority) - izmeu ostaloga oznaava koji je DNS posluitelj autoritativan za dotinu domenu, kao i dodatne informacije o zoni. Svaka ispravna zona mora imati SOA zapis.

AAAA i A6 - povezuju odgovarajue domensko ime sa IPv6 adresom (128bitna adresa). Mogue je nai i AAAA i A6 zapis, pri emu se oni razlikuju u nekim detaljima: A6 omoguava da labela bude definirana kao binarni niz, itd. Danas se A6 smatra jo uvijek eksperimentalnom, te se preporua koristiti AAAA u produkciji.

DNAME - relativno recentni nain definiranja zamjenskih imena za cijelu domenu, ne nuno samo pojedino domensko ime. Koristi se primjerice u IPv6 za agregaciju i delegaciju cijelog prefiksa. U praksi se rijetko sree.

16/90


SRV (engl. server selection) - zapis koji se sve ee koristi u protokolima koji se tek pojavljuju na tritu, a predstavlja znatno bolju alternativu trivijalnim MX zapisima. Rije je o openitom zapisu za definiciju lokacije servisa, njegove teine i prioriteta, primjerice za LDAP, HTTP, SMTP i sl.

TXT (engl. text string) - pojednostavljeno, omoguava proizvoljan tekstualan zapis do 255 bajtova. Danas se koristi primjerice umjesto zastarjelog HINFO opisa ureaja koji nosi domensko ime ili za upisivanje SPF (engl. sender policy framework) obiljeja.

DS (engl. delegation signer) - dodaje se na mjestu prekida zone (mjesta gdje se vri delegacija) da bi se pokazalo kako je delegirana zona digitalno potpisana i da dotina prepoznaje odreeni klju kao ispravni vlastiti klju. Ovime se eksplicitno definira delegacija, umjesto implicitno kao do sada.

KEY (engl. public key) - javni klju koji je autoriziran od SIG zapisa, a omoguava spremanje i DNSSEC kljueva i proizvoljnih kljueva za aplikacije.

KX (engl. key exchanger) - omoguava metodu za delegiranje autorizacije za neki vor u ime jednog ili vie vorova, kako bi pruili servise razmjene kljueva.

LOC (engl. location information) - zapis u koji je mogue spremiti geolokacijske odnosno GPS podatke o odreenom voru ili domeni.

SIG (engl. cryptographic public key signature) - predstavlja potpis radi autentifikacije podataka u DNSSEC-u.

TSIG (engl. transaction signature) - omoguava jednostavnu autentifikaciju koristei dijeljene tajne kljueve i hashiranje za DNS transakcije.

RP (engl. responsible person) - zapis o odgovornoj osobi za domenu ili vorove.

Postoji jo niz rijetko koritenih zapisa: AFSDB (engl. AFS database location code), HINFO (engl. host information), ISDN (engl. ISDN address), MB (engl. mailbox), MR (engl. mail rename domain code), NULL (engl. null record), RT (engl. route through), X25 (engl. X25 PSDN address), MINFO (engl. mailbox or mailing list information), PX (engl. pointer to X.400/RFC822 mail mapping information), NSAP (engl. network service access point address) i NAPTR (engl. naming authority pointer). Praktinu upotrebu i detaljniji opis pojedinih RR-ova emo pokazati kroz primjere u Bind9 poglavlju.

Ponekad moete naii na neke od ovih zapisa, no oni se vie ne koriste i preporuljivo ih je izbjegavati koristiti: WKS (engl. well known services), GPOS (engl. geographical position), MD (engl. mail destination), MF (engl. mail forwarder), NSAP-PTR (engl. NSAP pointer), NXT (engl. next domain), itd.

1.9.Primarni i sekundarni NS, prijenos zoneSa svakodnevnim koritenjem DNS sustava nuno se susresti i sa par dodatnih pojmova i funkcionalnosti, pa ponimo od samog meuodnosa DNS

17/90


posluitelja. Svaki posluitelj koji ima kompletnu kopiju zone (bilo lokalno bilo prihvatom na neki drugi nain) bez potrebe za procesom rezolucije je autoritativni DNS posluitelj za tu zonu. Dakle, rije je o posluitelju koji servira vlastite podatke klijentima. Naravno, posluitelj moe biti autoritativan za jednu zonu, ali ne nuno i za neku drugu. Osnovni podatak koji informira posluitelj da je autoritativan za tu zonu je SOA zapis, uz ostatak konfiguracije koji omoguava prihvat podataka o zoni i sl. Krivo definirano SOA polje moe dovesti do situacije da niti jedan DNS posluitelj za zonu ne bude autoritativan - i time do prestanka normalnog rada DNS rezolucije za tu zonu.

Moe (ak je preporuljivo!) postojati vie definiranih DNS posluitelja za istu zonu koristei vie odgovarajuih NS zapisa. Danas je praksa da bi svaka zona trebala imati barem dva DNS posluitelja, tako da padom jednog DNS nastavlja funkcionirati - neto sporije, ali bitno je da su RR-ovi i dalje dostupni. Zato je bitno imati dva DNS posluitelja? Nakon isteka TTL vremena pojedinog RR-a (definirano u svakom RR-u), podaci spremljeni po raznim klijentima i posluiteljima nestaju. U sluaju da je postojao samo jedan autoritativni NS (jedan DNS posluitelj), a da je on neaktivan ili neispravan - naa zona je nedostupna. I ne samo to - ona je nedostupna na due vrijeme zbog toga to se neuspjeli upit (NXDOMAIN) spremio na nekom klijentu i njegovom posluitelju zbog principa negativnog meuspremnika. Stoga je razvijen princip primarnog (engl. primary, master) i sekundarnog (engl. secondary, slave) DNS posluitelja. Primarni posluitelj je onaj autoritativni posluitelj koji podatke o svojoj zoni ima lokalno spremljeno, odnosno ima im lokalni pristup. Sekundarni posluitelj je pak onaj koji dobiva podatke od nekog vanjskog izvora, obino koristei prijenos zone (engl. zone transfer) od primarnog posluitelja. Jasno, primarni posluitelj za jednu zonu moe biti sekundarni za drugu i sl. Sa gledita klijenta, oba su posluitelja (primarni i sekundarni) jednake vrijednosti (autoriteta) i jednakog prioriteta (sluajni izbor). Naravno, postoje i drugi razlozi za implementaciju sekundarnog posluitelja - kako radi lakeg odravanja (primarni ne mora biti aktivan za vrijeme odravanja), tako i boljeg rasporeivanja optereenja za velike zone i mnogo upita. Naravno, dobro je i postaviti sekundarni posluitelj fiziki udaljenim iz ve navedenih razloga.

Osim primarnih i sekundarnih autoritativnih posluitelja postoji jo par tipova posluitelja. Ponimo od iskljuivo meuspremnikog posluitelja (engl. caching-only name server). Takvi posluitelji nisu autoritativni niti za jedan RR i nemaju nikakve lokalne podatke koje bi posluivali - njihova osnovna funkcija je poboljati performanse DNS sustava radei kako pozitivno tako i negativno meuspremanje rezultata DNS upita, smanjujui tako optereenje na autoritativnim posluiteljima. Sljedei tip je prosljeivaki posluitelj (engl. forwarding name server). Njegova je osnovna funkcija prihvat i prosljeivanje upita nekom drugom DNS posluitelju, ali se obino kombinira i sa lokalnim spremanjem dobivenih rezultata - pa je rije o dobrom rjeenju za spore mree. Jo jedan tip je i iskljuivo autoritativni posluitelj (engl. authoritative-only name server) koji nema meuspremnik DNS upita niti ne odgovara na upite za koje nije autoritativan. On je dakle primarni ili sekundarni posluitelj za zonu, a ne omoguava rekurzivne upite. Rije je najee o vidu sigurnosti gdje se odvajaju posluitelji za iskljuivo

18/90


autoritativne i iskljuivo meuspremnike zadae. Obino takve okoline gdje se trai sigurna forma DNS posluitelja imaju nekoliko DNS posluitelja od kojih su neki javno vidljivi, a neki nisu - pa tvore skrivene posluitelje (engl. stealth name server). Najee je sluaj da skriveni posluitelji interno isporuuju klijentima DNS informacije koje nisu vidljive na javnoj vanjskoj mrei. Na taj nain se vanjskim klijentima posluuje tek dio informacija za koje se smatra da im je potrebno, a unutranjima se daje drugi dio informacija - za koji se smatra da im je dovoljno - i tako se eliminira sigurnosni problem da svi vide "sve". Taj princip se jo naziva razdvojenim posluiteljima (engl. split name server), odnosno razdvojeni DNS (engl. split DNS).

1.10.Prijenos zone i poboljanjaKao to je ve reeno, na primarnom DNS posluitelju se zona nalazi lokalno, te se i promjene unose lokalno. No, takve podatke nuno je prenijeti na siguran i korektan nain do sekundarnih, podreenih DNS posluitelja i po mogunosti automatski, odmah nakon zavretka ureivanja zone na primarnom. Naime, jednom promijenjeni podaci na primarnom posluitelju bi bez mehanizma sinhronizacije bili tek djelomino dostupni, budui da se klijentski upiti primarnom i sekundarnim posluiteljima statistiki podjednako raspodjeljuju - pa bi svaki drugi ili n-ti upit za novim zapisom zavrio ili neuspjehom ili zastarjelim podacima. Nuno je stoga osigurati mehanizme za provjeru svjeine podataka na sekundarnom posluitelju naspram onih na primarnom kao i mehanizme za prijenos zone po potrebi ili barem redovito.

Kljuni dio u implementaciji ovih mehanizama je ve spomenuti SOA zapis. On sadri osim podatka tko je autoritativni posluitelj (i koji je zapravo primarni) za zonu i nekoliko vrlo vanih podataka:

Serijski broj (engl. serial) zone - odreuje verziju podataka u zoni, odnosno cijele zone. Pravilo je da se svaki put kad se bilo koji podatak u zoni mijenja, dotini serijski broj mora poveati - bilo automatski (TinyDNS) bilo runo (Bind). Na taj nain se omoguava podreenim posluiteljima da prepoznaju zastarjelost vlastitih podataka (manji serijski broj - starija zona) i iniciraju prijenos zone. Za serijski broj ne postoje odreena pravila, ali se prakticira neki od tri mogua naina: YYYYMMDDn, YYYYMMDDnn i automatski (obino vrijeme promjene zone u sekundama poevi od Epohe). Posljednji broj nn u SOA je u prva dva sluajeva redni broj promjene zone unutar dotinog dana. Nepravilno koritenje SOA polja (primjerice obrnuto koritenje mjeseci MM i dana DD) moe uzrokovati desinkronizaciju i zastarjele podatke na sekundarnim posluiteljima.

Vrijeme osvjeavanja (engl. refresh) - oznaava koliko sekundi e sekundarni posluitelji ekati izmeu pokuaja osvjeavanja zone. Pojednostavljeno, to je najdue vrijeme od promjene zone na primarnom posluitelju koje je sekundarni ekati prije pokuaja prijenosa zone.

Vrijeme ponovnog pokuaja (engl. retry) - oznaava koliko e sekundarni posluitelji morati ekati nakon neuspjenog prijenosa zone prije nego pokuaju ponovo. Na ovaj nain se jednostavno eliminiraju masovni pokuaji prijenosa zone koji bi se inae deavali.

19/90


Vrijeme isteka (engl. expire) - definira vrijeme nakon kojeg e sekundarni posluitelji smatrati vlastite podatke zastarjelima i odbaciti ih, sve do idueg uspjenog prijenosa zone. Time se jednostavno rijeio problem pretjerano zastarjelih zapisa, koji bi unijeli desinkronizaciju u DNS sustav.

Primjer 9: SOA polja u praksi

esa.fer.hr SOA esa1.esa.fer.hr postmaster.esa.fer.hr ( 1124015177 ;serial (version) 28800 ;refresh period (8 hours) 7200 ;retry interval (2 hours) 604800 ;expire time (1 week) 604800 ;default ttl (1 week) )carnet.hr SOA dns.carnet.hr hostmaster.carnet.hr ( 2005071902 ;serial (version) 10800 ;refresh period (3 hours) 3600 ;retry interval (1 hour) 2419200 ;expire time (4 weeks) 86400 ;default ttl (1 day) )

Sekundarni posluitelj po inicijalnom pokretanju moe imati bilo nekakvu stariju lokalnu kopiju - koju koristei SOA polje provjerava naspram primarnog posluitelja i po potrebi vri prijenos zone. Naravno, ako nema nikakve podatke, vri se takoer prijenos zone.

Sama replikacija podataka, odnosno prijenos zone zapoinje standardnim DNS upitom (dakle UDP) tipa AXFR (engl. address transfer). Na dobiveni zahtjev DNS posluitelj u sluaju da klijent ima dozvolu odgovara potvrdno, te se klijent ponovno spaja - ovaj put radi pouzdanosti ostvaruje TCP vezu i prenosi itavu zonu kroz istu vezu, zatvarajui je po zavretku. Nakon toga dotini sekundarni posluitelj odbacuje svoje stare podatke i uitava nove, ponavljajui proces kako je definirano vremenom osvjeavanja. Naravno, u sluaju neuspjelog prijenosa takoer se proces pokuava ponoviti kako je definirano vremenom pokuaja. A ako se desi da proe vrijeme isteka, odbacuju se svi podaci u sekundarnom posluitelju sve do prvog uspjenog prijenosa - kao to je ve opisano. Naravno, prije nego se obavlja prijenos zone, skoro uvijek se deava standardni UDP DNS upit za SOA poljem, ime se provjerava da li je zaista prijenos zone potreban - iako je mogue da se taj upit za SOA RR odvija i kroz ve uspostavljenu TCP vezu.

Naalost, koliko god ovaj mehanizam prijenosa bio efikasan sa gledita jednostavnog polu-automatiziranog prijenosa zone, osnovni problem je da se u praksi u veim organizacijama DNS zone praktiki redovno mijenjanju i da je odreivanje prijenosa kroz SOA nepraktino - ili je previe rijetko pa se zone ne osvjeavaju sukladno sa promjenama, ili je pak previe esto - pa se posluitelj znatno optereuje velikim i estim prijenosima. Ono to je

20/90


definitivno poboljanje ovakvog naina je model ugraen u veinu recentnih DNS posluitelja:

Primarni DNS posluitelj obavjetava sve svoje sekundarne posluitelje o promjeni zone standardnom DNS porukom obavjetenja odnosno alje im NOTIFY paket.

Sekundarni posluitelji se na prispijee takve poruke ponaaju kao da im je isteklo vrijeme osvjeavanja - te je poboljanje oigledno: rijeio se problem nepotrebnog prozivanja primarnog posluitelja i skratilo se vrijeme u kojem sekundarni posluitelji daju zastarjele informacije.

Idue poboljanje danas prisutno uglavnom u modernijem DNS softveru poput Bind posluitelja su inkrementalni prijenosi zona (tzv. IXFR) kod kojih se umjesto cijele zone (standardni AXFR) prenosi tek dio promjena, odnosno zadnje promjene. Posluitelj interno vodi rauna o promjenama u lokalnoj zoni: dri lokalnu bazu dotinih promjena na inkrementalni nain, uvajui razlike izmeu pojedinih verzija. Svaki put kada sekundarni posluitelj zatrai prijenos zone koristei IXFR upit (dakle sposoban je za inkrementalni prijenos), posluitelj iz upita proita serijski broj zone koju sekundarni posluitelj smatra aktualnom i poalje samo razlike izmeu trenutne i te verzije - odnosno samo promijenjene RR-ove. U praksi se dri tek nekoliko zadnjih verzija zone, pa se u sluaju da primarni posluitelj nema informacije o nekoj jako staroj zoni vri puni prijenos. Jasno, u sluaju da primarni posluitelj ne podrava IXFR ili sekundarni ne alje IXFR upite, obavlja se iskljuivo AXFR.

Prijenos zone ima i svoje nedostatke - on naalost ne garantira nikad da e se prenijeti svi originalni podaci iz zone na primarnom posluitelju, ali uglavnom se na veini dananjeg DNS softvera prenesu bez problema svi standardni RR-ovi.

1.11.DelegacijaVratit emo se jo jednom na netrivijalan proces delegacije: rije je o dijeljenju odreene zone u podzone, koristei odgovarajue NS zapise - u svojem delegacijskom obliku. No, na nekoliko je vanih detalja potrebno obratiti panju: ako se zona delegira na DNS posluitelje iji je FQDN iz delegirane zone, za normalno funkcioniranje je u matinoj zoni potrebne definirati odgovarajui povezujui zapis (engl. glue records) - A zapis koji definira adrese DNS posluitelja iz dotine zone. To je nuno zbog toga to se DNS posluitelji prozivaju po svojim DNS imenima, a ne IP adresama. Da bi se dolo do podataka iz zone, nuno je doi prvo do posluitelja iz te zone - meutim, u sluaju da ne postoje povezujui zapisi u matinoj zoni, posluitelj matine zone ne bi imao dotini podatak te bi jednostavno izdelegirao upit DNS posluitelju ija se IP adresa jo uvijek ne zna.

Nuno je primijetiti kako se svaka promjena autoritativnih posluitelja za pojedinu domenu (NS zapisi) mora runo sinkronizirati i na nadreenim posluiteljima da bi bila ouvana konzistentnost delegacije (engl. delegation consistency). U protivnom nema poante postojanja dotinih posluitelja koji nee biti dostupni (nemaju povezujue zapise na matinoj zoni) jednom kad

21/90


proe TTL za njihove A zapise. Sljedei est problem je kriva delegacija (engl. lame delegation), kada NS naveden u matinoj zoni kao autoritativni za zonu ne prua autoritativne odgovore. Postoji nekoliko razloga za takvo ponaanje: a) nema aktivnog DNS posluitelja, b) posluitelj je aktivan ali je bez autoritativnih podataka (svi su istekli, sekundarni, nije bilo recentnog prijenosa zone) ili c) odgovara sa porukom o greki (SERVFAIL ili REFUSED). Dakle, problem je do nekonzistentne definicije delegacije (razliiti NS zapisi na matinoj i delegiranoj zoni) ili do toga da su u obje zone NS-ovi krivo postavljeni (pokazuju na krivi ili loe konfigurirani posluitelj). Kod postavljanja delegacije nuno je pripaziti da se ne desi kruna meuovisnost (engl. cyclic dependancy) kod kojeg jedan dio DNS stabla sadri meusobne ovisnosti izmeu dvije zone, onemoguujui time normalan rad DNS-a. DNS klijenti standardno mogu prolaziti razliitim dijelovima DNS stabla da bi pronali traeni zapis - no kod meusobne ovisnosti e takvi upiti zavriti petljom i nikad se ne dolazi do odgovora.

Zavrni sluaj delegacije je vjerojatno i najkompliciraniji, meutim pokazuje eleganciju rada sa DNS sustavom. Delegacija podmree bez upotrebe klasa (engl. classless subnet delegation) je danas odgovor na nunost delegiranja tek jednog dijela reverzne (IN-ADDR.ARPA) zone. Naime, za upravljanje reverznom zonom standardno se delegirala najmanja mrea, podmrea klase C sa 256 adresa - to se vrlo brzo pokazalo nepraktinim zbog velike i nepotrebne potronje IP adresa. Osnovni nain za formiranje ovakve delegacije je koristiti nekoliko odgovarajuih zapisa u reverznoj matinoj zoni koja e se delegirati:

NS zapise - za definiranje posluitelja za podmreu, PTR zapise - koji povezuju definirana kanonika imena prema

reverznim adresama, CNAME zapise - koji omoguavaju definiranje zamjenskih imena kako

bi se pojednostavio proces.

Kada je jednom ovako definirano, postoje osnovna dva naina delegacije: Nadleno tijelo delegira svaku IP adresu kao D klasu podmree sa

jednim ili vie NS zapisom za svaku IP adresu. Onaj tko prima delegaciju morati imati zonu za svaku IP adresu, SOA, dodatne NS-ove i odgovarajui PTR zapis,

Alternativno matino tijelo ne mora uope "stvarno" delegirati, ve moe koristiti praktiki proizvoljan CNAME zapis za svaku reverznu adresu (IP) u svojoj reverznoj zoni, zamjenjujui PTR-ove. Pravilo je da se obino ta labela formira iz IP adrese koja se mijenja, a sufiks mora biti domena kojoj se zapravo "prosljeuje" upit. Na taj nain onaj tko prima delegaciju treba imati samo odgovarajui PTR da bi omoguio da se dotina labela razrijei. Ovo je ujedno i danas najpopularniji sustav delegacije bez klasa.

Primjer 10: Reverzna delegacija bez klasa

69.2.53.161.in-addr.arpa CNAME 69.srce.hr.

22/90


1.12.DNS dodaci i neki detaljiVeina dananjih DNS posluitelja ima ugraeni vrlo jednostavni i primitivni mehanizam krunog posluivanja (engl. round robin) za koje se smatra da omoguava jednoliko rasporeivanje optereenja po odredinim adresama. Reeni funkcionira na sljedei nain: u sluaju da je u odgovoru na zadani upit vie RR-ova (jedno pitanje - jedan odgovor, vie zapisa), redoslijed RR-ova u odgovoru je pseudosluajan. Imajui u vidu da tipine aplikacije najee koriste samo prvi zapis iz odgovora, dobiva se ponaanje gdje aplikacije svaki put kontaktiraju "drugi" posluitelj. Algoritmi u samim posluiteljima uglavnom garantiraju ciklinost, a ponegdje ih je mogue mijenjati ili fino podeavati: npr. novije Bind9 inaice imaju rrset-order parametar kojim se moe definirati ciklinost ili posve sluajan odabir nad istim RR-ovima. Dotini mehanizam ima osnovni nedostatak u vidu manjka ikakve provjere da li su zapisi ispravni ili da li je odredina adresa uope dostupna - a kamoli koliko je optereenje na pojedinoj adresi za koju se pokuava implementirati raspodjeljivanje. Ovo se obino rjeava koristei niske TTL vrijednosti i kakvo suelje prema DNS posluitelju koje po potrebi omoguava izbacivanje/ubacivanje zapisa u listu ili njihovu promjenu (radi minimizacije ekanja, optereenja, detekcije mrtvih posluitelja, itd). Raspodjela e funkcionirati uglavnom dobro dokle god nema sluajeva da svega jedan upit (ili samo jedno raunalo) generira vrlo visoka optereenja.

Drugi, ne tako oit problem je da kruno posluivanje moe uzrokovati da se polazno ime u procesu rezolucije nee nuno dobiti nazad iz odgovarajueg PTR zapisa. U takvom sluaju e dio SMTP posluitelja, koji implementira provjeru adrese pretraujui unaprijed i unazad DNS rezolucijom, moe odbiti isporuiti potu. Sve u svemu, ikakva raspodjela optereenja (a kamoli inteligentna raspodjela) po A zapisima je trenutno suboptimalna - pa se smatra da je budunost koritenje SRV zapisa koji se tek treba dovoljno proiriti. Alternativa je koritenje podservisa unutar postojeih DNS posluitelja koji bi na osnovu nekih parametara (stanje udaljenih posluitelja, npr) predali DNS posluitelju, a zatim i klijentu zadovoljavajui odgovor.

Primjer 11: Kruno posluivanje

Pokuaj 1:www.google.com CNAME www.l.google.comwww.l.google.com A 66.249.93.104www.l.google.com A 66.249.93.99

Pokuaj 2:www.google.com CNAME www.l.google.comwww.l.google.com A 66.249.93.99www.l.google.com A 66.249.93.104

U DNS zoni pojedinih modernijih DNS posluitelja mogu je i jedan poseban zapis, takozvani zamjenski zapis (engl. wildcard). Rije je o zapisu koji omoguava da jedan zapis postoji umjesto niza drugih istog tipa, koji bi

23/90


pokazivali na isti podatak u istoj zoni. U takvom zapisu se koristi znak "*" u imenu kao jedini znak u labeli. Sam DNS posluitelj e primijeniti dotini zapis i odgovoriti sa dotinim sadrajem u sluaju da:

Nema drugih zapisa koji su precizniji (bolji) odgovor na upit, odnosno onih koji tono odgovaraju upitu,

Zamjenski zapis se moe staviti umjesto grupe labela tako da odgovara na zadani upit (engl. pattern matching).

Pojednostavljeno reeno, zamjenski zapis e omoguiti da se upiti za inae "nepostojeim" labelama preusmjere na "ispravni" RR.

Naposljetku, spomenimo i dinamiki DNS (engl. dynamic DNS) na klasini DNS sustav. DNS u poetku osmiljen s idejom da se promjene u zonama nee preesto odvijati - to smo ve vidjeli kod problematike razmjene i sinkronizacije zona. Za unos u DNS sustav su uglavnom predviene statike adrese koje se ne mijenjaju, budui da bi runo mijenjanje svaki put predstavljalo nonu moru za odravanje. Moderni DNS i DHCP posluitelji stoga omoguavaju meusobno povezivanje sustava dodjeljivanja IP adresa sa DNS sustavom, tako da se svako DHCP-registrirano raunalo registrira u DNS sustavu kroz automatizirani proces. Specifino, DHCP klijent alje DNS UPDATE poruku koja indicira DNS posluitelju to treba obaviti sa odgovarajuim RR-ovima. Naravno, dinamiki DNS kao takav nije ogranien nuno na DHCP, ve u praksi svaki autorizirani DDNS (dinamiki DNS) klijent moe upravljati odgovarajuim zapisima u zoni.

1.13.DNS sigurnostNaalost, uz DNS sustav su vezani i razliiti sigurnosni problemi. Postoji niz trikova pomou kojih se moe odredini DNS posluitelj natjerati da prihvati lane zapise. Takvom metodom lairanja DNS zapisa (engl. DNS forgery) nesvjesni se klijenti preusmjeruju na lane adrese i time postaju laka meta napadaa. Standardno su takvi napadi u formi trovanja DNS meuspremnika (engl. cache poisoning), napada kod kojeg se utie na DNS posluitelj da povjeruje da je dobio autoritativne informacije o nekim RR-ovima. Time se utie na sve klijente koji koriste dotini DNS posluitelj da takoer koriste lairanu informaciju, koja moe omoguiti daljnje razliite napade na klijentska raunala.

Postoje tri osnovna tipa ovakvog napada: Preusmjeravanje posluitelja za odredinu domenu - gdje se za neku

domenu na zloudnom posluitelju specificira vlastiti NS za traenu domenu u autoritativnom odjeljku i jo u dodatnom odjeljku daje vlastiti A zapis sa lanim NS-om koji se nazivno nalazi u napadnutoj domeni. Zatrovani posluitelj pamti IP adresu NS posluitelja koji je sada napadaev DNS posluitelj i time napada dobiva mogunost proizvoljnog baratanja sa cijelom napadnutom zonom.

Preusmjeravanje NS zapisa odredine domene - omoguava preusmjeravanje DNS posluitelja neke druge domene (nevezane uz originalni upit) na proizvoljnu napadaevu IP adresu. Napadaev DNS posluitelj odgovara u autoritativnom odjeljku za napadnutu domenu (nevezanu uz originalni upit) sa NS zapisom u traenoj domeni, a u

24/90


dodatnom odgovoru daje A zapis sa IP adresom dotinog DNS posluitelja. Time dolazi do iste funkcionalnosti kao i u prolom napadu.

Trei tip napada je napad identifikacijom - kod kojeg je osnovna ideja predvianje 16bitnog identifikacijskog broja u DNS komunikaciji. Ako napada uspjeno pogodi isti i bude prvi koji vraa odgovor sa ispravnim brojem, posluitelj/klijent e tretirati njegov odgovor kao ispravan i autoritativan. Naalost, sa to veim brojem istovremenih DNS upita koje posluitelj obrauje, vjerojatnost uspjenog pogaanja (odnosno vjerojatnost kolizije) jedinstvenog broja upita se poveava. Danas moderni softver uglavnom taj problem rjeava kvalitetnijim pseudo-sluajnim generatorima kao i sluajnim izborom visokih izvorinih portova za upite (budui da odgovor mora biti poslan na isti izvorini port).

Veina ovih napada danas je rijeena promjenama u DNS softveru (dakle noviji Bind9 i Djbdns softver) koji uglavnom ignorira dobivene DNS odgovore koji nisu striktno vezani uz prvotni zadani upit. Jedno od osnovnih mjera zatite je ogranienje rekurzivnih upita iskljuivo na podruje lokalne mree. U praksi je ovo esta pogreka, budui da Bind posluitelj o osnovnoj konfiguraciji omoguava rekurzivne upite svima - pa je time udaljenom napadau cijela procedorua trovanja meuspremnika naalost jednostavnija za izvedbu.

Alternativni i sve popularniji pristup sigurnosti je uvoenje sigurnog DNS-a, tzv. DNSSEC sustava. Pojednostavljeno, rije je o koritenju odgovarajuih RR-ova za potpisivanje dijelova zona ili ak cijele komunikacije koristei digitalne potpise i digitalne certifikate kako bi se potvrdila izvornost, integritet i autentinost DNS podataka. Na taj nain (provjeravajui potpis i podatke u zoni) DNS klijent moe provjeriti podatke i za sigurnou znati jesu li oni zaista potekli od traenog autoritativnog DNS posluitelja.

Naposljetku spomenimo problem ne toliko vezan uz sigurnost koliko vezan uz DNS zagaenje (engl. DNS pollution) odnosno bespotrebne DNS upite. primjerice DNS upite za RFC 1918 privatnim adresama je obino dobro lokalno terminirati na DNS posluitelju. Takav promet bespotrebno optereuje vrne DNS posluitelje kao i va posluitelj - budui da se takve adrese koriste iskljuivo u privatnim mreama te niti jedan DNS posluitelj u svijetu nee biti autoritativan za reene adrese. Terminacija se obino rjeava tako da se na razini DNS posluitelja definiraju "prazne" reverzne zone za RFC 1918 klase: 10.in-addr.arpa, 16.172.in-addr.arpa do 31.172.in-addr.arpa i 168.192.in-addr.arpa. Prema recentnim istraivanjima oko 7% svjetskog DNS prometa predstavlja curenje RFC 1918 upita prema vrnim DNS posluiteljima, stoga je 2002. godine formirana dodatna usmjerivaka hijerarhija oko AS112 radi terminiranja upita za RFC 1918 (10.in-addr.arpa, itd.) i RFC 3330 (254.169.in-addr.arpa) adresama.

Postoje jo razliiti tipovi zagaenja koja se deavaju u DNS prostoru: A-A upiti - neispravni DNS klijent alje A upit u kojem je ve sadrana

IP adresa ("Koja je IP adresa raunala sa IP adresom 1.2.3.4?"). Ovo

25/90


je karakteristino za Microsoft Windows NT operacijski sustav, a rjeava se obino koritenjem djbdns servisa ili Bind9 posluitelja koji je autoritativan za svih 256 numerikih zona, pri emu je svaka prazna.

Upiti za krivim TLD-ovima - koji su najee greka u lokalnim konfiguracijama (kriva domena, netona domena, mobilni ureaji, neispravne standardne konfiguracije) ili aplikacijama, pa cure upiti za "localhost", "localdomain", "workgroup" i slinim nepostojeim domenama, odnosno domenama koje bi trebale biti lokalno definirane.

Upiti za adresama vrnih posluitelja - tipino svi DNS posluitelji imaju popis vrnih posluitelja kako bi uope mogli ostvariti poetnu komunikaciju. Povremeno osvjeenje zapisa je normalno zbog istjecanja TTL-a, no RR-ovi za vrne posluitelje imaju tipino TTL od 1000 sati. Ovo je takoer najee greka u filtriranju DNS prometa, neispravnom DNS posluiteljskom softveru i sl.

IPv6 upiti - Bind posluitelj tipino dodatno obavlja najee nepotrebne (ak i ako raunalo nema IPv6 stog) AAAA i A6 upite, primjerice za povezujue zapise.

26/90


2. DNS alatiPostoji cijeli spektar razliitih alata kako za iskusnog DNS administratora, tako i za poetnika. Stoga donosimo tek osnovne alate koji bi trebali omoguiti testiranje individualnih zapisa, konfiguracija i cijelih zona. Nadalje, nekad mnogo koritenu naredbu nslookup ne spominjemo iz jednostavnog razloga - neoprostivo je zastarjela i praktiki neupotrebljiva za iole sloenije zadae.

2.1.Naredba hostNaalost postoje dvije inaice ove naredbe sa istim imenima - jedna je ona koju donosi Bind9 programski paket, a druga je slobodno dobavljiva i nalazi standardno se u veini razliitih Unixoida i Linux distribucija. Mi emo se ovdje orijentirati na potonju inaicu, koja ima prilino vie mogunosti i dodataka. Osnovna sintaksa naredbe je sljedea:

host [-v] [-a] [-t tip_upita] [parametri] [posluitelj]host [-v] [-a] [-t tip_upita] [parametri] -l zona [posluitelj]

Argumenti naredbi su sljedei: -v daje kompletne informacije pri pregledu RR-ova (TTL, klase), te sve

odjeljke (dodatni i autoritativni), -t parametar omoguava pretragu za proizvoljnim tipom RR (mogue

je zadati sve tipove koje smo ve spomenuli), -a odgovara -t any (odnosno -t *), -l omoguava pregled svih zapisa u zoni (obavlja AXFR), te je sa -t

mogue filtrirati koje specifine tipove RR-ova se trai iz cijele zone, -p pri ispisu zone forsira da se obavlja prijenos zone samo sa

primarnog posluitelja, -d omoguava jo detaljniji ispis sa prikazom komunikacije i greaka, -Z daje ispis kakav odgovara standardnoj Bind zoni.

Primjer 12: Koritenje naredbe host

Ispis DNS posluitelja za carnet.hr domenu u Bind formatu:$ host -Z -t ns carnet.hrcarnet.hr. 20667 IN NS dns.carnet.hr.carnet.hr. 20667 IN NS dns2.carnet.hr.carnet.hr. 20667 IN NS bjesomar.srce.hr.

Ispis TXT polja za fsb.hr domenu:$ host -t txt fsb.hrfsb.hr TXT "v=spf1 ip4:161.53.116.0/22 ip4:193.198.206.0/24 ip4:193.198.217.192/27 a mx ptr ~all"

27/90


Ispis svih A zapisa u bofhlet.net domeni:$ host -l -t a bofhlet.netbofhlet.net. A 38.119.119.63ftp.bofhlet.net. A 38.119.119.63host.bofhlet.net. A 38.119.119.63localhost.bofhlet.net. A 127.0.0.1

Pregled DNS posluitelja za hr ccTLD preko dns.srce.hr posluitelja (primijetite toku na kraju domene):$ host -v -t ns hr. dns.srce.hr Server: dns.srce.hrAddress: 161.53.3.7

Query about hr. for record types NSTrying hr ...Query done, 5 answers, authoritative status: no errorhr 86400 IN NS sunic.sunet.sehr 86400 IN NS ns-ext.vix.comhr 86400 IN NS ns.uu.nethr 86400 IN NS dns.srce.hrhr 86400 IN NS ns1.univie.ac.atAdditional information:ns.uu.net 3594 IN A 137.39.1.3dns.srce.hr 86400 IN A 161.53.3.7ns1.univie.ac.at 68394 IN A 193.171.255.2sunic.sunet.se 86394 IN A 192.36.125.2ns-ext.vix.com 3594 IN A 204.152.184.64ns-ext.vix.com 3594 IN AAAA 2001:4F8:0:2:0:0:0:13

2.2.Naredba digNaredba dig je pripadnik neto starije generacije programa, pa je dobar dio njegove funkcionalnosti pokriven u host naredbi. No njegova jednostavna sintaksa je prednost za veinu DNS administratora, a i standardno generira potpuni ispis nalik na Bind zonu. Takoer, reeni alat ima niz korisnih zastavica za detekciju i otklanjanje greaka u udaljenoj konfiguraciji. Najjednostavniji nain upotrebe naredbe dig je sljedei:

dig @posluitelj ime_zapisa tip_zapisa

28/90


Pri emu je posluitelj u formi IPv4 ili IPv6 adrese, ime zapisa je traeno ime RR-a, a tip je odgovarajui tip RR-a. Standardno dig ispisuje sve komentare, koje je mogue ugasiti koritenjem parametra +nocomments. Takoer spomenimo par korisnijih odnosno ee koritenih parametara:

+tcp, +notcp - forsiraju koritenje TCP odnosno UDP DNS komunikacije,

+search, +nosearch - omoguuju odnosno onemoguuju itanje /etc/resolv.conf za search te domain parametrima,

+recurse, +norecurse - omoguuje odnosno onemoguuje postavljanje RD zastavice odnosno rekurzije udaljenog posluitelja,

+trace, +notrace - pregled svih izvrenih upita da se zadovolji pretraga poevi od korijenskih DNS posluitelja nadalje.

Primjer 13: Koritenje naredbe dig

Ispiimo A zapis za jagor.srce.hr:$ dig jagor.srce.hr

; DiG 9.2.4 jagor.srce.hr;; global options: printcmd;; Got answer:;; ->>HEADER


Ispiimo svih 13 korijenskih DNS posluitelja:$ dig +nocomments ns . @a.root-servers.net.; DiG 9.2.4 +nocomments ns . @a.root-servers.net.;; global options: printcmd;. IN NS. 518400 IN NS L.ROOT-SERVERS.NET.. 518400 IN NS M.ROOT-SERVERS.NET.itd.

2.3.Naredba dnswalkJednom kad su postavljene zone i kad ih DNS posluitelj servira svojim klijentima, poeljno je redovno provjeravati ispravnost istih. Jedan od jednostavnijih alata za ovu namjenu je dnswalk, koji e koristei AXFR preuzeti eljenu zonu i ispisati razliite utvrene nekonzistentnosti iste. Prije upotrebe nuno je osigurati se da sa raunala klijenta imate dozvole za prijenos zone (AXFR). Sintaksa je jednostavna (primijetite obaveznu toku na kraju domene):

dnswalk [ -adilrfFm ] domena.

Parametri imaju sljedea znaenja: -a upozorava na viestruke A zapise, -r rekurzivno silazi po poddomenama u potrazi za grekama, -d ispisuje greke na standardni izlaz za greke, -m provjerava zonu samo ako je promijenjena od zadnjeg pokretanja

ovog programa, -F provjerava adrese tako da radi standardnu rezoluciju pojedinog A

zapisa i provjerava dobiveni izlaz sa rekurzivnom rezolucijom (PTR) i usporeuje dobivene rezultate,

-i onemoguuje provjeru za krivim znakovima u labelama, -l omoguava provjeru za neispravnim delegiranjem.

Primjer 14: Koritenje naredbe dnswalk

Pregled greaka u fsb.hr domeni:$ dnswalk -Falr fsb.hr.Checking fsb.hr.Getting zone transfer of fsb.hr. from hobbit.fsb.hr...done.SOA=localhost.fsb.hr contact=postmaster.fsb.hrWARN: www.coma.fsb.hr CNAME zrno.fsb.hr: CNAME (to karmela.fsb.hr)WARN: www.zrno.fsb.hr CNAME zrno.fsb.hr: CNAME (to karmela.fsb.hr)0 failures, 2 warnings, 0 errors.

30/90


2.4.Naredba fpdnsNaredba fpdns kao osnovnu namjenu detekcija softvera udaljenog DNS posluitelja. Ovo je u praksi vrlo korisno za eliminiranje potencijalnih problema u komunikaciji (primjerice, izmeu Djbdns i Bind9 posluitelja i sl). Naravno, kao osnovna metoda detekcije na veini Bind posluitelja moe posluiti i naredba host:

host -t txt -c chaos version.bind posluitelj

No, za skoro sve druge posluitelje nema neke opeprihvaene i standardne metode - pa stoga fpdns vri razliite specifine upite i usporeuje prema internoj bazi za svaki softver. Takoer, fpdns ukazuje na omoguenost rekurzivnih upita udaljenom klijentu, to je takoer vrlo vaan dijagnostiki podatak: u sluaju da udaljeni DNS posluitelj omoguava rekurziju klijentu koji nije u njegovoj domeni oigledno je rije o ozbiljnoj ranjivosti. Dotina naredba ima sljedeu sintaksu:

fpdns.pl [ -c ] [ -d ] [ -f ] [ -F broj_djece ] [ -p port ] [ -Q izvorina_adresa ] [ -r broj_pokuaja ] [ -s ] [ -t vrijeme_upita ] [ -v ] [ posluitelj ]

Parametri imaju ova znaenja: -c koristi pregled CH TXT polja (za Bind softver) ako je mogue, no to

se standardno ne podrazumijeva zbog nepreciznosti (administrator moe upisati proizvoljan sadraj);

-d omoguava detaljni ispis greaka i komunikacije, -f forsira upotrebu CH TXT, -F omoguava kontrolu djece-procesa koji obavljaju identifikaciju,

standardno je to 10 primjeraka, -p daje mogunost promjene odredinog porta za DNS komunikaciju -

naravno, to je standardno port 53, -Q omoguava izbor izvorine adrese to je korisno primjerice na

raunalima sa vie mrenih adresa, -r kontrolira broj ponovnih pokuaja identifikacije, -s smanjuje izlazni ispis na to manje informacija, -t omoguava kontrolu ukupnog vremena komunikacije - primjerice da

se ne eka na posluitelj koji je nedostupan.

Primjer 15: Koritenje naredbe fpdns

Saznavanje verzije posluitelja dns.carnet.hr:$ fpdns dns.carnet.hrfingerprint (dns.carnet.hr, 161.53.123.3): BIND 9.2.0rc7 -- 9.2.2-P3 [recursion enabled]

Odnosno verzije esa1.esa.fer.hr posluitelja:$ fpdns esa1.esa.fer.hr

31/90


fingerprint (esa1.esa.fer.hr, 161.53.71.194): TinyDNS 1.05

Te verzije DNS posluitelja za google.com domenu:$ fpdns ns1.google.com fingerprint (ns1.google.com, 216.239.32.10): BIND 8.3.0-RC1 -- 8.4.4

2.5.Naredba nslintZa razliku od veine opisanih alata, nslint je naredba koja lokalno provjerava ispravnost Bind zona. Na ovaj nain moete provjeriti veinu problema prije nego se uope ponu servirati potencijalno neispravne zone. Naalost, ovaj program ima minus to prijavljuje pretjerano mnogo razliitih informacija o potencijalnim (dakle ne i stvarnim) problemima koje nije mogue filtrirati ili kontrolirati. Takoer, budui da ovaj program radi iskljuivo lokalno - ogranien je na Bind zone. Sintaksa je trivijalna, sa -c parametrom se prosljeuje put do named.conf konfiguracijske datoteke za Bind posluitelj.

Primjer 16: Koritenje naredbe nslint

$ nslint -c /etc/named.confnslint: 161.53.116.6 in use by frodo.fsb.hr. and *.hsasf.hr.nslint: 161.53.116.6 in use by hsasf.hr. and frodo.fsb.hr.nslint: 161.53.116.6 in use by www.hsasf.hr. and hsasf.hr.itd.

2.6.Naredba zonecheckOvaj alat je za krajnjeg korisnika jo jednostavniji od dnswalk naredbe, a obavlja daleko vie temeljitih pretraga ispravnosti i konzistencije DNS zona, kao i razliitih preduvjeta za ispravno funkcioniranje. Izvjetaji su jasni i pregledni, uz svaki problem je priloeno i vrlo jasno objanjenje na engleskom jeziku - pa je time i dobro za DNS administratora-poetnika. Uz ve spomenute prednosti, zonecheck ima i niz argumenata koji omoguavaju fino upravljanje nad ispisom i testovima. Sintaksa je sljedea:

zonecheck [ -hqV ] [ -voet opt ] [ -46 ] [ -c konfiguracija ] [ -n lista_posluitelja ] domena

Argumenti su mnogobrojni ali ne i nuni za normalan rad, gdje su standardne postavke dovoljno dobre. Stoga neemo ii u detalje, a zainteresiranima preporuujemo itanje odgovarajuih prirunika uz program.

Primjer 17: Koritenje naredbe zonecheck

Provjera bofhlet.net domene:

32/90


$ zonecheck bofhlet.netZONE : bofhlet.net.NS ns2.bofhlet.net./38.119.119.64=> ns1.bofhlet.net./38.119.119.63

==> SUCCESS (but 3 warning(s))

2.7.Naredba dnstopRije je o servisu koji omoguava jasne i pregledne statistike DNS upita u stvarnom vremenu. Reeni servis prislukuje mreni promet i analizira DNS upite, kategorizirajui ih po: domeni (TLD, drugog i treeg stupnja), tipu upita, tipu operacije te izvorinoj ili odredinoj adresi. Takoer postoji par ugraenih filtera koji omoguavaju pregled tipinih zagaenja DNS-a: A-A upite i upite za nepostojeim domenama. Sintaksa je sljedea:

dnstop [-aps] [-b izraz] [-i adresa] [-f filtar] [ureaj] [datoteka]

Parametri imaju ova znaenja: -a anonimizira odnosno skriva adrese u ispisu, -b definira BPF izraz za filtriranje mrenog prometa (tipino je sljedei:

udp dst port 53 and udp[10:2] & 0x8000 = 0), -i omoguava ignoriranje reene adrese, -o onemoguava postavljanje mrenog suelja u nain za

prislukivanje svog prometa (engl. promiscuous mode),

33/90


-s i -p omoguavaju prikupljanje informacija o domenama drugog i treeg stupnja,

-f omoguava koritenje dodatnih filtara DNS upita; na raspolaganju su unknown-tlds za

Documents

DNS priručnik - download.tutoriali.orgdownload.tutoriali.org/Tutorials/Server/DNS_prirucnik.pdf · D. Korunić: DNS priručnik, v1.5 1.Uvod Na današnjem Internetu je tzv. DNS jedan