Skripta za Osnove telekomunikacija

(drugi dio)

1. ARP

ARP - Address Resolution Protocol je TCP/IP protokol koji se koristi da pretvori IP adresu u fizicku adresu, tzv DLC (Data Link Control) adresu, kao što je Ethernet adresa. Host (cvor) u mreži koji želi dobiti neku fizicku adresu emituje (broadcst) ARP zahtjev (request) u TCP/IP mrežu. Cvor na mreži koji ima adresu iz zahtjeva, u odgovoru šalje svoju fizicku (hardware) adresu. Postoji još i Inverzni ARP (Reverse ARP – RARP) koji se koristi za otkrivanje sopstvene IP adrese. Host emituje u mrežu (broadcast) svoju fizicku adresu, a RARP server mu u odgovoru šalje IP adresu. ARP je protokol koji IP protokol koristi da bi utvrdio odnos izmedu IP mrežnih adresa i fizickih adresa koje koristi DLL protokol. Gledajuci OSI-ISO strukturu, ARP funkcionira nešto ispod treceg sloja i obicno se koristi u Ethernet mrežama. Termin pronalaženje adrese (address resolution) odnosi se na pronalaženje fizicke adrese racunara u mreži. Pronalaženje adrese se dešava tako da "klijent" proces na jednom racunaru šalje odredenu informaciju "server" procesu na drugom racunaru. Informacija u zahtjevu omogucava "serveru" da razluci o kojem se sistemu radi na osnovu cega "server" generiše odgovor. Proces pronalaženja se završava kada "klijent" dobije od "servera" odgovor u kojem se nalazi tražena adresa. U objašnjenju su termini "klijent" i "server" upotrijebljeni sa navodnicima zato što svaki host u okviru implementacije ARP protokola ima aktivna oba procesa. U Ethernet mreži koriste se fizicke adrese koje identificiraju izvorište (source) i odredište (destination) svakog okvira koji se šalje Ethernet protokolom. Fizicka Ethernet adresa se sastoji od 6 bajta (48 bita). Primjer fizicke adrese bi bio 00-01-02-AB-23-0F. Adresa odredišta može se koristiti da se naznaci da se radi o broadcast paketu – paketu koji je namijenjen za sve racunare spojene na tu mrežu. U tom slucaju se u polju odredišta nalaze sve jedinice (FFFF- FF-FF-FF-FF). Fizicka adresa se još naziva i MAC adresa (Medim Access Controll address). Svaki racunar u mreži ima mrežnu karticu (network interface card – NIC). Svakoj mrežnoj kartici je dodijeljena globalno jedinstvena fizicka adresa koja se pohranjuje u PROM. Ova adrese se koristi kao adresa izvora (source address) za svki okvir koji ova kartica šalje. Kartica prima sve okvirove o koji u adresi odredišta (destination address) imaju njenu fizicku adresu o koji u adresi odredišta imaju broadcast (FF-FF-FF-FF-FF-FF) adresu Ako je kartica konfigurisana za multicast, tada kartica može primati okvirove namijenjene za odredeni skup fizickih adresa. Pošto Ethernet funkcionira na drugom sloju, a IP funkcionira na mrežnom i radi sa mrežnim adresama, i ne brine se o fizickim adresama, neophodan je mehanizam odredivanja jednoznacne veze izmedu fizickih i IP adresa. U ovu svrhu, u okviru drajvera (software driver) za mrežnu karticu implementirani su ranije pomenuti procesi ARP "klijent" i "server" koji moraju biti aktivni na svim racunarima koji trebaju funkcionisati u IP/Ethernet mreži. Postoje cetiri tipa ARP poruka koje se šalju ARP protokolom. Tip poruke se identificira uz pomoc cetiri vrijednosti koje može imati "operation" polje ARP poruke. Tipovi poruka su: 1. ARP request 2. ARP reply 3. RARP request 4. RARP reply

Format ARP poruke dat je na slici:

Da bi se smanjio broj zahtjeva za odredivanje fizicke adrese, "klijent" proces pohranjuje vec razlucene adrese u memoriju koja se naziva ARP keš (ARP cache). Da nebi došlo do toga da se u memoriji nalaze informacije koje ne odgovaraju stvarnom stanju na mreži (npr. promjene adresa, racunar više nije aktivan), iz sadržaja ARP keša se periodicki brišu informacije o adresama racunara sa kojima se ne komunicira, te onih racunara koji koji su postali nedostupni. Još jedan mehanizam se koristi za smanjenje broja zahtjeva. Obzirom da se u ARP zahtjevu nalazi IP adresa "klijenta", nakon što je "server" proces primio ARP zahtjev, u ARP keš se upisuje fizicka adresa i IP "klijenta" koji je poslao zahtjev. Primjer upotrebe ARP-a Slika ispod pokazuje proces u kojem racunar pokušava kontaktirati drugi racunar "sysa" uz pomoc PING programa. Uzima se da nije bilo ranije komunikacije izmedu ova dva sistema i da se mora koristiti ARP da bi se identificirala fizicka adresa drugog racunara. Poruka sa ARP zahtjevom ("Y.Y.Y.Y pita: ko je X.X.X.X ?", gdje su X.X.X.X i Y.Y.Y.Y IP adrese) šalje se kao broadcast. Pošto su broadcast primili svi sistemi u mreži, ciljani sistem odgovara a ostali bez obavještenja ignorišu ovaj ARP zahtjev. Sistem na kojeg se odnosi poruka kreira ARP odgovor ("X.X.X.X je hh:hh:hh:hh:hh:hh", gdje je hh:hh:hh:hh:hh:hh fizicka adresa racunara cija je IP adresa X.X.X.X). Ovaj paket se šalje direktno na adresu racunara koji je uputio zahtjev (u ovom slucaju Y.Y.Y.Y). Po prijem u paketa sistem sa IP adresom Y.Y.Y.Y u svoj ARP keš upisuje utvrdenu IP i fizicku adresu. Obzirom da je originalni zahtjev sadržavao fizicku adresu racunara koji je poslao zahtjev, nepotrebno je slanje novog ARP zahtjeva kojim bi se saznao ovaj podatak tako da sistem sa adresom X.X.X.X upisuje u svoj ARP keš IP i fizicku adresu sistema koji je poslao ARP zahtjev. Nakon toga se obavlja komunikacija vezana za PING program.

2. IEEE 802.11

IEEE 802.11 je skupina standarda za bežične lokalne mreže (WLAN) koji su rezvijeni od strane radne grupe 11. međunarodnog tijela IEEE 802.

Skupina standarda 802.11 trenutačno sadrži šest načina bežične modulacije signala, koji koriste isti protokol, a najčešći načini su definirani a, b i g dodatcima izvornom standardu koji se ponekad naziva "802.11 legacy"; sigurnosne odredbe su naknadno dodane i okupljene su u

802.11i dodatku. Ostali dodatci ove porodice (c-f, h-j, n) su servisna podoljšanja i proširenja ili ispravke prijašnjih odredbi. 802.11b je prvi široko rasprostranjeni bežični standard, a 802.11g je trenutačno u najvećoj ekspanziji, dok je 802.11a slabije raširen, ali također vrlo prisutan u svijetu.

802.11b i 802.11g standardi koriste nelicencirani pojas frekvencija na 2,4 GHz. Standard 802.11a koristi frekvencije na 5 GHz. Radom na tim frekvencijama, 802.11b i 802.11g uređaji mogu biti ometani od strane mikrovalnih pećnica, bežičnih telefona, kamera i drugih uređaja koji također koriste taj "neregulirani" pojas frekvencija.

Proizvodi napravljeni prema ovim standarima često nose zaštitni znak Wi-Fi.

802.11b i 802.11g dijele područje frekvencija u 14 međusobno preklopljenih kanala koji su široki po 22 MHz. Kanali 1, 6 i 11 (a u nekim zemljama i 14) međusobno se ne preklapaju i te kanale (ali i druge koji su jednako razmaknuti) moguće je koristiti tako da više mreža može raditi jedna blizu druge a da se ne ometaju.

Kanali 10 i 11 su jedini koji su dostupni u svim dijelovima svijeta, jer Španjolska nije dopustila upotrebu kanala od 1. do 9. za 802.11b uređaje.

3. Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) protokol ostvaruje identifikaciju dva sugovornika povezana preko raèunalne mreže i zaštiæeni prijenos podataka meðu njima.

Internet je svojom komercijalizacijom stvorio potrebu za veæom sigurnošæu prijenosa. Donedavno je Internet bio mreža uglavnom akademskih graðana koji su slobodno razmjenjivali podatke. Nikakva zaštita nije bila potrebna, kljuèna je bila efikasnost. U skladu s tim raðeni su i protokoli za prijenos podataka, kao što je telnet, ftp, http i brojni drugi koji ostvaruju traženi prijenos podataka, ali ne i njihovu zaštitu.

Iako je danas potreba za zaštitom podataka osnova za komercijalnu upotrebu mreža, niti velike organizacije i poduzeæa ne mogu si priuštiti mijenjanje postojeæih protokola, zbog broja korisnika koji ih koriste.

Rješenje ove dileme je u prijenosu nezaštiæenih podataka kroz zaštiæene komunikacijske kanale. Upravo to radi SSL protokol. Zaštitu ostvaruje snažnim šifriranjem, a za identifikaciju koristi poznatu tehniku: sustav javnih kljuèeva (Public Key Criptography).

Prilikom stvaranja SSL-a postavljeni su sljedeæi ciljevi (po prioritetima):

1. Kriptografska zaštita (Criptographic Security). SSL ostvaruje zaštitu podataka za ostvarenje sigurne veze izmeðu dva sudionika u komunikaciji.

2. Neovisnost o softveru i hardveru (Interoperability). Omoguæiti programerima stvaranje softvera koji implementira SSL tako da dva razlièita softvera mogu razmijeniti parametre šifriranja, bez meðusobnog poznavanja kôda.

3. Proširivost (Extensibility). Kreirati okvir unutar kojeg se mogu uklopiti nove metode šifriranja

javnim i simetriènim kljuèem ukoliko se se za to pojavi potreba. Time se istovremeno ostvaruju dva podcilja:

spreèava potrebu za stvaranjem novih protokola (uz rizik njihovih moguæih nedostataka)

spreèava potrebu implementacije potpuno novih metoda šifriranja

4. Relativna efikasnost (Relative efficiency). Šifriranje zna biti vrlo zahtjevno za procesor

raèunala, posebno kada se koristi asimetrièno šifriranje. Zbog toga SSL pamti (cache)

komunikacijske parametre ostvarenih veza kako bi smanjio broj veza koje mora ispoèetka

stvarati, èime ujedno manje optereæuje mrežu.

Zadatak je Secure Sockets Layer (SSL) protokola ostvariti zaštiæeni prijenos podataka kroz mrežu. SSL protokol ukljuèuje identifikaciju servera, identifikaciju klijenta i šifriranu razmjenu podataka meðu njima. To postiže koristeæi tehnike šifriranja i identificiranja opisane u prethodnom poglavlju, a organizirane su na naèin koji èini potpun sustav zaštite komunikacije dva entiteta vezana na mrežu.

SSL protokol ostvaruje zaseban komunikacijski sloj smješten na pouzdan transportni sloj (npr. TCP/IP), dok se na SSL smješta aplikacijski sloj. Od aplikacijske razine prima poruku koju treba poslati, rastavi je u manje dijelove prikladne za šifriranje, dodaje kontrolni broj, šifrira, eventualno komprimira, zatim te dijelove pošalje. Primalac primi dijelove, dekomprimira, dešifrira, provjeri kontrolne brojeve, sastavi dijelove poruke te ih preda aplikacijskoj razini. Na taj naèin ostvaruje zaštiæeni kanal prijenosa kroz mrežu.

SSL je transparentan i neovisan o aplikacijskom sloju, a zaštiæenu vezu uspostavlja prije nego aplikacijska razina primi ili pošalje makar jedan byte podataka. Prije nego poène slati zaštiæene podatke kroz mrežu, SSL identificira server (opcionalno i klijenta) koji komuniciraju. SSL se sastoji od dva protokola:

SSL Handshake (rukovanje) protokol koji omoguæuje klijentu i serveru meðusobnu identifikaciju te razmjene parametara za prijenos šifriranim kljuèem (algoritam i kljuèeve)

SSL Record (zapis) protokol koji je zadužen za šifriranje i prijenos poruka.

Za uspostavljanje zaštiæenog prijenosa podataka SSL zahtijeva minimalno identifikaciju servera. To èini u fazi uspostavljanja razgovora (handshake) pokazivanjem svoju potvrdu klijentu. Za identifikaciju se koristi sustav javnih kljuèeva i digitalni potpis. Nakon identifikacije servera, klijent i server meðusobno razmjenjuju poruke šifrirane simetriènim kljuèevima, što je znatno brže od rada s asimetriènim kljuèevima, i štiti podatke od prisluškivanja i neovlaštenog mijenjanja.

Server može tražiti klijenta da se identificira (nije nužno za ostvarenje zaštiæenog prijenosa). Proces identifikacije klijenta identièan je identifikaciji servera, nakon èega može poèeti razmjena podataka.

! Komunikacija servera ili klijenta sa izdavaocem potvrda nije dio SSL protokola. Komunikacija sa izdavaocem potvrde prilikom identifikacije entiteta na potvrdi odreðena je Preporukama ITU-T X.509 odnosno ISO-IEC Standardom 9594-8.

SSL može uspostaviti razgovor izmeðu klijenta i servera bez identifikacije klijenta ili servera. Dakako, tada je zaštita prijenosa podataka vrlo niska, samo simetriènim šifriranjem i to kljuèem koji je nezaštiæenom komunikacijom dogovoren izmeðu klijenta i servera.

Zaštita komunikacije koju ostvaruje SSL ima tri osnovna svojstva:

Veza je privatna. Podaci koji se razmjenjuju su šifrirani. Koriste se algoritmi za simetrièno šifriranje DES i RC4.

Identitet klijenta odn. servera može se provjeriti javnim kljuèem. Koriste se algoritmi sustava javnih kljuèeva RSA i DSS.

Veza je pouzdana. Provjerava se izvor i potpunost primljenih podataka. Koriste se algoritmi za raèunanje kontrolnih brojeva SHA i MD5.

Za ostvarivanje zaštiæenog prijenosa SSL trebaju podržavati i klijent i server.

Prikaz rada SSL-a

Kada klijent dâ zahtjev za vezu odreðenom serveru, a jedan od sudionika zahtijeva SSL vezu, prvo na red dolazi SSL Handshake protokol - uspostavljanje razgovora. Naèin rada SSL Handshake protokola i izazovi sa kojima se treba suoèiti dani su u ovom prikazu. Radi slikovitosti u prikazu komuniciraju Ana i Branko, što u stvarnosti mogu biti dva servera, ili server i klijent. Zapis {nešto}kljuè oznaèava da je nešto kodirano kljuèem.

Provjeravanje vjerodostojnosti identiteta Zadatak identifikacije je provjera je li entitet (klijent ili server) sa kojim je komunikacija ostvarena zaista onaj koji tvrdi da je.

Ana javlja Branku da želi s njime komunicirati.

A->B neka-poruka

Branko koristi svoj privatni kljuè da šifrira poruku i vraæa je natrag Ani.

B->A {neka-poruka}brankov-privatni-kljuè

Ana prima poruku i dešifrira je Brankovim javnim kljuèem koji je on prije objavio. Ana usporeðuje je li poruka koju je poslala Branku identièna s onom koju je dekodirala. Ukoliko jest, ona zna da razgovara s Brankom.

Ukoliko se netko drugi želi predstaviti kao Branko, neæe moæi jer ne zna Brankov privatni kljuè, te neæe moæi poslati Ani kodiranu neku-poruku umjesto Branka.

Opasnost "probijanja" privatnog kljuèa Osim ako smo potpuno sigurni s kime komuniciramo, nije mudro kodirati primljenu poruku i zatim je poslati dalje. U takvoj je situaciji onome tko prisluškuje komunikaciju moguæe otkriti kljuè kojim je poruka šifrirana na osnovu poslane poruke i te iste kodirane poruke.

Zato je potrebno da Branko ne kodira primljenu poruku veæ da kodira neki novi sadržaj.

A->B Bok, si ti Branko?

B->A Bok Ana ja sam Branko

{Bok Ana ja sam Branko}brankov-privatni-kljuè

Kod ovakve komunikacije, Branko se ne ugrožava kodiranjem svoje poruke jer nije kodirao ništa što bi moglo ugroziti sigurnost komunikacije. Branko prvo šalje nekodiranu poruku i zatim tu istu, ali kodiranu. Ana time lako može ustanoviti da je Branko zbilja Branko. Ovdje se radi o digitalnoj ovjeri, koju SSL vrši nad sluèajno odabranim podacima iz meðusobnog razgovora klijenta i servera.

Specifikacija SSL protokola

Kada SSL Handshake protokol napravi identifikaciju servera i/ili klijenta te dogovori naèine šifriranja meðu njima, kažemo da je uspostavljen razgovor (session). Veæ je prije reèeno kako su operacije s asimetriènim kljuèevima zahtjevne za raèunalnim resursima. Dodamo li tome procese provjeravanja potvrde i dogovaranje oko naèina simetriènog šifriranja, uoèavamo kako je uspostavljanje razgovora relativno dugotrajna faza. Èesto puta klijent i server žele paralelno uspostaviti više razgovora, npr. prijenos datoteke i èitanje www sadržaja. Ponovno izvoðenje faze uspostavljanja razgovora, sa identifikacijom i dogovaranjem atribura simetriènog šifriranja za svaku razgovor sa istim serverom bilo bi nepotrebno. Zato je omoguæeno unutar jednog razgovora uspostaviti više veza (connection). Time je moguæe optimirati komunikaciju izmeðu klijenta i servera.

Razgovori i veze

Razgovor je opisan atributima koji se dogovaraju unutar faze uspostavljanja razgovora izmeðu klijenta i servera. Ti atributi osnova su za uspostavljanje svake nove veze. SSL dozvoljava više veza unutar jednog razgovora, ali i odvijanje više razgovora paralelno izmeðu istog klijenta i servera.

Logièno, ovi atributi poznati su i klijentu i serveru te svaki èuva svoju kopiju njihovih vrijednosti. Zadatak je SSL Handshake protokola usklaðivati - izjednaèavati njihove vrijendosti.

SSL dozvoljava promjenu atributa razgovora i veze za vrijeme njihovog trajanja èime se postiže dodatna moguænost zaštite. Kako bi proces mijenjanja atributa prošao bez utjecaja na tijek komuniciranja, potrebno je da i klijent i server èuvaju po dvije kopije svih atributa: "aktivne" i "nove". Dodatno, odvojeno se èuvaju atributi za slanje i atributi za primanje poruka. Kada klijent ili server prime nove atribute za dešifriranje, "novi atributi" postaju "aktivni atributi" koji se od tog trenutka koriste za daljnje dešifriranje. Oni se ne mogu odmah upisivati u "aktivne", jer je poruka koja sadrži nove atribute još je uvijek šifrirana s "aktivnim". Isto je kada klijent ili server promijene naèin šifriranja za slanje: "novi atributi šifriranja" se pošalju sugovorniku, a nakon toga postaju "aktivni atributi šifriranja" koji se koriste od tog trenutka na dalje. Poruka o promjeni naèina šifriranja su i same šifrirane koristeæi "aktivne atribute".

SSL Record protokol

Record protokol (ili Record sloj) prima podatke od višeg sloja u blokovima proizvoljnih duljina. Same podatke ne interpretira, veæ ih reže u dijelove odgovarajuæih duljina, koje zaštiti i šalje sugovorniku, gdje se odvija obrnuti proces.

Prije daljnje obrade primljeni podaci se fragmentiraju u blokove fiksne dužine. Prilikom toga ne obazire se na dužinu klijentovih poruka. Tako više klijentskih poruka može biti spojeno u jedan fragment ili jedna poruka podijeljena u više fragmenata.

Svi se fragmenti Record protokola komprimiraju algoritmom definiranim u atributima razgovora. Algoritam za komprimiranje mora biti takav da ne dolazi do gubitaka podataka tokom kompresije (lossless). Ukoliko je u atributu zapisana null vrijednost, komprimiranje se ne vrši.

Poruke se zaštiæuju simetriènim šifriranjem i MAC algoritmom koji su definirani u atributima razgovora. Ukoliko su na tim atributima zapisne null vrijednosti podaci neæe biti zaštiæeni.

Šifrira se komprimirani fragment i dodaje mu se MAC vrijednost. Rezultat je spreman za slanje. Dakako, uz taj obraðeni fragment šalju se i drugi podaci nužni za prijenos poruke (zaglavlje) no ti podaci nisu specifièni za SSL protokol pa nisu ovdje ni navedeni.

Primalac dešifrira primljeni fragmet, izraèunava iz njega MAC vrijednost te ako ona odgovara primljenoj MAC vrijednosti poruka se prihvaæa, u suprotnom se vraæa obavijest o grešci.

Obavijesti

Za osiguranje ispravnog tijeka razgovora SSL protokol koristi posebnu vrstu poruka - obavijesti. Obavijesti su, kao i ostale poruke, komprimirane i šifrirane, ne sadrže podatke iz višeg sloja nego sadrže vrstu obavijesti i opis. Možemo razlikovati dvije vrste obavijesti: o kraju veze i o grešci.

Klijent i server moraju se prije prekida veze usaglasiti da nastupa njen kraj, što èine sa obavijesti o kraju veze. Kraj može inicirati bilo koji sugovornik. Takva poruka govori primaocu da pošiljalac više neæe slati poruke unutar te veze. Ukoliko primalac primi poruke nakon obavijesti o kraju, ignorirat æe ih.

Svaki je sugovornik obavezan poslati upozorenje o kraju slanja. Time on i dalje može (ali ne mora) primati poruke dok ne primi od drugog sugovornika njegovu obavijest o prestanku slanja. Ujedno je obaveza drugoga da "zatvori" vezu, odnodno proglasi nevažeæima njezine atribute.

I klijent i server nakon zatvaranja veze moraju zaboraviti vrijednosti njezinih atributa.

Ukoliko se ustanovi greška prilikom komunikacije sugovornik koji ju je ustanovio o tome obavještava drugog sugovornika.

Ako se radi o grešci koja ugrožava sigurnost prijenosa (fatal alert) oba sugovornika istovremeno prekidaju vezu. Druge veze unutar razgovora mogu nastaviti svoju komunikaciju, ali je nužno da se promijeni identifikator razgovora kako bi se sprijeèila upotreba dosadašnjeg identifikatora za otvaranje nove veze od strane nepodobnog sugovornika.

Moguæe greške u SSL protokolu

Neoèekivana poruka primljena je neodgovarajuæa poruka. Ova greška uvijek rezultira prekidom veze.

Neispravna MAC vrijednost ukoliko se ustanovi neispravna MAC vrijedost takoðer se prekida veza.

Greška prilikom dekompresije ulazna vrijednost dekompresijskog alogritma nije dovela do oèekivanog rezultata (npr. neodgovarajuæa duljina rezultata dekomprimiranja).

Greška prilikom faze uspostavljanja razgovora primaocu ova obavijest govori da pošiljalac nije u moguænosti uskladiti se s atributima zaštite koji su mu dani na biranje. Ova greška razultira prekidom razgovora (u ovom sluèaju veze još nisu uspostavljene).

Nema potvrde ova se greška može pojaviti ukoliko na zahtjev potvrde sugovornik odgovara da je nema.

Loša potvrda potvrda je mijenjana (nekonzistentna), sadržani potpis ne potvrðuje identitet, i sl.

Nevažeæa potvrda period važenja potvrde je prošao ili još nije došao.

Neprikladna potvrda dotièan tip potvrde nije podržan od strane protokola.

Ukinuta potvrda potvrda je ukinuta od strane vlasnika.

Nepoznata potvrda ukoliko je tokom obrade potvrde došlo do neke neoèekivane situacije, potvrda se proglašava neprihvatljivom.

Nevažeæi parametar vrijednost nekog atributa je izvan dozvoljenih vrijednsoti ili je nekonzistentan s ostalim vrijednostima. Ova greška rezultira prekidom veze.

SSL Handshake protokol

Atribute koji opisuju razgovor stvara SSL Handshake protokol koji djeluje iznad Record sloja. Handshake protokol poruke predaje Record protokolu koji ih kao i sve druge poruke šifrira i pošalje. Prije faze uspostavljanja razgovora (handshake faze) njegovi atributi nisu odreðeni tako da se prve poruke šalju nezaštiæeno. Zahvaljujuæi sustavu javnih kljuèeva to ne ugrožava prijenos poruka.

Kada SSL klijent i SSL server prvi puta poènu komunicirati dogovaraju se o verziji protokola, odabiru algoritama za simetrièno šifriranje, opcionalno se identificiraju te se dogovore oko tajne koju æe koristiti za šifriranje. Taj proces odvija se u Handshake protokolu.

Ukratko proces se može opisati ovako: klijent pošalje pozdravnu poruku serveru, na koju server mora odgovoriti svojim pozdravom, u suprotnom dolazi do prekida komunikacije. Ove pozdravne poruke koriste se za uspostavljanje sljedeæih atributa razgovora: verzije protokola, identifikator razgovora, algoritme šifriranja, algoritma za kompresiju i sluèajnih vrijednosti klijenta i servera. Klijent u svojem pozdravu ponudi serveru listu moguæih naèina šifriranja i komprimiranja (poredane po redosljedu najboljeg odabira - prvi je najbolji) iz koje server odabire sebi najbolju kombinaciju koju može prihvatiti.

Nakon pozdravne poruke server šalje svoju potvrdu, ukoliko ga treba identificirati (što je najèešæi sluèaj).

Kad je server pozitivno identificiran, on može tražiti klijenta njegovu potvrdu, ukoliko je to u skladu sa dogovorenim algoritmima šifriranja. Zbog više moguæih varijacija serverog pozdrava, klijent ne može zakljuèiti kada nastupa njen kraj, zato server šalje klijentu poruku o kraju pozdrava. Ako je server zatražio od klijenta potvrdu oèekuje ili odgovor koji sadrži poruku ili obavijest da klijent potvrdu nema.

U ovom trenutku klijent šalje svoje nove atribute kojima æe slati šifrirane podatke i "nove atribute" postavlja za "aktivne atribute". Zatim šalje obavijest o kraju slanja šifriranu "aktivnim atributima". Kao odgovor, server šalje svoje atribute, te nakon toga njima šifriranu obavijest o kraju slanja.

Sada je faza uspostavljanja razgovora (Handshake) završena te klijent i server mogu poèeti razmjenjivati podatke aplikacijske razine.

Klijent i server imaju moguænost iznova zapoèeti veæ postojeæi razgovor. Time se preskaèe provjera vjerodostojnosti i dogovaraju se samo nužni novi atributi. To poveæava fleksibilnost pri optimiranju metode zaštite.

U toj situaciji razgovor izgleda ovako: klijent pošalje pozdravnu poruku koristeæi identifikator razgovora koji želi iznova zapoèeti. Server provjerva listu svojih razgovora i traži postoji li taj identifikator razgovora. Ako ga naðe i voljan je obnoviti taj razgovor, odgovara svojim pozdravom koji sadrži taj identifikator. Sada i klijenti i server moraju poslati svoje nove atribute šifriranja nakon èega odmah šalju poruku o kraju uspostavljanja razgovora (ne pozdrava, pošto je nepotrebna preskaèe se). Podaci s aplikacijske razine mogu se slati.

Ukoliko server ne naðe identifikator razgovora u svojoj listi, odgovara novim identifikatorom i server i klijent provode potpuno uspostavljanja razgovora.

SSL protokol u primjeni

SSL protokol stvoren je kao odgovor rastuæim zhatjevima za zaštiæen prijenosa podataka na Internetu. Zbog pravovremenog nastanka te zbog tržišne uloge poduzeæa Netscape Communications, stvaraoca ovog protokola, SSL je postao vrlo rasprostranjen. SSL osim što je odobren kao standard od strane www consortiuma (www.w3.org) postao je de facto standardom.

Uz SSL razvijala su se i druga rješenja koja ostvaruju zaštiæen prijenos podataka kroz mrežu. Uspješnost SSL-a dodatno je naglašena nedostatkom drugih dovoljno dobrih rješenja koji bi ga zamijenila. Dat æu kraæi pregled nekih od rješenja.

S-MIME Secure-MIME protokol razvila je RSA i dodatak je veæ postojeæem MIME protokolu. Koristi sustav javnih kljuèeva kao osnovu za provjeru vjerodostojnosti i šifriranje. Algoritmi za šifriranje i rad s potvrdama identièni su onima korištenim u SSL-u tako da se iste potvrde mogu koristi i u ovom protokolu. Korisnicima MIME-a S-MIME omoguæuje zaštitu identiènu u ovom radu opisanoj zaštiti koju pruža SSL. Sve radnje potrebne za provjeru vjerodostojnosti i šifriranje automatizirane su u softveru koji koristi S-MIME tako da je za korisnika vrlo jednostavan za upotrebu.

S-HTTP Secure HTTP je dodatak HTTP-u, dakle djeluje na aplikacijskoj razini ISO/OSI modela. Za razliku od SSL-a koji ima zadatak ostvariti zaštiæeni kanal izmeðu klijenta i servera, S-HTTP ima za cilj zaštiæeno prenijeti pojedinaènu poruku. Takoðer omoguæuje provjeru vjerodostojnosti pošiljaoca poruke te šifriranje poruke kao i SSL. Razlog nerasprostranjenost ovog protokola je neuspješan marketing koji ga je pratio, iako zadovoljava veæinu zahtjeva traženih na tržištu. Zbog djelovanja na razlièitim razinama ISO/OSI modela moguæe je kombinirano koristiti S-HTTP i SLL.

SSH Secure Shell koristi se za spajanje na udaljeno raèunalo. Stvara zaštiæeni kanal izmeðu dva raèunala, a identifikacija se vrši pomoæu lozinke (uobièajeno prilikom pristupanja udaljenom raèunalu) koju prije slanja kroz mrežu šifrira. Ne omoguæuje identifikaciju pomoæu potvrda. SSH kao i SSL djeluje na nekom pouzdanom protokolu, najèešæe je to TCP.

PEM Private Enhanced Mail omoguæuje zaštiæeni prijenos e-mail poruka koristeæi provjeru vjerodostojnosti potvrdama, zaštitu sustavom javnih kljuèeva i provjeru integriteta pomoæu kontrolnog broja. PEM nije vezan za neki odreðen operativni sustav ili vrstu korisnika pa ga podržava velik broj softverskih proizvoda. Ogranièenje koje postavlja PEM je moguænost slanja samo tekstualnih poruka (ASCII).

MOSS MIME Object Security Services je protokol koji pruža iste elemente zaštite kao i PEM, ali i za MIME objekte. Nije jako rasprostranjen, a zbog loše specifikacije nailazi se na razlièite implementacije istog protokola.

PCT Private Communication Technology je proizvod Microsofta koji je nastao kao reakcija na SSL verziju 2. Ta je verzija SSL-a imala probleme u situacijama kada je došlo do nasilnog prekida veze èime je napadaè dobio priliku da se ukljuèi u razgovor bez identifikacije. PCT je uklopio sve prednosti SSL-a te riješio uoèene probleme. Èim se pojavio SSL verzija 3, gdje su riješeni postojeæi problemi i dodane druge moguænsoti PCT je zasjenjen i rijetko se koristi.

SHEN SHEN je zamjena za postojeæi HTTP. Razvijen je u CERN-u, gdje i sam HTTP zbog èega je zapažen, ali nije zaživio te je danas teško pronaæi informacije o njemu.

PGP Pretty Good Privacy je proizvod koji pruža moguænost identificiranja privatnim kljuèem, provjeru integriteta i šifriranje. Ne podržava provjeru vjerodostojnosti pomoæu potvrda. Za upotrebu korisnik je primoran dosta toga samostalno napraviti pa zna biti nespretan.

Uspjeh SSL-a SSL sadrži sve što je potrebno za sigurnu razmjenu podataka preko mrže. Pojavio se na vrijeme na tržištu i široko je prihvaæen od strane korisnika.

SSL sadrži sve raspoložive sigurnosne metode koje prema potrebi možemo ukljuèivati u pojedina uspostavljanja komunikacijskh kanala izmeðu dva sugovornika preko mreže. Omoguæuje provjeru vjerodostojnosti pomoæu potvrda, korištenje razlièitih kljuèeva za pojedini razgovor, šifriranje i provjeru integriteta. Ukoliko su klijent i server neaktivni duže vrijeme ili razgovor s istim atributima zaštite potraje predugo, atributi se mijenjaju.

Dodatno, implementacija u aplikacijskom softveru omoguæuje i administratoru servera i klijentu vrlo jednostavnu upotrebu. Jedini nedostak SSL-a je u tome što traži od programera aplikativnog softvera da dobro poznaje operativni sustav za koji rade softver. Naime, ako operativni sustav direktno pristupa TCP protokolu potrebno ga je preusmjeriti da to radi preko SSL protokola.

Važnu ulogu uspješnosti SSL-a imaju davaoci potvrda. Danas dominiraju dva davaoca potvrdi: Thawte i VeriSign. Davoci potvrda svojim ugledom osiguravaju da korisnici vjeruju njihovim potvrdama, bez èega bi SSL bio beskoristan. Zbog tih svojih karakteristika, SSL ostaje osnova sigurnosnog prijenosa podataka na Internetu.

4. Ethernet

Ethernet (IEEE 802.3) je mrežna tehnologija za LAN mreže, temeljena na frame načinu rada. To

znači da se podaci šalju u paketima koji su prilagođeni za slanje preko računarske mreže.

Definira umrežavanje i signaliziranje za fizički sloj, te frame formate i protokole za MAC,

odnosno podatkovni sloj OSI modela. Ethernet, poznat i pod imenom IEEEs 802.3, je postao

najrasprostranjeniji standard za računarske mreže koji se počeo uzdizati ranih 1990-tih pa sve

do danas gdje drži primat, te je skoro u potpunosti zamijenio ostale mrežne tehnologije za LAN

mreže kao što su Token Ring, FDDI te ARCNET.

Princip rada

Ethernet se sastoji od tri dijela:

Fizičkog medija preko kojeg putuju informacije u računarskoj mreži (UTP kabel itd.) Protokola, odnosno skupa pravila za kontrolu pristupa na mediju Ethernet paketa u kojima se prenose podaci koji su ustvari grupe bitova organizovanih u

polja

Da bi računari u mreži radili potrebno je da svi razumiju isti protokol (set pravila za stvaranje paketa podataka), odnosno da rade po njegovim pravilima. Ethernet protokol određuje da svaki paket završi na zadanoj adresi, pošto po propisu Etherneta svaki paket podataka mora imati adresu odredišta i adresu izvora. Svaki računar u Ethernet mreži ima 48-bitni ključ poznat kao MAC adresa čiji je glavni zadatak osiguravanje različite adrese za računar u mreži. MAC adresa se još zove i hardverska adresa koja je unikatna za svaki proizvedeni Ethernet uređaj. Uređaj preko kojih računar, koji je priključen na Ethernet mrežu, prima podatke se naziva mrežna kartica, koja se najčešće nalazi u sastavu jedne obične matične ploče.

U jednoj Ethernet mreži ne postoji centralni nadzor, te su svi korisnici jednaki. To znači da svi dijele propusnost mreže tako da nijedan korisnik u mreži ne može zauzeti čitav medij samo za

sebe. Pošto se podaci u Ethernet mreži šalju serijski u manjim paketima, velika je mogućnost da se da u isto vrijeme dva ili više korisnika šalju neki podatak na istoj mreži. Da bi se desilo slanje podataka računar mora provjeriti medij, pa tek kada ustanovi da je slobodan počinje prijenos nekog podatka. Taj mehanizam kontrole se naziva MAC (Medium Acces Control) dok se on temelji na CSMA/CD (Carrier Sense Multiple Access with Collision Detection) protokolu.

On se brine za ravnopravno stanje u jednoj računarskoj mreži, ali se brine i za spriječavanje sukoba koje se mogu desiti ako računari u mreži u isto vrijeme ustanove da je medij slobodan. Tada CSMA/CD mehanizam zaustavlja slanje paketa te ga odgađa za ponovno slanje, koje se praktično dogodi u mikrosekundama zbog čega korisnik to i ne primjeti. No ako se kojim slučajem paket 16 puta odbije zbog zauzetosti onda se korisnik obavijesti o nastaloj grešci na mreži, dok on može tek kasnije pokušati slanje podatka.

Za umrežavanje Ethernet mreža najviše se koristi UTP (Cat-5) kabel koji je potisnuo ranije korišćeni koaksijalni i AUI kabel. Oprema za Ethernet mreže je veoma jeftina, jer kako je mrežna kartica već obično na matičnoj ploči sve što treba je da imamo UTP kablove i po potrebi (ako se radi o većim mrežama) mrežne switcheve ili hubove. Brzine se kreću od 10, najčešće 100 Mbps, dok se u posljednje vrijeme sve češće promovira brzina od 1 Gbps.

5. ICMP protokol

ICMP (Internet Control Message Protocol) je protokol internet razine i sastavni dio IP protokola. Definiran je RFC-om 792. Osnovna namjena ICMP protokola je osigurati kontrolu prijenosa podataka do odredišta. Ovaj protokol ne osigurava pouzdani prijenos podataka, to treba osigurati protokol više razine. Poruke se šalju samo kao odgovor na poslane IP pakete, na poslane ICMP pakete odgovor se ne šalje. U slučaju gubitka ICMP poruke, ne generira se nova ICMP poruka o nastaloj pogrešci.

ICMP poruke se šalju koristeći osnovno IP zaglavlje. Prvi oktet polja podataka IP paketa definira tip ICMP poruke, čime je određen format ostatka paketa. Vrijednost polja "Protocol" za ICMP poruku je 1. Svaka ICMP poruka sadrži i IP zaglavlje poruke o čijem gubitku izvješćuje te prvih 64 bita podataka originalnog paketa.

Format ICMP paketa je prikazan na slici 3-6.

Slika 3-6: Format ICMP paketa

Značenja polja su:

Type – Tip ICMP poruke (poruke i njihova značenja su navedeni u nastavku). Code – Za svaki tip poruke definirani su određeni kodovi Checksum – Kontrolni zbroj paketa Identifier – Identifikator paketa Sequence number – Broj sekvence Address mask – 32-bitna maska

ICMP generira osam različitih tipova poruka, od kojih tri zahtijevaju odgovor. Te poruke su:

Odredište nedostupno (engl. Destination Unreachable) - Šalje se kad nije moguće uspostaviti vezu ili pronaći put do odredišnog računala, kao i u slučaju kad odredišno računalo ne može prepoznati koja se usluga od njega potražuje, tj. ne prepoznaje priključnu točku usluge (engl. port). Ako je nedostupna mreža ili računalo, poruku šalje usmjernik, a ako nije prepoznata priključna točka onda ju šalje odredišno računalo.

Istek vremena (engl. Time Exceeded) - Šalje se kad je paket odbačen jer je polje "TTL" postalo jednako nuli. Koristi se za određivanje puta kroz mrežu.

Problem s parametrima (engl. Parametar Problem) - Poruku generiraju usmjernik ili odredišno računalo kad paket treba biti odbačen jer zbog problema s parametrima u zaglavlju ne mogu završiti obradu paketa.

Blokiranje izvorišta (engl. Source Quench) - Generira se kad paketi stižu brže nego što ih odredište može obraditi pa usmjernik ili odredišno računalo šalju izvorištu ICMP poruku za privremeni prekid slanja paketa.

Preusmjeravanje (engl. Redirection) - ICMP poruka koju šalje usmjernik kad u svojoj tablici usmjeravanja nađe bolji put do odredišta. Drugi usmjernik mora se nalaziti u istoj mreži.

Eho zahtjev / eho odgovor (engl. Echo Request / Echo Reply) - Par poruka kojima se saznaje je li odredište aktivno. Adrese izvorišta i odredišta zahtjeva zamjene mjesta u odgovoru. Ove poruke koristi naredba ping.

Vrijeme / odgovor o vremenu (Timestamp / Timestamp Reply) - Šalju se kad je potrebno saznati za koje vrijeme se poruka preko odredišta vrati do izvorišta (RTT - Round Trip Time).

Zahtjev za informacijom / odgovor na zahtjev za informacijom (engl. Information Request / Information Reply) - Koriste se za doznavanje adrese vlastite mreže.

6. TCP protokol

TCP (Transmission Control Protocol) je dominantan, spojevni, prijenosni protokol interneta, garantira pouzdanu isporuku podataka od izvorišta do odredišta u kontroliranom redoslijedu. PDU TCP protokola je segment. Segmenti se pakiraju u IP pakete i šalju preko mreže. Osnovna svojstva usluge koju nudi TCP su:

Pouzdanost Veza od točke to točke Dvosmjerni prijenos podataka Svi podaci tretiraju se kao niz okteta

Prilikom korištenja TCP usluge entiteti prolaze kroz tri faze:

1. Uspostava veze 2. Razmjena podataka 3. Prekid veze

Uspostava veze - Proces koji se izvodi na jednom računalu želi uspostaviti vezu s procesom na nekom drugom računalu. Računalo koje traži uspostavu veze naziva se klijent, a drugo računalo se naziva poslužitelj. Klijentski proces informira klijentski TCP da želi uspostaviti vezu s poslužiteljem. Klijentsko računalo tada šalje poslužitelju prvi specijalni segment. Poslužitelj

odgovara drugim specijalnim TCP segmentom i konačno klijent odgovara trećim specijalnim segmentom. Ova procedura se naziva "three-way handshake". U nastavku slijedi objašnjenje spomenutih segmenata:

1. Klijent prvi šalje specijalni TCP segment poslužitelju. Taj specijalni segment ne sadrži podatke aplikacijske razine. Ima jedan od bitova zastavica u zaglavlju segmenta. To je tzv. SYN bit, postavljen na 1. Iz tog razloga, taj specijalni segment zove se SYN segment. Nadalje, klijent odabire inicijalni redni broj (client_isn) i stavlja ga u polje za redni broj inicijalnog TCP SYN segmenta. Taj segment je uhvaćen u IP datagramu i poslan na internet.

2. Pod pretpostavkom da IP datagram koji sadrži TCP SYN segment stigne do poslužitelja on izdvaja TCP SYN segment iz datagrama, alocira TCP spremnik i varijable i šalje segment kojim odobrava uspostavu veze klijentu. Taj segment odobravanja veze također ne sadrži podatke aplikacijske razine, ali sadrži tri važne informacije u zaglavlju segmenta. Prvo, SYN bit je postavljen na 1. Drugo, Acknowledgment polje zaglavlja TCP segmenta se namješta na isn+1. Na kraju, poslužitelj odabire svoj inicijalni redni broj (server_isn) i stavlja vrijednost u polje zaglavlja TCP segmenta.

3. Kada klijent primi segment odobravanja veze, također alocira spremnik i varijable u vezi. Klijent tada šalje poslužitelju još jedan segment koji potvrđuje da je dobio segment odobravanja veze. To radi tako da stavi vrijednost server_isn+1 u acknowledgement polje zaglavlja. SYN bit postavlja se u 0 budući da je veza uspostavljena.

Kada se sva tri koraka obave, klijent i poslužitelj jedan drugome mogu slati segmente koji sadrže podatke. U svakom budućem segmentu SYN će biti postavljen na 0. Slika 4-1 prikazuje "three-way handshake" proceduru.

Slika 4-1: "Three-way handshake"

Razmjena podataka - TCP entiteti razmjenjuju podatke u obliku segmenata. Segment se sastoji od zaglavlja koje ima 20 okteta (uz opcionalni dio) za kojim slijedi nula ili više okteta podataka, a nastaje skupljanjem podataka od nekoliko upisivanja ili razbijanjem podataka od jednog upisivanja. Veličina segmenta je varijabilna uz dva ograničenja:

Svaki segment uključujući i TCP zaglavlje mora stati u 65 535 okteta IP paketa Svaka mreža ima svoj MTU (Maximum Transmission Unit), a to je najveća dopuštena

jedinica za prijenos koja definira gornju granicu veličine segmenta.

Ako je segment prevelik za mrežu kroz koju mora proći, čvor vrši fragmentaciju u više manjih segmenata od kojih svaki dobiva svoje IP zaglavlje.

Osnovni protokol kojeg koriste TCP entiteti je protokol s klizajućim prozorom (engl. Sliding Window):

1. Nakon slanja segmenta predajnik pokreće brojač (engl. timer) 2. Kad segment stigne na odredište, prijemnik šalje u segmentu potvrdu s brojem jednakim

slijedećem broju segmenta kojeg očekuje 3. Ako brojač istekne prije nego što je primljena potvrda, segment se šalje ponovno

Slika 4-2 prikazuje strukturu TCP segmenta:

Slika 4-2: TCP segment

Značenja polja su:

Source Port - Broj priključne točke usluge izvorišta. Destination Port - Broj priključne točke usluge odredišta. Sequence Number - Redni broj prvog okteta podataka u tom segmentu; ako je

postavljena zastavica S (SYN), onda je to početni redni broj (ISN - Initial Sequence Number), a prvi oktet podataka ima broj ISN+1.

Acknowledgment Number - Broj potvrde; ako je postavljen A (ACK) bit, polje sadrži redni broj sljedećeg okteta kojeg primatelj očekuje.

Offset - Pomak podataka, pokazuje na početak podataka u TCP segmentu, izraženo u 32-bitnim riječima (TCP zaglavlje je uvijek višekratnik 32-bitne riječi).

Reserved – Polje je rezervirano za buduće potrebe; popunjeno je nulama. Kontrolni bitovi:

o URG - Indikator hitnih podataka o ACK - Indikator paketa potvrde o PSH - Inicira prosljeđivanje svih do tada neproslijeđenih podataka korisniku o RST - Ponovna inicijalizacija veze o SYN - Sinkronizacija rednih brojeva o FIN - Izvorište više nema podataka za slanje

Window – Prozor, označava koliko je okteta prijemnik spreman primiti

Checksum - Kontrolni zbroj; računa se kao 16-bitni komplement jedinice komplementa zbroja svih 16-bitnih riječi u zaglavlju i podacima; pokriva i 96 bitova pseudozaglavlja koje sadrži izvorišnu i odredišnu adresu, protokol i duljinu TCP zaglavlja i podataka.

Urgent Pointer - Pokazivač na redni broj okteta gdje se nalaze hitni podaci; polje se gleda jedino ako je postavljena zastavica URG.

Options + Padding - Options mogu, a ne moraju biti uključene; ako postoje, veličine su x×8 bita, Padding je dopuna nulama do 32 bita.

Data - Podaci aplikacijske razine.

Prekid veze - Kada klijentska aplikacija odluči prekinuti vezu s poslužiteljem šalje TCP segment sa FIN bitom postavljenim u 1 i uđe u FIN_WAIT_1 stanje. Dok je u FIN_WAIT stanju, klijentski TCP čeka TCP segment potvrde od strane poslužitelja. Kada primi navedeni segment, klijentski TCP ulazi u FIN_WAIT_2 stanje. Dok je u FIN_WAIT_2 stanju, klijent čeka sljedeći segment od strane poslužitelja s FIN bitom postavljenim u 1. Nakon što primi taj segment klijentski TCP ulazi u TIME_WAIT stanje. TIME_WAIT stanje dopušta TCP klijentu da pošalje finalnu potvrdu u slučaju da je ACK izgubljen. Vrijeme provedeno u TIME-WAIT stanju ovisi o implementaciji, ali tipične vrijednosti su trideset sekundi, jedna minuta i dvije minute. Nakon čekanja veza se formalno zatvori.

7. UDP protokol

UDP (User Datagram Protocol) je jednostavan bespojni protokol prijenosne razine koji omogućava aplikacijama direktno korištenje usluga internet razine, multipleksira promet različitih aplikacija. Demultipleksiranje na granici prijenosne i aplikacijske razine prikazano je na slici 4-4.

Slika 4-4: Demultipleksiranje UDP prometa pojedinih aplikacija

Demultipleksiranje se obavlja pomoću sljedeće četvorke:

(IPS, IPD, PS, PD)

gdje je:

IPS – IP adresa izvorišta, IPD – IP adresa odredišta, PS – Priključna točka izvorišta, PD – Priključna točka odredišta.

Pomoću IP adrese izvorišta i priključne točke izvorišta identificirana je jedna aplikacija (npr. APP2), dok je pomoću IP adrese odredišta i priključne točke odredišta omogućeno paralelno ostvarivanje više UDP veza na istu aplikaciju. Drugim riječima, neka aplikacija, preko jedne priključne točke može istovremeno komunicirati s više aplikacija na udaljenim računalima.

Nekada je bolje za prijenos poruka koristiti UDP protokol umjesto TCP protokola. Neki od tih slučajeva su:

Prijenos podataka aplikacija koje same osiguravaju pouzdani prijenos, ili kada aplikacija dopušta manje gubitke.

Slanje upita jednog računala drugom računalu, uz mogućnost ponavljanja upita ako odgovor ne stigne nakon isteka određenog vremenskog intervala.

Kada je potrebno poslati manji blok podataka, veličine jednog paketa pa je jednostavnije i brže prenositi samo podatke, bez dodatnih kontrola, a u slučaju pogrešnog prijema podatke poslati ponovno.

Slika 4-5 prikazuje format UDP datagrama:

Slika 4-5: Format UDP datagrama

Značenja polja su:

Source port - Izvorišna priključna točka usluge je opcionalno polje. Kada se koristi, označava priključnu točku procesa koji šalje podatke. Na nju će doći odgovor kada ne postoji druga informacija. Ako se polje ne koristi popuni se nulama.

Destination port - Odredišna priključna točka usluge. Length - Duljina UDP datagrama u oktetima uključujući zaglavlje i podatke. Minimalna

duljina UDP datagrama je 8 okteta. Checksum - Kontrolni zbroj zaglavlja, računa se na osnovu pseudo zaglavlja iz IP i UDP

zaglavlja i podataka. Ako je polje ispunjeno nulama znači da predajnik nije računao zbroj; ako je zbroj jednak nuli, prenosi se kao niz jedinica.

Data – Podaci.

8. NAT

Network address translation (NAT) is a methodology of modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device for the purpose of remapping one IP address space into another.

Network address translation was originally used to map every address of one address space to a corresponding address in another space, such as when an enterprise changed Internet service providers without having a facility to announce a public route to the network. Most often today, NAT is used in conjunction with IP masquerading which is a technique that hides an entire IP address space, usually consisting of private network IP addresses (RFC 1918), behind a single IP address in another, usually public address space. This mechanism is implemented in a routing device that uses stateful translation tables to map the "hidden" addresses into a single IP address and readdresses the outgoing Internet Protocol packets on exit so they appear to originate from the routing device. In the reverse communications path, responses are mapped back to the originating IP addresses using the rules ("state") stored in the translation tables. The translation table rules established in this fashion are flushed after a short period unless new traffic refreshes their state.

The method enables communication through the router only when the conversation originates in the masqueraded network, since this establishes the translation tables. For example, a web browser in the masqueraded network can browse a website outside, but a web browser outside could not browse a web site hosted within the masqueraded network. However, most NAT devices today allow the network administrator to configure translation table entries for permanent use. This feature is often referred to as "static NAT" or port forwarding and allows traffic originating in the "outside" network to reach designated hosts in the masqueraded network.

Because of the popularity of this technique to conserve IPv4 address space, the term NAT has become virtually synonymous with the method of IP masquerading.

As network address translation modifies the IP address information in packets, it has serious consequences on the quality of Internet connectivity and requires careful attention to the details of its implementation. NAT implementations vary widely in their specific behavior in various addressing cases and their effect on network traffic. The specifics of NAT behavior is not commonly documented by vendors of equipment containing implementations.[1]

9. HTTP protokol

HTTP je request/response protokol za komunikaciju između poslužitelja (servera) i klijenta. HTTP klijent, kao što je web preglednik najčešće inicira prijenos podataka nakon što uspostavi TCP (vidi TCP/IP) vezu s udaljenim web serverom na određenom portu.

Server konstantno osluškuje zahtjeve na određenom mrežnom komunikacijskom portu (tipično port 80), čekajući da klijent pošalje niz znakova (string), kao što je "GET / HTTP/1.1" - kojim će zahtjevati uspostavljanje komunikacije - a nakon toga i tekstualnu MIME poruku koja sadrži nekoliko slovnih nizova (zaglavlje) koji određuju aspekte zahtjeva, te paket neobaveznih podataka. Nakon "GET" poruke, klijent mora poslati niz znakova koji određuju adresu virtualnog hosta, na primjer "HOST:www.example.com".

Zahtjev (engl. request) klijenta će rezultirati slanjem odgovora (engl. response) s poslužitelja, kao što je "200 OK" - nakon čega će server poslati i svoj paket podataka koji najčešće sadrži traženu datoteku ili poruku o grešci. Odmah po ispunjenju zahtjeva klijenta, server će prekinuti komunikaciju.

HTTP se razlikuje od ostalih TCP protokola kao što je npr. FTP, po tome što se konekcija i komunikacija sa serverom prekida odmah nakon izvršenja zahtjeva klijenta (isporučenog paketa traženih podataka). Zbog ovoga je HTTP idealan za Web, gdje je stranica obično povezana s drugim stranicama na drugim poslužiteljima. Ova karakteristika HTTP protokola povremeno stvara probleme web dizajnerima, s obzirom da nedostatak "perzistentne konekcije" s poslužiteljem moraju nadoknaditi uporabom drugih metoda za očuvanjem korisničkog "stanja". Jedna od tih metoda uključuje uporabu HTTP cookie-a.

HTTPS je sigurna verzija HTTP protokola, koja koristi SSL/TLS za zaštitu i skrivanje prometa, odnosno podataka koji se razmjenjuju između klijenta i poslužitelja. Ovaj protokol obično koristi TCP port 443. SSL (donekle) omogućava zaštitu komunikacije, čak i u slučaju kada je samo jedna strana (obično poslužitelj) autentificirana.

Lokacija HTTP (i HTTPS) dokumenata se određuje pomoću URL adrese. URL adresna sintaksa je kreirana posebno za povezivanje web stranica.

10. IP, što je kratica engleskog izraza Internet Protocol, je mrežni protokol za prijenos podataka kojeg koriste izvorišna i odredišna računala za uspostavu podatkovne komunikacije preko računalne mreže.

Podatci u IP mreži se šalju u blokovima koji se nazivaju paketi ili datagrami. Specifično je da se prilikom slanja paketa između izvorišta i odredišta unaprijed ne određuje točan put preko mreže kojim će podatci prijeći, te u tom smislu govorimo o IP mreži kao o paketskoj mreži.

IP protokol osigurava relativno nepouzdanu uslugu prijenosa podataka na modelu usluge koji se često naziva najboljom mogućom (ili u engleskom originalu best effort), što znači da nema gotovo nikave garancije da će poslani paket ili datagram zaista i doći do odredišta nakon što je poslan. Sam paket se u procesu prijenosa može promijeniti, može se promijeniti redoslijed paketa u odnosu na ona redoslijed kojim su poslani s izvorišta, može se duplicirati ili potpuno izgubiti tijekom prijenosa. Ukoliko aplikacija zahtijeva pouzdanost, koriste se drugi mehanizmi ili protokoli, najčešće na sloju iznad samog IP protokola.

Uređaji koji usmjeravaju pakete na njihovom putu kroz računalnu mrežu nazivaju se usmjerivači (eng. router). S obzirom da je sam koncept IP protokola oslobođen mehanizama koji osiguravaju pouzdanost, i sam proces usmjeravanja paketa je relativno brz i jednostavan. To znači da usmjerivači povremeno mogu presložiti redoslijed, promijeniti ili čak izgubiti pakete, što se dobro slaže s modelom najbolje moguće, ali da u konačnici to ne utječe previše na samu uslugu.

IP protokol je standard na najvećoj računaloj mreži danas - Internetu. Najraširanija verzija protokola koja je de facto standard Interneta je IP verzija 4 (IPv4), dok je najizglednija slijedeća verzija IP verzija 6 (IPv6). Pojedine verzije se razlikuju u načinu adresiranja, ali i brojnim drugim detaljima. Tako npr. IPv4 koristi 32-bitnu IP adresu, dok recimo IPv6 koristi 128-bitnu adresu. Ostale verzije također postoje, ali nisu u široj uporabi: verzije od 0 do 3 su uglavnom bile rezervirane za posebne namjene ili nekorištene, verzija 5 je eksperimentalna verzija tzv. stream protokola, itd.

10. DNS

DNS (Domain Name System) je hijerarhijski distribuirani sustav u kojem se nalaze

informacije o IP adresama i imenima računala, a mogu nalaziti i različite druge informacije.

Ime računala (engl. hostname) je jedinstveno simboličko ime unutar pojedine mreže kojim se

koriste neki protokoli (npr. SMTP, NNTP) da bi identificirali računalo. Imena računala mogu

biti samo jedna riječ, ako se radi o lokalnoj mreži ili nekoliko riječi odvojenih točkama. ako

se radi o domenskom imenu (engl. domain name) o kojem će biti riječi u poglavlju 5.2.1.

Klijentima DNS informacije pružaju DNS poslužitelji, koristeći DNS protokol za

komunikaciju kako sa klijentima tako i međusobno.

Svrha DNS sustava je pojednostavljivanje komunikacije među računalima u smislu olakšanog

pamćenja imena kao i mogućnosti tematskih i drugih grupiranja računala koja nisu blizu u

smislu slijednih IP adresa. Jasno je, u svakodnevnom radu je daleko lakše koristiti i pamtiti

imena umjesto odgovarajućih IP adresa.

DNS sustav je, naravno, mnogo širi, te obuhvaća tri osnovne funkcije s različitim segmentima

koje ćemo definirati u nastavku:

1. DNS imenski prostor, problematiku imenovanja i pravila: karakteristike su

hijerarhijska struktura, imenička struktura i pravila imenovanja te specifikacije

domena

2. Registraciju domena i druge administrativne probleme: hijerarhijsku strukturu

nadležnih tijela, hijerarhiju vršnih nadležnih tijela (TLD), procedure registracije

sekundarnih domena, administraciju DNS zona i administraciju hijerarhije

3. Poslužitelje i proces razrješavanja: DNS zapisi i zone, tipovi DNS poslužitelja sa

različitim ulogama, procesi razrješavanja, DNS poruke, formati i zapisi.

Domensko ime

Domensko ime je simboličko ime računala na internetu koje ga najčešće jednoznačno

identificira (postoji mogućnost da više računala dijeli jedno domensko ime). DNS sustav vrši

preslikavanje domenskog imena u jednu ili više IP adresa i obratno, preslikavanje jedne ili

više IP adresa u jedno domensko ime. Većina operacijskih sustava DNS koristi implicitno pa

je moguće nekom računalu na internetu pristupiti kako kroz odgovarajuću IP adresu, tako i

kroz domensko ime, ako je definirano.

Labela (engl. label) je, po definiciji, alfanumerički niz znakova, uz napomenu da je dopušten

i znak "–" (ASCII znakovi od A do Z i znak "–"), pri čemu se labele ne razlikuju po velikim i

malim slovima. Labela može biti duga maksimalno 63 znaka. Više takvih labela se

međusobno odvaja točkama, a one zajedno tvore domensko ime, koje se u takvoj potpunoj

formi kada su navedene sve labele zove i FQDN (Fully Qualified Domain Name). Takvo ime

je maksimalne duljine 255 znakova, a različito od običnog domenskog imena (koje može biti i

kratkog oblika, sadržavajući samo dio labela) po tome što predstavlja apsolutnu stazu unutar

DNS hijerarhije. Da bi se FQDN dodatno razlikovao od labela odnosno standardnih, ne nužno

potpunih, domenskih imena česta je konvencija dodavanja dodatne točke (znaka ".") na kraj

domenskog imena.

Zaključimo: Domensko ime se sastoji od dvije ili više labela odvojenih točkama. Krajnje

desna labela je TLD, a svaka druga labela lijevo je poddomena. Poddomena je domena koja

je hijerarhijski ispod prethodne. Ukupno može biti maksimalno 127 podjela, dok se držimo

zadane granice od 255 znakova za FQDN. Na kraju, labela koja je krajnje lijeva je kratko ime

računala.

Domene

Imena domena su obično grupirana tj. završavaju određenom skupinom labela za koje postoje

točno definirana pravila. Takve završne labele se nazivaju TLD (Top-Level Domain) imena.

Postoje dva tipa TLD imena:

Geografski bazirane domene, tzv. ccTLD (engl. country code TLD) domene koje

predstavljaju državni dvoznakovni kod temeljen na ISO-3166 standardu, a danas ih je

u uporabi preko 243. Primjeri takvih domena su: .hr, .us, .de, .jp, .co.uk, ...

Generičke domene, tzv. gTLD (engl. generic TLD) domene koje se obično sastoje od

tri ili više znakova. Primjeri takvih domena su: .com, .net, .org, .info, .biz, .edu,

.travel, ...

U pojedinoj domeni, odnosno domenskom prostoru ne mogu postojati dvije iste labele - što

znači niti dvije poddomene niti dva računala s istim imenom.

Za dodjelu domena i upravljanje domenama zadužena je neprofitna organizacija ICANN

(Internet Corporation for Assigned Names and Numbers). Ova relativno mlada organizacija je

preuzela poslove koje je nekad obavljala IANA (Internet Assigned Numbers Authority). Riječ

je o upravljanju domenama i IP adresama, pri čemu se lokalna registracija IP adresa predaje

pojedinačnim RIR-ovima (Regional Internet Registries). Svaki RIR alocira adrese za različiti

dio svijeta, a europski RIR je RIPE (Réseaux IP Européens).

Domenski registri

Slično kao i za IP adrese, postoje domenski registri. To su baze podataka o domenama i

odgovarajućim IP adresama, po jedan za svaku TLD. Oni kao uslugu daju domenska imena za

vlastitu TLD te omogućavaju ostatku svijeta pregled informacija o registracijama pojedinih

domena. Domenski registri se inače nazivaju NIC (Network Information Center) te su

najčešće neprofitne ili državne organizacije. Informacije o registracijama su dostupne kroz

Whois sustav. Za Europu je nadležan whois.ripe.net poslužitelj. Same registracije se

najčešće događaju po principu tko prvi registrira dobije domenu, iako se mogu formirati i

složene politike zbog zaštićenih imena, itd. Svaki registar upravlja DNS poslužiteljima za

specifični TLD a to je za hrvatsku vršnu .hr domenu dns.srce.hr kojim upravlja HR-DNS

služba za CARNet. Dakle, za ccTLD-ove su obično nadležne vlade pojedinih država, dok je

za gTLD nadležan isključivo ICANN. ICANN regulira upravljanjem 13 vršnih DNS

poslužitelja (engl. root servers).

Primjer DNS hijerarhije prikazan je na slici 5.1.

DNS razrješenje

Funkcionalni DNS sustav nužno se sastoji od tri dijela:

DNS klijent (engl. resolver) - Program koji se izvršava na klijentskom računalu i koji

formira određeni DNS zahtjev

Rekurzivni (engl. recursive) DNS poslužitelj - Poslužitelj koji nakon dobivenih

upita za klijenta obavlja pretraživanje kroz DNS stablo i vraća odgovore natrag

klijentima

Autoritativni (engl. authoritative) DNS poslužitelj - Poslužitelj koji odgovara na

upite rekurzivnih poslužitelja te vraća ili završni odgovor ili zbog delegiranja vraća

referencu na neki drugi autoritativni DNS poslužitelj

Sam proces primanja zahtjeva i njihove obrade i vraćanja odgovora naziva se DNS

razrješenje (engl. name resolution). Osnovno razrješenje jest proces pretvorbe domenskog

imena u IP adresu: Prvo tražimo autoritativni DNS poslužitelj, a zatim mu šaljemo upit za

adresom, na koji on odgovara traženom adresom. Budući da je DNS strogo distribuirana baza,

ona je raspodijeljena na mnogo različitih poslužitelja. Razvidno je da zbog raspodijeljenosti

razrješenje najčešće ne može biti obavljeno kroz samo jedan upit i odgovor, već zahtijeva

dulju komunikaciju tj. niz upita i odgovora. Najčešća je situacija kada klijent šalje zahtjeve

lokalnom DNS poslužitelju (nadležan za klijentsko računalo, obično dodijeljen od ISP-a ili

ustanove u kojoj se nalazi klijentsko računalo), koji predstavlja rekurzivni poslužitelj. Taj

poslužitelj obavlja upite za klijenta, a zatim mu vraća odgovor. Dakle, najveći i

najkompliciraniji dio procesa predstavlja traženje autoritativnog poslužitelja u složenoj DNS

hijerarhiji.

Što se tiče samih tipova DNS razrješenja, postoje dva osnovna tipa prolaska kroz DNS

hijerarhiju da bi se otkrio točan zapis. Oni se razlikuju po tome tko obavlja većinu posla oko

saznavanja podataka i njihove obrade, a prvenstveno se pojavljuju kad lokalni DNS

poslužitelj nema sve informacije:

Iterativni - Klijent šalje upite, a poslužitelj mora odgovoriti jednim od dva moguća

odgovora:

o Odgovorom na zahtjev

o Imenom drugog DNS poslužitelja (vrši se delegiranje) – Ovaj poslužitelj ima

više podataka o traženom upitu.

U ovakvom tipu upita najveći dio posla obavlja klijent iterirajući akcije upit-odgovor i

prolazeći kroz DNS hijerarhiju.

Rekurzivni - Klijent šalje rekurzivni upit, poslužitelj preuzima posao pronalaženja

informacija o traženom upitu. Dakle, ono što je u iterativnom obavljao klijent, kod

rekurzivnih upita obavlja poslužitelj - obrađuje informacije i šalje nove upite drugim

poslužiteljima sve dok ne sazna informaciju koju traži. Dakle, klijent šalje svega jedan

zahtjev te dobiva ili točnu informaciju koju je tražio ili poruku o grešci. Proces je

prikazan na slici 5-2.

Zaključujemo da je rekurzivni način pretraživanja vrlo povoljan za klijente, ali može znatno

opteretiti DNS poslužitelje pa se takve forme upita obično eksplicitno dopuštaju samo

računalima iz lokalne mreže, dakle računalima kojima je dotični DNS poslužitelj

autoritativan.

Praktički svaka pretraga za nekom DNS informacijom počinje od čvornog DNS poslužitelja,

tj. od vrha DNS stabla. Prolazak kroz DNS stablo je silazak po granama stabla, gdje je svaki

čvor jedan DNS poslužitelj, nadležan za svoj dio DNS prostora. Osnovni preduvjet

pronalaženja čvora stabla je lokalna lista 13 vršnih DNS poslužitelja, koji dalje delegiraju

pretragu po zapisima. Dakle, DNS stablo je hijerarhijski složen skup DNS poslužitelja, gdje

svaka domena i poddomena ima jednog ili više autoritativnih DNS poslužitelja. Dotični

poslužitelji (čvorovi stabla) su nadležni za domene ispod njih, ili mogu delegirati dalje,

servirajući podatke drugima na upit.

U praksi se osim domena i labela pojavljuje i pojam zona. Zona predstavlja dio ukupnog

domenskog prostora, te se prostire od jedne točke, odnosno autoritativnog DNS poslužitelja

za tu zonu, dalje do krajnjih čvorova ili do početaka neke druge zone. Zona je, dakle, dio

domene, ali se može prostirati i na cijelu domenu.

DNS međuspremnik

Osnovni načini pretraživanja (iterativni i rekurzivni silazak kroz DNS stablo) vrlo su

neučinkoviti jer svaki upit implicitno znači novi prolazak kroz stablo, počevši od vršnih DNS

poslužitelja. Jasno, kada bi se u stvarnom svijetu nužno svaki put prolazilo od početka DNS

stabla do traženog zapisa, proces DNS razrješavanja bi predugo trajao, a opterećenje DNS

poslužitelja bi postalo preveliko. No, eskalaciju ovog problema prilično je smanjio

jednostavan princip spremanja kako pozitivnih (uspješnih) tako i negativnih (neuspješnih)

rezultata DNS upita na DNS poslužiteljima.

Formiranje međuspremnika (engl. cache) DNS rezultata korisno je zbog dviju jednostavnih

činjenica:

Veće su šanse da će se pristupati nekom resursu ako se nedavno pristupalo nekom

drugom prostorno bliskom resursu - to je tzv. prostorna lokalnost reference

Ako se nekom resursu nedavno pristupalo veće su šanse da će mu se ponovno

pristupati - to je tzv. vremenska lokalnost reference.

U praksi je pokazano da se često šalju isti ili slični DNS upiti u vremenski bliskim periodima.

Stoga svi DNS poslužitelji imaju interne međuspremnike o nedavnim DNS upitima koji im

omogućavaju pribavljanje odgovora ili dijela odgovora iz međuspremnika. DNS

međuspremnici se nalaze i na većini DNS klijenata, a obavljaju isti posao kao i na DNS

poslužiteljima. Na taj način se spremaju rezultati već obavljenih upita i na klijentskim

računalima, što smanjuje promet prema poslužiteljima i njihovo opterećenje. Tako spremljeni

odgovori će biti dulje spremljeni kod klijenata, budući da je svaki međuspremnik ograničene

veličine i novi upiti brišu stare ili nekorištene odgovore.

Međuspremnici više poboljšavaju performanse što su bliže klijentu, ali daju bolju pokrivenost

što su dalje od klijenta. Podaci spremljeni u međuspremnicima imaju svoja vremena života,

TTL pa se time osigurava da zastarjeli podaci nužno nestaju iz spremnika. DNS poslužitelji će

pri prihvatu DNS upita obaviti pretraživanje vlastitog međuspremnika kao i lokalne DNS

baze, pokušavajući što više skratiti vremenski "skup" prolazak kroz DNS stablo. Negativni

efekt postojanja TTL vremena za DNS zapise je što utječe i na vrijeme propagacije podataka

(engl. propagation time) po DNS stablu, budući da se promjene između ne vide sve do

eksplicitnog nestajanja zapisa zbog TTL-a.

Reverzno razrješenje

Do sada je razmatrano standardno razrješenje unaprijed (engl. forward) kod kojeg se DNS

imena pretvaraju u IP adrese. U standardnoj komunikaciji na internetu nužno je moći vršiti

razrješenje u oba smjera, a to znači i unatrag (engl. reverse). Problem reverznog DNS

razrješenja je što se poslužitelji razlikuju prvenstveno po domenama za koje su nadležni, a

ovdje imamo samo IP adresu kao početnu informaciju. Kako bi se omogućio ovaj proces,

formirana je dodatna hijerarhija uvođenjem in-addr.arpa domene. Ova domena se sastoji od

četiri razine poddomena, a svaka razina odgovara jednom dijelu IP adrese. Reverznim DNS

razrješenjem, odnosno prolaskom kroz te četiri razine, dolazi se do čvora za traženu IP adresu

koji pokazuje na odgovarajuće domensko ime. Svaka razina unutar in-addr.arpa domene

sastoji se od 256 poddomena (od 0 do 255). Reverzna DNS adresa se formira od čvorova

unutar reverzne domene, a identična je obratno zapisanoj IP adresi s in-addr.arpa sufiksom pa

upiti nad takvom adresom kao povratnu informaciju daju "standardnu" adresu.

Reverzno razrješavanje za 161.53.166.3 prikazano je na slici 5-3.

DNS protokol

DNS poslužitelj koristi standardne priključne točke TCP/53 i UDP /53. Na njima sluša

zahtjeve, a odgovore šalje koristeći njih ili neku drugu priključnu točku veću od 1024.

Odgovor je traženi zapis, odnosno RR (engl. resource record).

Standardno se koristi UDP. Komunikacija se svodi na jedan UDP upit i jedan UDP odgovor.

TCP se koristi jedino kad veličina odgovora prelazi 512 okteta ili za prijenos zone (engl. zone

transfer). Standardni DNS upit je obično vrlo jednostavan, sadrži uglavnom samo adresu koja

se želi razriješiti, ali odgovori su vrlo komplicirani budući da sadrže sve adrese i zamjenske

adrese koje su rezultat upita. Zbog toga se odgovori obično sažimaju posebnim algoritmima,

eliminirajući nepotrebne podatke i smanjujući samu veličinu UDP datagrama. Ako veličina

paketa i dalje prelazi 512 okteta, šalje se parcijalna poruka u obliku UDP paketa s posebnim

bitom postavljenim u 1 koji označuje da se upit mora ponoviti koristeći TCP.

Primarni i sekundarni DNS, prijenos zone

Autoritativni DNS poslužitelj za određenu zonu je svaki poslužitelj koji ima kompletnu

kopiju zone bez potrebe za procesom razrješavanja. Dakle, riječ je o poslužitelju koji daje

vlastite podatke klijentima. Osnovni podatak koji informira poslužitelj da je autoritativan za

zonu je SOA zapis. Neispravno definiran SOA zapis može dovesti do situacije da niti jedan

DNS poslužitelj nije autoritativan, a time i do prestanka normalnog rada DNS razrješavanja za

tu zonu.

Dobro je definirati više DNS poslužitelja za istu zonu koristeći više odgovarajućih NS zapisa.

Svaka zona trebala bi imati barem dva DNS poslužitelja. Nakon isteka TTL vremena

pojedinog RR-a (definirano u svakom RR-u), podaci spremljeni po raznim klijentima i

poslužiteljima nestaju. U slučaju da je postojao samo jedan autoritativni DNS, a da je on

neaktivan ili neispravan, zona je nedostupna. Stoga je razvijen princip primarnog (engl.

primary, master) i sekundarnog (engl. secondary, slave) DNS poslužitelja. Primarni

poslužitelj je onaj autoritativni DNS poslužitelj koji podatke o svojoj zoni ima lokalno

spremljene. Sekundarni poslužitelj je onaj koji podatke dobiva od nekog vanjskog izvora,

obično koristeći prijenos zone (engl. zone transfer) primarnog poslužitelja. Primarni

poslužitelj za jednu zonu može biti sekundarni za drugu i sl. Sa strane klijenta, oba su

poslužitelja jednake vrijednosti i jednakog prioriteta (slučajni izbor). Dobro je da sekundarni

poslužitelj bude fizički udaljen od primarnog.

Dinamički DNS

Današnji DNS i DHCP poslužitelji omogućavaju međusobno povezivanje sustava

dodjeljivanja IP adresa i DNS sustava. Takav sustav naziva se dinamički DNS (engl.

dynamic DNS), a radi na način da se svako računalo koje dobiva IP adresu od DHCP

poslužitelja registrira u DNS sustavu kroz automatizirani proces. DHCP klijent šalje DNS

UPDATE poruku koja indicira DNS poslužitelju što treba obaviti s odgovarajućim RR-ovima.

Naravno, dinamički DNS kao takav nije ograničen nužno na DHCP, već u praksi svaki

autorizirani DDNS klijent može upravljati odgovarajućim zapisima u zoni.