Redaktsioon: 13. mai 2009, kell 10:05

Traditsiooniline sissejuhatus

Kindlasti kohe ei ole selle teksti lugejate hulgas inimesi, kes ei tea mis on DNS ja mil moel teda tarbitakse. Aeg ajalt on siiski kasulik ka teadmiste elementaarosakesed üle korrata, ent ajanappuses teadjamad kodanikud võiksid siis närvirakkude säästmiseks järgnevad pisikesed sissejuhatavad ajaloo ja baasteadmiste lõigud vahele jätta ja koheselt BINDi hingeelu lahkavate osade kallale asuda.

Minnes tagasi iidsete aegade juurde, siis kui veel IT dinosaurused ringi müttasid – umbes 1970ndad – oli kogu arvutimaailm võrreldes tänase päevaga vägagi teistmoodi. Korralik server täitis vähemalt ühe korruse, kui mitte suisa terve maja, ja kaalu oli mitme tanki jagu.

Algselt, kui omavahel ühendatud arvutivõrke oli piisavalt vähe, sai serveri poole pöördumisel ka IP aadressi kasutamisega askeetlikult hakkma. Inimaju imeliku ehituse tõttu ei püsinud Võrgu kasvades sõbralikud IP aadressid enam kasutajatel meeles ja hakati harrastama nimede andmist IP aadressidele, nii sündisid domeeninimed. Paare nimi=<IP aadress> hoiti igas tähtsamas purgis tekstifailis millel nimeks hosts.txt ja mida iga serveri haldaja oma nägemust mööda täiendas. Mingi hetk sai aga kasutajatel selgelt villanud sellest pudrust-kapsast mida selline haldus (või siis haldamatus) endaga kaasa tõi ja '73ndal tehti ettepanek tsentraalse süsteemi loomiseks, mis kiirelt ka implementeeriti ja oli elujõuline kuni '80ndate alguseni.

Võrkuühendatud arvutite hulga kasvades paisus aga ka hosts fail. Hosts faili sobimatus antud situatsioonis kasutamiseks ning e-kirjade marsruutimise keerukus olid peamised initsiaatorid, mis tõid kaasa praeguse nimesüsteemi üheks alustalaks oleva RFC nr. 830 sünni. Järgnev on, nagu armastatakse öelda, juba ajalugu.

Päris julgelt võib väita, et tänasel päeval on DNS Interneti toimimise vaatenurgast üks kriitilisemaid teenuseid. Justnimelt seda silmas pidades otsustati, et tarkvara, mida hakatakse kasutama selle teenuse osutamiseks, peab olema:

võimalikult veavaba
vajadusel kiirelt paigatav, ning
täielikult usaldatud Interneti kogukonna poolt.

Teiste sõnadega – nimeserver peab olema avatud lähtekoodiga. Nii sündis BIND - enimkasutatud nimeserveri tarkvara.

Kuigi võib tunduda, et mis selles nimede serveerimises siis keerulist saab olla, on DNS pidevas muutumises standardite kogum ja BIND pidevas arengus tarkvara. Kurikaeltel on imeline võime üles leida nõrkused suvalises süsteemis ning see on aidanud läbi valu ja pisarate muuta nii DNS protokolli ennast kui ka seda protokolli implementeerivat tarkvara paremaks ja turvalisemaks.

Lähtudes tänapäevases Internetis tekkinud Metsiku Lääne keskkonnast on ka selles dokustaadis lisaks tavapärastele põhielementidele nagu tsoonid, delegeerimine jms kaetud ka nn advanced topicud DNSSEC, SPF, IPv6 ning haldamise-turvalisuse aspektist olulised split-DNS (vaated), TTL. Lisaks on lahti seletatud kuidas toimivad mõned enimlevinud DNSi protokolli- või implementeeriva tarkvara nõrkusi kasutavad ründed, et süsteemihaldurid teaks ette valmistada ennast ja hallatavaid süsteeeme võimalike ebameeldivuste varalt.

Nimepuu

DNSi ülesehitus on puu laadne. Kõige aluseks on juured elik "." ("punkt") serverid, kes teavad järgmise taseme domeenide servereid. Järgnevad ülema astme domeenid (TLD) nagu näiteks .org, .net, .com ning riikide TLDd nagu näiteks .ee, .fi, .ru. Nood omakorda teavad kõike enda taseme haru (pädevusala) kohta ja, mitte eriti üllatuslikult, teavad järgmise taseme serverid kõike oma pädevusala kohta ...

Nõudeks on, et haru samal tasmel nimed ei kordu. Pisike ASCII kunst seda juttu ilmestama:

. / \ ee com / \ neti google / \ / \ x www mail www / \ y z

Domeeni nimi kujuneb liikudes alguspunktist edasi ja kirjutatakse lahti meile harjumatus suunas paremalt vasakule, ignoreerides kirjapildis tavaliselt punkti (aga näiteks brauserid tunnistavad punkti nime lõpus, proovi kui ei usu!), seega läbides tee:

. -> ee -> neti kirjutub täisnimi kujule neti.ee ja läbides tee:
. -> com -> google saame google.com

Harul sama taseme mittekorduvuse nõude ilmestuseks - legaalsed on teed (samad tasemed aga erinevad harud):

. -> ee -> google (google.ee) või
. -> com -> neti (neti.com)

ja ilmselgelt ei saa puus esineda selle reegli järgi kaks korda

. -> com -> google (google.com)
. -> com -> google (google.com)

Domeeninimede osas on hetkel kehtimas veel üks nõue: kasutada tohib sümboleid a-z, numbreid 0-9 ning miinus märki ning nime ei tohi alustada miinusega. Miks hetkel? Me kõik oleme tähele pannud, et tavapäraselt ei kasutata näiteks Eesti veebiserveri aadressides täpitähti - Järvamaa veebilehest saab Internetis jarvamaa.ee. Kui eesti tähestikus on kõigest mõned ameerika omast erinevad tähed siis tasub mõelda vene, hiina, jaapani keele peale.

Internet on muutunud rahvusvaheliseks ja erinevad rahvad nõuavad võimalust kasutada Interneti nimedes oma tähestikku. Selle tarvis on laiendus DNSi standardile, kutsutakse seda IDN'ks (International Domain Names) ja on selge, et see tühistab senised nimede sümbolireeglid ent muudab seni suhteliselt lihtsa süsteemi oluliselt keerukamaks ja haavatavamaks. Sügavuti seda teemat siin ei käsitle, huvilised võiksid pilgu peale heita ühele IDNi alusdokumendile - RFC 3490.

Domeeninime mõiste sellega paraku ei ammendu, nutikad inimesed on domeeninimedele teinud kasulikke täiendavaid jaotusi.

Domeen, domeeninimi, tsoon

Lihtsaim on neil vahet teha lihtsa reegli järgi - kui nimi enam ei "hargne", siis on tegemist domeeninimega. Tuginedes eeltoodud näitele:

. / ee / neti / \ www ns \ h01

on www.neti.ee domeeninimi aga ns.neti.ee domeen, sest ta "hargneb" edasi. Toome juurde veel alamdomeeni mõiste: antud näites on domeen neti.ee TLD ee alamdomeen ja domeen ns omakorda neti.ee alamdomeen.

Kui domeenininimedega selgus majas, on õige aeg tutvust teha tsooniga. Enne kui tekib kellelgi assotsatsioone: ei - tsoon ei ole koht kuhu paha domeenid saadetakse karistust kandma. Tsoon on definitsiooni järgi Interneti nimepuu delegeerimise punkt. Lahtiseletatult - tsoon saab katta katkematu tüki domeenipuul s.t. teada kõiki nimesid oma tasemel. Seega teel domeenipuuud mööda . -> ee tähendab see seda, et kusagil on tsoon mis omab teavet oma tasemel kogu ee domeeni kohta. Tsoonis on kõik domeeninimed ja delegeerimised teistele domeenidele.

Jätkates eeltoodud neti.ee näitel:

ee tsoonis on kirjeldatud kõik domeeninimed ja delegeerimised, muuhulgas netii
neti.ee domeeni tsoonis on kindlasti kirjeldatud domeeninimi www.neti.ee aga ei sisalda midagi domeeninime h01.ns.neti.ee kohta sest ...
... ns.neti.ee on antud juhul delegeeritud tsoon ja domeeni ns.neti.ee domeeninimesid teab server millele selle tsooni serveerimine on delegeeritud.

Kuigi esmapilgul võib pilt pisut segane olla, loksub kõik tavaliselt siis paika kui vaadata kuidas me saaksime kehtestada reegleid, mille alusel luua tarkvara. "Tsooniteooriast" lähtuda - tsoon sisaldab terviklikku pilti oma taseme domeeninimedest ja domeenide delegatsioonidest - tundub olevat mõistlik tarkvara loomisel. Miks? Kui me lähtuksime tarkvara luues domeenist, siis tekiks palju segadust mis on seotud alamdomeenide ja domeenide delegatsioonidega, eeskätt muutuks väga keeruliseks sellekohase info nimeserverite vahel sünkrooniseermise probleemi lahendamine. Ilmselt ei ole eriti üllatav see, et populaarne nimeserveri tarkvara BIND tegeleb tegelikult tsoonide, mitte domeenidega.

Pädevad nimeserverid ja puhverdavad nimeserverid

Igal tsoonil on on vähemalt üks pädev nimeserver. Pädev on nimeserver siis, kui ta oskab öelda tsooni kohta kõiki:

domeeninimesid
(alam)domeenide delegeerimisi

Pädevaid nimeservereid saab olla kolme liiki:

primaarsed pädevad nimeserverid
sekundaarsed nimeserverid
varjatud nimeserverid

Primaarne pädev nimeserver

Kõige lihtsam on mõista primaarset pädevat nimeserverit kui serverit, milles on tsoonifaili "originaal". Tsoon on tavaliselt faili kujul ja seda võidakse redigeerida käsitsi või siis abivahendite abil, dünaamilise tsooni puhul ei osale inimene tsooni kujunemise protsessis. Kordame üle, et tsoonis on kirjeldatud kõik domeeni domeeninimed ja delegeerimised.

Sekundaarne nimeserver

Sekundaarne nimeserver hoiab primaarse nimeserveri tsooni koopiat ja millele on viidatud tsooni NS kirjes. Ta teeb seda täpselt nii kaua, kui suur on tsooni kohta kirjeldatud TTL (Time To Live) parameeter, olgu meie näidisdomeeni puhul TTLiks 432000. Siit 432000 -> 432000 / 60(sek) / 60(min) / 24(tundi) = 5(päeva) mis reaalses elus tähendab seda, et kui primaarne nimeserver kaob eetrist siis on administraatoril aega taastada primaarne server täpselt 5 päeva, enne kui sekundaarses nimeserveris tsoon aegub ja ta enam ei vasta päringutele selle tsooni kohta.

Varjatud nimeserver

Varjatud nimeserver on selline nimeserver, mis hoiab primaarse nimeserveri tsooni koopiat, aga millele ei ole viidatud tsooni NS kirjes. Ka varjatud nimeserver hoiab sarnaselt sekundaarse nimeserveriga koopiat TTLi parameetri poolt fikseeritud arv sekundeid.

DNS: domeeninimest IPks ja IPst domeeninimeks tagasi

Seni oleme vaatanud seda, kuidas toimub nime lahendamine IP aadressiks. Ometigi on olemas ka vastupidine protsess kus IP lahendadakse nimeks, nimetatakse seda pöördteisenduseks. Kuigi mõlemad hõlmavad endas nimeserveri teenust ja sisuliselt on tegemist lihtsalt erinevusega tsooni kirjeldamise süntaksis, on erinevus domeeninime teadvas TLDs. Erinevus süntaksis seisneb sellest, et kasutatakse spetsiaalset in-addr.arpa. domeeni IP aadresside nime kirjeldamisel. 195.50.209.245 on seega kujul 245.209.50.195.in-addr.arpa. Teeme selle kohta ka pisikese pildi, kuidas mahutada kolm IP aadressi (195.50.209.245, 212.107.52.17, 62.65.192.24) meile tuttavasse domeenipuusse:

in-addr.arpa / | \ 195 212 62 / | \ 50 107 65 / | \ 209 52 192 / | \ 245 17 24

Puust täisnime tuletamise reeglit järgides saame:

245.209.50.195.in-addr.arpa.
17.52.107.212.in-addr.arpa.
24.192.65.62.in-addr.arpa.

Domeeninimi->IP teisenduste puhul tegelevad TLD tsooni haldamisega organisatsioonid/ettevõtted kes osutavad nimeserveri teenust. Domeeninime lahendamine IPks toimub seega näiteks www.google.com puhul selliselt:

leia juurnimeserver

päri juurelt .com TLD nimeserverit

päri .com TLDlt google domeeni nimeserverit

IP->domeenimini teisendusel jõutakse TLDni IP omaniku andmete järgi ja IP teisenduse domeeninimeks teeb interneti teeenusepakkuja (ISP) nimeserver. IP 195.50.209.245 puhul näiteks toimub see selliselt:

leia juurnimeserver

päri juurelt 195.in-addr.arpa TLDd, selleks on regionaalse RIRi (regionaalne interneti registraator) nimeserver

päri RIRilt võrgubloki omaniku nimeserverit, selleks on ISP nimeserver

Siin on kaks olulist infokillukest, mida süsteemiadministraator peaks meeles pidama:

domeeninimega või domeeniga seotud soovid ja mured tuleb esitada TLD haldajale
pöördteisendusega seotud soovide ja muredega tuleb pöörduda ISPi poole

Puhverdav nimeserver

Puhverdav nimeserver, ka rekursiivse nimeserver, ei ole pädev ühegi domeeni suhtes. Kindlasti on puhverdavas serveris kirjeldatud tsoon "." (punkt) s.t. nimeserverid kes teavad vastuseid punktist järgmise taseme (.com, .net, .ee jne) nimeserverite kohta. Puhverdav nimeserver "teab" paljude domeenide domeeninimesid - neid, mida kliendid on temalt küsinud ja millele ta on leidnud vastuse - aga ei oma terviklikku pilti neist domeenidest.

Puhvris hoitakse domeeninimesid TTLiga määratud aeg. Aeg-ajalt võib osutuda vajalikuks puhvri tühjendamine enne TTLi aegumise kättejõudmist - põhjusel või teisel võib juhtude nii, et pädevas nimeserveris on muutunud andmed aga puhverdavad nimeserverid kasutavad vanu andmeid. Tänasel päeval on süsteemiadministraatoril vajalik ka täiendavalt kaitsta puhverdavat nimeserverit. Miks ja kuidas, sellest tuleb juttu allpool.

BINDi seadistamine

Kõige paremini saab kõik selgeks tavaliselt läbi praktilise tegevuse. Seepärast selgitame siis BINDi kasutamist reaalelulise näite varal, seadistades BINDi serveerima domeeni domeen.ee kõikvõimalikel viisidel ja kõikvõimalikes seadistustes. Enne selle töö juurde asumist on meil vaja selgeks teha mõned terminid ilma milleta kohe kindlasti läbi ei saa.

DNSi terminite kiirkursus

Järgnevad terminid ja mõisted on kasutuses nimeserveri tsoonifailides, peamine allikas eestikeelsete terminite osas on Imre Oolbergi sellekohane töö.

Canonical name: Kanooniline nimi. Hosti tegelik nimi. Seda kasutatakse CNAME kirjetes, PTR- kirjetes, NS kirjetes ja MX kirjetes. Kanooniline nimi on mõnes mõttes pettekujutelm, sest paljudel serveritel on rohkem kui üks võrdväärset nime. Praktiliselt on kanooniline nimi iga domeeninimi millel on A-kirje.
RR: Resource Record. Ressursikirje on domeeninimega kaasaskäiv infokogum mis kirjeldatakse tsoonifailis. Alljärgnevad terminid on ressursikirjed.
SOA: Start of Authority Record. SOA kirje on esimene kirje tsoonifailis. SOA kirje esimene väli määrab tsooni pädeva nimeserveri.
NS: Name Server Record. NS-kirje määrab, milline nimeserver teenindab antud tsooni, NS kirjeid võib olla mitu. Iga NS kirje on kas delegeerimiskirje või pädevuskirje (authority record). Kui NS kirje asub samanimelises tsoonis, siis ta on pädevuskirje. Kui NS kirje nimi on alamdomeeni nimi, siis ta on delegeerimiskirje.
A: Address Record ehk aadresskirje seob domeeninime IPv4 ehk neljabaidise IP-aadressiga. Kui DNS välja töötati, siis soovitati, et kaks A-kirjet ei viitaks ühele ja samale IP-aadressile. Tänapäeval ei peeta nimetatud piirangut oluliseks - mitu erinevat domeeninime võivad viidata samale IP-aadressile (laialt kasutatav virtuaalsete teenuste puhul) ja üks domeeninimi võib viidata mitmele erinevale IP-aadressile (koormuse jagamine).
AAAA: see aadresskirje seob domeeninime IPv6 ehk siis 128bitise IP-aadressiga.
CNAME: Canonical Name Record. CNAME-kirje tekitab aadresskirje nimele aliase (hüüdnime).
PTR: Pointer Record (pointer - osuti). Nimetatakse ka "Reverse Record". PTR-kirje viitab hosti kanoonilisele nimele. See nimi peab olema IP-aadressiks tagasi lahenduv, ehk siis peab toimima teisendusahel A -> PTR -> A.
MX: Mail Exchange Record. MX-kirjega määratakse e-posti serverid, mida kasutatakse e-mailide hoidmiseks seni kuni adressaadi server saab posti vastu võtta või lihtsamates lahendustes võtavadki domeeni e-posti vastu ja toimetavad otse aadresaadile. MX-kirjetel määratakse ära ka postiserverite prioriteet, kõige väiksema prioriteediväärtusega MX kirje määrab domeeni posti eest vastutava postiserveri.
TXT: DNS protokolli mittetähenduslik kirje. Võib sisaldada vabas vormingus max 255 baiti pikka teksti. Leidnud kasutust näiteks spämmivastases võitluses SPF info kandjana.

Tagasi "juurte" juurde

Esitame lihtsa küsimuse: kuidas me saame teada, mis nimeserverid teavad kõike Eesti TLD .ee kohta?

Vastuse leidmiseks kasutame nimepärimise vahendit dig, mis on tarkavrapaketi BIND osana kliendi tööriist:

zyx@tux$ dig ee NS ; <<>> DiG 9.5.1-P2 <<>> ee NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55277 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ee. IN NS ;; ANSWER SECTION: ee. 86400 IN NS sunic.sunet.se. ee. 86400 IN NS ns.kbfi.ee. ee. 86400 IN NS ns.eenet.ee. ee. 86400 IN NS ns.ut.ee. ee. 86400 IN NS ns2.elion.ee. ee. 86400 IN NS ns.uninet.ee. ee. 86400 IN NS ns.uu.net.

Et leida tuge hierarhilise ülesehituse teooriale, üritaks järgmisena vastata küsimusele: kuidas on võimalik selle vastuseni jõuda? (alljärgnevas on eemaldatud kõik ballastinfo mis eelnevas päringu vastuses oli alles)

zyx@tux$ dig ee NS +trace . 57764 IN NS g.root-servers.net. . 57764 IN NS l.root-servers.net. . 57764 IN NS i.root-servers.net. . 57764 IN NS b.root-servers.net. . 57764 IN NS f.root-servers.net. . 57764 IN NS a.root-servers.net. . 57764 IN NS c.root-servers.net. . 57764 IN NS k.root-servers.net. . 57764 IN NS d.root-servers.net. . 57764 IN NS m.root-servers.net. . 57764 IN NS e.root-servers.net. . 57764 IN NS h.root-servers.net. . 57764 IN NS j.root-servers.net. ;; Received 336 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms ee. 172800 IN NS NS.UNINET.ee. ee. 172800 IN NS SUNIC.SUNET.SE. ee. 172800 IN NS NS.KBFI.ee. ee. 172800 IN NS NS.EENET.ee. ee. 172800 IN NS NS.UT.ee. ee. 172800 IN NS NS.UU.NET. ;; Received 284 bytes from 2001:dc3::35#53(m.root-servers.net) in 43 ms ee. 86400 IN NS sunic.sunet.se. ee. 86400 IN NS ns2.elion.ee. ee. 86400 IN NS ns.eenet.ee. ee. 86400 IN NS ns.uninet.ee. ee. 86400 IN NS ns.ut.ee. ee. 86400 IN NS ns.uu.net. ee. 86400 IN NS ns.kbfi.ee. ;; Received 184 bytes from 193.40.133.222#53(NS.KBFI.ee) in 1 ms

Siit on näha päringu vastuse leidmise tee, mis näitlikult selgitab puukujulist ülesehitust. Tegevused, mida nimeserveri klient tegi, on siis alljärgnevad:

leiame juurnimeserverid, sellele teadis vastust arvutis paiknev lokaalne nimeserver (vt rida millel 127.0.0.1)
leiame ee TLD nimeserverid, sellele teadis vastust m.root-servers.net (tollelt serverilt saime vastuse IPv6 protokolli kasutades, serveri aadress 2001:dc3::35)
pärime punktis kaks leitud nimeserveri käest domeeni ee suhtes pädevaid nimeservereid, sellele annab meile vastuse NS.KBFI.ee (193.40.133.222)
vastuseks on seitse serveri domeeninime

Siitkaudu jõuame kahe mõisteni: pädev vastus ja mittepädev vastus. Elu teeb lihtsamaks see, et termineis endis on avatud kogu termini sisu.

Pädev vastus on seega nimepäringu vastus, mille saame domeeni suhtes pädevalt nimeserverilt. Pädevaks nimeserveriks saab olla domeeni primaarne või sekundaarne nimeserver - see server mis domeeni tsoonis kirjeldatud NS kirjega.

Mittepädevaid vastuseid annavad puhverdavad nimeserverid - nemad uurivad meie küsimuse vastuse pädevalt nimeserverilt, edastavad selle meile ja salvestavad selle ka vahemällu järgmiste päringute kiire vastamise jaoks.

Primaarse nimeserveri seadistamine

BINDi puhul toimub primaarses pädevas nimeserveris tsooni seadistamine tavaliselt sellisel moel:

1. primaarses seadistusfailis named.conf viidatakse tsoonifailile:

zone "domeen.ee" { type master; notify yes; also-notify { 192.168.2.22; }; file "/etc/bind/pri/domeen.ee"; };

domeen.ee on domeen, mille suhtes ollakse pädev
type master viitab sellele, et tegemist on primaarse nimeserveriga
notify viitab, et also-notify sektsioonis kirjeldatud IPdele (vihje: varjatud nimeserver) saata teateid tsooni muutumisest lisaks tsoonis kirjeldatud nimeserveritele. Vaikeseades on notify väärtus juba yes, siin olen ta eraldi välja toonud selguse mõttes

2. fail /etc/bind/pri/domeen.ee sisaldab tsooni andmeid:

$TTL 432000 @ IN SOA domeen.ee. hostmaster.domeen.ee. ( 2 ; Serial 432000 ; Refresh 86400 ; Retry 2419200 ; Expire 432000 ) ; Negative Cache TTL ; @ IN NS ns1.domeen.ee. @ IN NS ns2.domeen.ee. @ IN A 192.168.1.22 @ IN AAAA 2a01:158:3:1:21c:c0ff:fe8a:4e79 ns1 IN A 192.168.1.22 ns2 IN A 172.16.33.1 @ IN MX 10 mx mx IN A 172.16.34.10 www IN CNAME @ @ IN TXT "see on domeen"

TTL, Refresh, Retry, Expire, Negative Cache TTL on aeg mis on sekundites. TTL on tsooni "eluaeg" elik aeg, kui kaua kehtivad tsooni andmed. Seda on oluline teada, sest TTL määrab ära kui kaua "mäletavad" tsooni koopia hoidjad - puhverdavad serverid ja sekundaarsed/varjatud serverid - seda tsooni. Näiteks tsoonifailis oluliste domeeni andmete muutmise eel on kasulik "keerata" TTL võimalikult väikeseks, et muutus leviks kiirelt. Teisalt on jälle kasulik hoida seda numbrit võimalikult suurena, et võimalikud äpardused nimeserveritega ei mõjutaks olulisel määral domeeninimede lahendamist (s.t. puhverdavad nimeserverid hoiavad tsooni andmeid puhvris kaua).

Serial on unikaalne tsooni andmete versiooni number ja tuleb suurendada iga kord, kui muudetakse tsoonifaili. Kui serial jääb muutmata siis primaarse nimeserveri arvates ei ole tsoonifail muutunud ja sekundaarsetele nimeserveritele ei saadeta teadet tsooni muutumisest, kui see teade ka saadetakse mingil põhjusel, siis ei uuenda sekundaarsed nimeserverid tsooni andmeid sest Serial on sama. Mõnedes kohtades kasutatakse Seriali puhul kuju AAAAKKPPIII kus AAAA on aasta, KK kuu, PP päev ja II iteratsioon elik päevase muutumise loendur, näiteks: 2009050905

@ tähistab domeeni sellisel kujul nagu see named.confis zone direktiivi juures kirjas, antud juhul siis @ = domeen.ee

NS, CNAME kirje puhul tähistab . (punkt) domeeninime lõppu. Kui seda seal pole, siis võib palju segadust tekkida reeglist, et nime lõppu lisatakse automaatselt domeen mis named.confis kirjas zone direktiivi juures.

Samaväärsed on seega antud juhul kirjapildid:

@ IN NS ns1.domeen.ee.
@ IN NS ns1

Sekundaarse nimeserveri seadistamine

BINDi puhul toimub sekundaarses nimeserveris tsooni seadistamine tavaliselt primaarses seadistusfailis named.conf sellisel moel:

zone "domeen.ee" { type slave; allow-.. file "/etc/bind/sec/domeen.ee"; };

Puhverdava nimeserveri seadistamine

Eelnevast jutust jä meile meelde, et puhverdava nimeserveri ülesandeks on DNS päringute teenindamine, esitades päringu pädevale nimeserverile ja salvestades vastuse vahemälus. Miks on puhverdava serveri kasutamine kasulik?

võit võrguliikluse vähenemise arvelt
lihtsam klientidel tööjaamu seadistada
lihtsam hallata tulemüüre
võimalus ennetada halva liikluse tekkimist

/../ Värske versioon nimetet vihjefailist on alati saadaval siit ja sisaldab ta infot kuidas leida juurnimeservereid, kellelt nimeinfot edasi pärida.

Vaated aka split DNS

Miks on see kasulik?

täiendav ressursikulu haldamiseks ... miks siis ometigi?

ACL ehk pääsuloend

ACL kasutatav mitmeski kohas aga DNS vaadete puhul eluliselt oluline ...

TTLi olulisusest

DNSSEC

IPv6

Sender Policy Framework (SPF)

Sinkhole elik Kuidas Ennetada Halba Liiklust

DNS on heaks instrumendiks turvateadlikule süsteemiadministraatorile, sest õigesti kasutades DNSi omadusi, on võimalik ära hoida turvaintsidente. Turvaintsidenti tekkimiseks poel tänapäeval teatavasti palju vaja: pruugib vaid brauseriga sattuda "ettevalmistatud" veebilehele ja ongi nakkus pahavaraga majas. Viimane võib kaasa tuua arvutikasutaja pääsutunnuste varguse, konfidentsiaalse siseinfo varguse, osalemise DoS ründes jne. Eduka ennetamise eeldusteks on:

puhverdava nimeserveri kasutamine DNS nimede lahendamisel
me teama pahasid domeeninimesid.

Toimismehhanism on lihtne: enne kui kasutaja jõuab brauseriga pahavaraga nakatavale lehele, teeb lehitseja DNS päringu domeeninime lahendamiseks IP aadressiks - sest TCP ühenduse saab teatavasti teha kahe IP vahel. Justnimelt sellel hetkel astume me otsustavalt mängu ja ennetame suurema õnnetuse tekkimise - me seadistame puhverdava nimeserveri pädevateks meile teadaolevate pahade lehtede suhtes ja suuname liikluse noile domeenidele kas /dev/nulli või siis spetsiaalselt ettevalmistatud veebiserverisse.

DNSi nõrkused

"Punkti" küsimise rünne

Puhvrimürgitamise rünne

Tool: PackETH

Packet data (modified answer to query google.ee)

71 ED 84 00 00 01 00 03 00 04 00 05 06 67 6F 6F 67 6C 65 02 65 65 00 00 01 00 01 C0 0C 00 01 00 01 00 00 07 08 00 04 4A 7D 5B>42<C0 0C 00 01 00 01 00 00 07 08 00 04 40 E9 A1>42<C0 0C 00 01 00 01 00 00 07 08 00 04 4A 7D 4D>42<C0 0C 00 02 00 01 00 05 46 00 00 10 03 6E 73 32 06 67 6F 6F 67 6C 65 03 63 6F 6D 00 C0 0C 00 02 00 01 00 05 46 00 00 06 03 6E 73 31 C0 5B C0 0C 00 02 00 01 00 05 46 00 00 06 03 6E 73 33 C0 5B C0 0C 00 02 00 01 00 05 46 00 00 06 03 6E 73 34 C0 5B C0 73 00 01 00 01 00 05 46 00 00 04 D8 EF 20>ff<C0 57 00 01 00 01 00 05 46 00 00 04 D8 EF 22>ff<C0 85 00 01 00 01 00 05 46 00 00 04 D8 EF 24>ff<C0 97 00 01 00 01 00 05 46 00 00 04 D8 EF 26>ff<00 00 29 10 00 00 00 80 00 00 00 Modified bytes are between marks >< original values - 68 instead of 42 and OA instead of ff

@@ 393. rida: / 393. rida: @@
 == Sinkhole elik Kuidas Ennetada Halba Liiklust ==
-DNS on heaks instrumendiks turvateadlikule süsteemiadministraatorile, sest õigesti kasutades on võimalik ära hoida turvaintsidente. Turvaintsidenti tekkimiseks poel tänapäeval teatavasti palju vaja: pruugib vaid brauseriga sattuda "ettevalmistatud" veebilehele ja ongi nakkus pahavaraga majas. Viimane võib kaasa tuua arvutikasutaja pääsutunnuste varguse, konfidentsiaalse siseinfo varguse, osalemise DoS ründes jne. Eduka ennetamise eeldusteks on:
+DNS on heaks instrumendiks turvateadlikule süsteemiadministraatorile, sest õigesti kasutades DNSi omadusi, on võimalik ära hoida turvaintsidente. Turvaintsidenti tekkimiseks poel tänapäeval teatavasti palju vaja: pruugib vaid brauseriga sattuda "ettevalmistatud" veebilehele ja ongi nakkus pahavaraga majas. Viimane võib kaasa tuua arvutikasutaja pääsutunnuste varguse, konfidentsiaalse siseinfo varguse, osalemise DoS ründes jne. Eduka ennetamise eeldusteks on:
 * puhverdava nimeserveri kasutamine DNS nimede lahendamisel
 * me teama pahasid domeeninimesid.

Erinevus lehekülje "DNS ja BIND" redaktsioonide vahel