Sisukord

1 Traditsiooniline sissejuhatus
2 BINDi seadistamine
3 DNS edasijõudnutele
4 DNSi nõrkused
- 4.1 "Punkti" küsimise rünne
- 4.2 Puhvrimürgitamise rünne
5 Kasutatud materjalid

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. See kirjutis põhineb Debian 5.0s pakendatud bindil versiooninumbriga 9.5.1.

Enne praktilise osa 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.

BINDi haldamise kiirkursus

Seadistusfailid: tavaliselt /etc/bind kataloogis, distributsiooniti võib see erineda. Peamine seadistuste fail on named.conf.

Käivitusfailid: /etc/init.d/bind9 on nimeserveerimise deemoni ohjamiseks, nagu ikka, parameeter start käivitab ja stop peatab. Kasutamiseks pead olema juurkasutaja. rndc on nimeserveerimise deemoniga suhtlemiseks vajalik käsk. Selle kasutamiseks ei pea olema juurkasutaja aga edukat toimimist peab tavakasutaja puhul natuke serveris korraldama. dig on nimeserveri klient kelle kaasabil saab nimeserveritele esitada küsimusi. DNSSEC osast leiad veel paar käsku, tavalise halduse osas neid ei ole vaja.

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 "test-domeen.ee" { type master; also-notify { 192.168.2.1; }; allow-transfer { koik_sekundaarsed; }; file "/etc/bind/pri/test-domeen.ee"; };

test-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 IP(de)le (vihje: varjatud nimeserver) saata teateid tsooni muutumisest lisaks tsoonis kirjeldatud nimeserveritele. Vaikeseades on notify väärtus juba sisse lülitatud (yes), siin olen ta eraldi välja toonud selguse mõttes
allow-transfer sisaldab kes siis lubanimekirja (sellest allpool) või IP aadresse millel lubatakse üle kanda terve tsoon

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

$TTL 432000 @ IN SOA ns1.test-domeen.ee. hostmaster.test-domeen.ee. ( 2 ; Serial 432000 ; Refresh 86400 ; Retry 2419200 ; Expire 432000 ) ; Negative Cache TTL ; @ IN NS ns1 @ IN NS ns2 @ IN A 192.168.4.5 @ IN AAAA 2a01:158:3:1:21c:c0ff:fe8a:4e79 ns1 IN A 192.168.4.5 ns2 IN A 192.168.4.1 @ IN MX 10 mx mx IN A 192.168.4.10 www IN CNAME @ @ IN TXT "v=spf1 ip4:192.168.4.0/24 -all"

TTL, Refresh, Retry, Expire, Negative Cache TTL on aeg mis on sekundites. TTL on tsooni "eluaeg" elik aeg, kui kaua hoiavad puhverdavad nimeserverid tsooni andmeid. Tsoonifailis oluliste domeeni andmete muutmise eel on kasulik "keerata" TTL võimalikult väikeseks, et muutus leviks kiirelt. Tavaolukorras on kasulik hoida see 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 AAAAKKPPII 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.test-domeen.ee.
@ IN NS ns1

SOA kirje on tsoonifailis kohustuslik esimene kirje. Lisaks erinevatele aegumisnumbritele sisaldab pädeva nimeserveri domeeninime (ns1.test-domeen.ee) ja halduri kontakti
NS kirjed on antud juhul kleepkirjed (glue record). Kleepekirje on delegeerimise osana kasutatav A-kirje mis on vajalik siis kui delegeeritava tsooni pädev nimeserver asub delegeeritavas tsoonis endas
A kirjed on siis tavalised aadresskirjed mis seovad domeeninime IP aadressiga
AAAA kirje seob domeeninime IPv6 aadressiga
MX kirje sisaldab domeeni e-posti vastuvõtva serveri prioriteeti (servereid võib olla mitu, väiksem number on kõrgem prioriteet) ja e-postiserveri domeeninime
TXT kirje on informatiivse iseloomuga, antud juhul olen seda SPFi jaoks tarvitanud (SPFist juttu pisut allpool)

Kui meil proovidomeen on õnnelikult üles seatud lisame harjutamise mõttes ka pöördteisenduse seadistuse. Testvõrgus oleme kasutusele võtnud 192.168.4.0/24 võrgubloki, sellele loomegi pöördteisenduse:

1. primaarses seadistusfailis named.conf viidatakse tsoonifailile:

zone "4.168.192.in-addr.arpa" { type master; file "/etc/bind/pri/4.168.192.in-addr.arpa"; };

2. kirjeldame pöördteisenduse tsooni

$TTL 432000 @ IN SOA ns1.test-domeen.ee. hostmaster.test-domeen.ee. ( 2 ; Serial 432000 ; Refresh 86400 ; Retry 2419200 ; Expire 432000 ) ; Negative Cache TTL 4.168.192.in-addr.arpa. IN NS ns1.test-domeen.ee. 1.4.168.192.in-addr.arpa. IN PTR ns1.test-domeen.ee. 5.4.168.192.in-addr.arpa. IN PTR ns2.test-domeen.ee. 10.4.168.192.in-addr.arpa. IN PTR mx.test-domeen.ee. $ORIGIN 4.168.192.in-addr.arpa. $GENERATE 32-128 $ PTR host-$.test-domeen.ee.

Algus on pöörteisenduse tsoonil samasugune nagu tavapärasel tsoonifailil
PTR kirjed on siis need, mida peamiselt kohtab pöördteisenduse failis. 1.4.168.192.in-addr.arpa. IN PTR ns1.test-domeen.ee. tähendab: IP aadressi 192.168.4.1 domeeninimi on ns1.test-domeen.ee.
$GENERATE direktiiv on bindi spetsiifiline, võimaldab algoritmiliselt kirjeldatavaid aadresse genereerida, antud juhul siis luuakse selle ühe $GENERATE reaga nimed host-32.test-domeen.ee .. host-128.test-domeen.ee IP aadressidele 192.168.4.32 .. 192.168.4.128

Sekundaarse nimeserveri seadistamine

Nagu ka primaarse tsooni seadistamisel, BINDi puhul toimib ka sekundaarse tsooni seadistamine primaarses seadistusfailis named.conf sellisel moel:

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

type slave ütleb, et tegemist on sekundaarse nimeserveriga sellele tsoonile
masters { .. } sektsioon sisaldab primaarsete pädevate nimeserverite IP aadresse kellelt pärida aru tsooni staatuse ja saatuse kohta
file "/etc/... kirjeldab mis failis andmeid hoidma hakatakse. Seda faili meie ei loo, küll aga peab vaatama, et viidatud kataloog oleks kirjutatav bindi protsessile.

Aktiivseks saame seadistuse teha käsuga rndc reload, enne seda tasub kontrollida kas primaarse nimeserveri seadistusfailis on allow-transfer sektsioonis mainitud sekundaarse nimesereveri IPd.

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

Puhverdava nimeserveri seadistamiseks on meil vaja luuav vastav sektsioon nimeserveri peamises seadistusfailis ning nn vihjefaili.

1. named.conf seadistamine

zone "." { type master; file "/etc/bind/db.root" };

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

NB! Puhverdav nimeserver peab olema päringuteks kättesaadav ainult sinu teenindatavatale klientidele.

Olulistest asjadest

TTLi olulisusest

Meenutame, et TTL näitas sekundites seda aega kaua andmeid hoitakse puhvris peale seda kui neid ükskord on päritud. Kordan üle, et tsoonifailis oluliste domeeni andmete muutmise eel on väga kasulik "keerata" TTL võimalikult väikeseks (5 minutit), et muutus leviks kiirelt ja teha tuleks siis TTL suuruse jagu sekundeid enne kui muudatust planeeritake! Tavaolukorras on kasulik hoida see numbrit võimalikult suurena, et võimalikud äpardused nimeserveritega ei mõjutaks olulisel määral domeeninimede lahendamist.

Nimeserveri turvamise olulisusest

Sissejuhatavas osas sai rõhutatud DNSi olulisust tänasel päeval kogu Interneti toimimise seisukohalt. Kui laskuda globaalselt tasemelt niiöelda indiviidi tasemele, siis ei kaota DNS seda tähtsust. Kuna DNSi kirjeid muutes on võimalik tekitada palju halba (infovargus, teenusetõkestus jne) siis peaks tavalisest hoolikalt jälgima mis toimub nimeserveris. Soovituslik on ka seadistuste hoidmine näiteks CVS või SVN versioonihaldustarkvara abil keskses repositooriumis. Sellisel juhul on suurema õnnetuse juhtumisel võimalik seadistustes "ajas tagasi rännata" ja ka kiirelt taastada puhtale installatsioonile endises seadistuses toimivat nimeserverit.

Eraldatuse olulisusest

Kui tegemist vähegi suurema infosüsteemiga tasub end säästa peavalust ja hoida rekursiivsed nimeserverid füüsiliselt eraldi pädevatest nimeserveritest. Eeskätt on see oluline turvalisuse aspektist - kui keegi otsustab rünnata teie nimeserverit ja see tal õnnestub kaob lisaks su domeeninimedele ka võimalus interneti kasutamiseks.

IPv6

Ei saa me enam läbi ilma IPv6-ta, seega peaks süsteemihaldur olema valmis selleks puhuks astub uksest sisse ülemus, kes kuulnud et selline tore asi nagu IPv6 on olemas, ja käsib homseks ära korraldada firma veebilehe kättesaadavuse IPv6 aadressilt. Lisaks võrguosale tuleb siis teha ka muudatus DNSi seadistusesse.

Domeeninimele IPv6 aadressi lisamine oli meie eelpooltoodud näite varal piisavalt lihtne:

@	IN	AAAA	2a01:158:3:1:21c:c0ff:fe8a:4e79

Pöördteisenduse registreerimine on ka analoogne IPv4'le, mõnevõrra ebamugav võib olla meeletu koguse numbrite rittaseadmine ilma vigu tegemata sest kui IPv6 aadressi kirjutamisel võib järjestikused "0" (nullid) ära jätta siis DNSi kirje puhul seda rõõmu ei ole, lisaks tuleb in-addr.arpa. asemel kasutada ip6.arpa.-t.

$ORIGIN 1.0.0.0.3.0.0.0.0.8.5.1.1.0.a.2.ip6.arpa.
9.7.e.4.a.8.e.f.f.f.0.c.0.c.1.2   14400 IN PTR ns1.test-domeen.ee.

DNSiga seotud e-posti teenuse probleemidest

Siintoodud info on oluline meelese pidada nii DNSi kui postiserverite haldajatel.

IPl peab olema pöördteisendus
IP pöördteisendus domeeninimeks ja domeeninime teisendus IPks peavad klappima
kui MX kirjega on viidatud mitmele serverile siis need serverid peavad ka vastama. Ei toimu automaagilist fail-overit teisele serverile kui üks MXiga viidatud servereist peaks mingil põhjusel rivist väljas olema. See omakorda tähendab seda, et hakkab juhtuma müstilist kirjade "venimist".
Kui registreerid domeeni, siis loo ka abuse, postmaster ja hostmaster postkastid et sinuga saaksid erinevad organisatsioonid operatiivselt suhelda kui mingi ikaldus peaks juhtuma.

DNS edasijõudnutele

Vaated aka split DNS

Split DNS on selliselt seadistatud nimeserver mis erinevate klientide samadele DNS päringutele vastab erinevalt. Näiteks on firma veebileht paigutatud privaataadressil sisevõrku ja soovitakse internetilüüsi mitte koormata "ringiga" veebilehel käimisega. Sellisel juhul seadistatakse DNS server vastama sisevõrgust pärijatale sisevõrgu IP aadressi ja välisvõrgust pärijatele välist IP aadressi. Kindlasti peab split DNSi implementeerimise planeerimisel arvestama täiendava ressursikuluga haldamisel.

Seadistamine koosneb kahest põhietapist

ACLide ehk pääsuloendite loomine
tsoonide "vaadete" loomine

Pääsuloendite loomine

Tsooni vaadete loomine

DNSSEC

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.

Toimimismehhanism 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 teadaolevalt pahavaraga nakatavate domeenide suhtes ja suuname liikluse nende domeeninimede suunas kas /dev/nulli, või siis spetsiaalselt ettevalmistatud serverisse.

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

DNS ja BIND