Sisukord

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

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 lõhestunud isiksusega 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 Expire (aegu) parameeter, olgu selleks näiteks väärtus 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 adekvatselt.

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 Expire 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
also-notifys on kirjeldatud IP(d) millele saata teateid tsooni muutumisest lisaks tsoonis kirjeldatud nimeserveritele
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 @ = test-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.

Puhverdava nimeserveri turvamine

NB! Puhverdav nimeserver peab olema päringuteks kättesaadav ainult sinu teenindatavatale klientidele. Miks, seda loe allpoolt DNS nõrkuste jutupunktist. Seda ei saa kahjuks korraldada ainult ühe direktiiviga named.conf 'is. Nimelt lubab BIND ikkagi punkti küsimist ja vastab puhvris olevate nimedega ka siis, kui options sektsiooni sees on rekursioon lubatud ainult "omadele".

Lahendada saab selle ülesande vaadete abil, kuna vaadetest pisut juttu ka allpool siis toon ära näidis seadistuse (alates BIND v9.3.x) ilma pikemate kommentaarideta:

view "seest" {
 match-clients { 192.168.4.0/24; };
 allow-query { 192.168.4.0/24; };
 additional-from-cache yes;
 recursion yes;
};
view "maailmast" {
 match-clients { any; };
 allow-query { none; };
 additional-from-cache no;
 recursion no;
};

Mugavuse mõttes võib match-clients juures kasutada pääsuloendeid, neist saab lugeda täpsemalt ka "DNS vaated" jutupunktis. Näidis seadistuses on lubatud rekursiivsus sisevõrgu klientidele 192.168.4.0/24 võrgust, kõigile teistele aga keelatud. Blokk view "nimi" { }; on piltlikult öeldes seadistus mis käib nonde klientide kohta, kes match-clients osaga kokku langevad, sinna lähevad direktiivid mis tavaliselt ikka seadistusfailis käivad (tsoonid jms).

Puhverdava ja autoriteetse BIND nimeserveri turvamine

Tihti on otstarbekas kasutada oma nimeserverite paari mõne tsooni puhul pädeva ehk autoriteetsena ning lubada samal ajal oma sisemistel serveritel lahendada nendes avalikke nimesi. Muidu peaks kasutama vähemalt nelja nimeserverit. Kuna liigsetele päringutele vastamist saab kuritarvitada, siis tuleb kasutada view ehk virtuaalseid nimeservereid. Kõige parem on need teha rekursiivne/autoriteetne tüübi järgi. "."-tsoon peab olema kirjeldatud "seest" osas, muidu on võimalik kasutada teie nimeserverit mahu rünnakus. Järgnev testitud ja ühes suuremas nimeserveris kasutuses olev kergelt lühendatud näide on tulnud kaasa OpenBSD 4.2 nimeserveriga.

view "seest" {
       match-clients { 192.168.4.0/24; };
       match-recursive-only yes;
       // Standard zones
       //
       zone "." {
               type hint;
               file "standard/root.hint";
       };
       zone "localhost" {
               type master;
               file "standard/localhost";
               allow-transfer { localhost; };
       };
       zone "127.in-addr.arpa" {
               type master;
               file "standard/loopback";
               allow-transfer { localhost; };
       };
       zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
               type master;
               file "standard/loopback6.arpa";
               allow-transfer { localhost; };
       };
       zone "com" {
               type delegation-only;
       };
       zone "net" {
               type delegation-only;
       };
};
view "autoriteetne" {
       recursion no;
       additional-from-auth no;
       additional-from-cache no;
       //zone "myzone.net" {
       //      type master;
       //      file "master/myzone.net";
       //};
};

Microsofti DNS serverist

Pisipehme nimeserveri turvamine on pisut keerulisem, põhimõtteliselt on siin kaks olukorda:

kui Interneti nimeteenus peab olema välistele klientidele kättesaadav (su nimeserver on pädev mõne domeeni suhtes), siis tuleb paigaldada kaks nimeserverit - üks rekusrsiivne ja teine pädev, ning piirata ligipääs rekursiivsele kas siis võrgu topoloogiaga või tulemüüri pääsulistiga
kui Interneti nimeteenus ei pea olema välistele klientidele kättesaadav siis on lihtne piirata ligipääs rekursiivsele kas siis võrgu topoloogiaga või tulemüüri pääsulistiga

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 teha! 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 hoolikamalt 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 aspektidest, näiteks kui keegi otsustab rünnata nimeserverit ja see tal õnnestub, kaob lisaks 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

DNS vaated

DNS vaadete puhul seadistatakse nimeserver selliselt, et erinevate klientide sama DNS päring saab erineva vastuse. 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. Samuti võib kasutada seda täiendava turvameetmena näiteks välismaalt lähtuva rünnaku efektiivsemaks tõrjumiseks - kui meil on pääsuloend milles loetletud kõik kohalikud (s.o. Eesti) võrgublokid siis saame suunata kas kohalikud kasutajad teise serverisse (mis ei ole ründe all) või siis saata hoopis ründajad kuhugi teise serverisse ... Kindlasti peab DNS vaadete implementeerimise planeerimisel arvestama täiendava ressursikuluga haldamisel.

Seadistamine koosneb kahest põhietapist

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

Pääsuloendite loomine

Pääsuloendid on sarnase iseloomuga IP aadresside ja võrgublokkide hulgad, millele on antud nimi. Pääsuloendi loome peamises seadistusfailis named.conf direktiivi acl abil:

acl sisemised { 192.168.4.0/24; };
acl v2limised { 172.16.16.0/24; };
acl koik_sekundaarsed { 192.168.4.2; 192.168.2.1; };

Kui läheb nimeserveri ehitamiseks natukenegi suurema süsteemi tarvis, tasub kindlasti seadistusfaili loomisel planeerida pääsuloendite kasutamist.

Tsooni vaadete loomine

Tsoonide puhul siis määratakse lisaparameetriga ära, kes seda tsooni "näevad". Kui tahame samu domeeninimesid erinevate IPdega näidata sõltuvalt pärija IP aadressist, siis tuleb luua niimitu tsoonifaili kuimitu erinevat vaadet domeeninimedest soovitakse anda.

Seadistusfailis named.conf kirjeldame

1. sisemise vaate

view "sisene" {
   match clients { sisemised; };

 zone "test-domeen.ee" {
      type master;
      also-notify { 192.168.2.1; };
      allow-transfer { koik_sekundaarsed; };
      file "/etc/bind/pri/int-test-domeen.ee";
 };
};

match clients parameetriga öeldakse, kellele see vaade kehtib. sisemised on pääsuloendi, mille defineerisime eelmises punktis, nimi.

2. välimise vaate

view "v2line" {
   match clients { v2limised; };

 zone "test-domeen.ee" {
      type master;
      file "/etc/bind/pri/ext-test-domeen.ee";
 };
};

ext-test-domeen.ee ja int-test-domeen.ee on tsoonifailid, mis sisaldavad siis sellist IP infot nagu meil pärivale kliendile sõltuvalt sellest, kus võrgus ta asub, on vaja näidata.

Sender Policy Framework (SPF)

SPF on pikas spämmi vastu võitlemise meetodite reas üks tehnoloogia, mille kasutamiseks vajalike muudatuste tegemine on DNSi haldurile suhtliselt lihtne. Täpsemalt võib süntaksi kohta lugeda siit, kokkuvõtlikult võib öelda, et SPFi puhul kontrollitakse, kas saatja aadressis olev domeen võib sellelt IPlt kirju saata, millelt ta seda üritab teha.

Selgitame näite varal kuivõrd lihtne on seda üles seada, meie testidomeeni tsoonifailis:

 @     IN      TXT     "v=spf1 ip4:192.168.4.0/24 -all"

tõlgendus oleks siis selline: minu domeeni kirju võivad saata ainult need, kelle IP on võrgublokist 192.168.4.0/24

Teisi mehhanisme, mida SPF poliitika kirjeldamisel kasutada, võiks lugeda juba eelnevalt viidatud süntaksi käsiraamatust.

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 pole tänasel päeval teatavasti palju vaja: pruugib vaid veebilehitsejaga sattuda pahalaste poolt spetsiaalselt "ettevalmistatud" veebilehele ja ongi nakkus pahavaraga majas. Viimane võib kaasa tuua arvutikasutaja pääsutunnuste varguse, konfidentsiaalse siseinfo varguse, osalemise DoS ründes jne.

Sinkholega halva liikluse eduka ennetamise eeldusteks on:

puhverdava nimeserveri kasutamine DNS nimede lahendamisel
me teame pahasid domeeninimesid.

Toimemehhanism on lihtne: enne kui kasutaja jõuab brauseriga pahavaraga nakatavale lehele, peab lehitseja tegema 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.

Pahade domeenide nimistu saab tavaliselt teemaga tegelevatelt organisatsioonidelt, malwaredomainlist.com on üks võimalikest valikutest. Kohalik CERT oskab kindlasti aidata nimistu tekitamisel.

Nimeserveri saab seadistada suht lihtsalt,

1. loome tsoonifaili sink.zone mis on ühine kõigil pahadel domeenidel

@         IN     SOA paha paha (
                         1
                         3600
                         1800
                         1W
                         600 )
@	IN	NS	127.0.0.1
	IN	A	127.0.0.1
*		A	127.0.0.1

tsoonifailist nähtub, et suuname kogu paha liikluse nimepärija kohalikku arvutisse.

2. registreerime domeeni named.conf-is

zone "paha.domeen" IN { type master; file "pri/sink.zone"; };

... ja teeme rndc reload. Valmis!

DNSi nõrkused

Aegade jooksul on DNSi haldajaid tabanud nii mõnigi halb üllatus. Katan lühidalt kaks teemat mis siiani aktiivses kasutuses kurikaelade poolt.

"Punkti" küsimise rünne, DNS võimendus

"Punkti" küsimise rünne on teenusetõkestus rünne, kus ebaõigesti seadistatud DNS serverit kasutatakse ära kellegi teise ründamiseks. Peamiseks toimemehhanismiks on siin kahe protokolli kombinatsioonis tekkiv nõrkus:

UDP protokolli puhul on võimalik paketi saatja võltsimine ja
DNS protokoll ei kehtesta mehhanisme millega saaks tuvastada võltsitud saatja aadressiga päringut

Toimib rünne siis selliselt:

paljudele rekursiivsetele nimeserveritele esitatakse korraga "." pärimine (punkti kohta loe rekursiivse nimeserveri sektsioonidest) võltsitud saatja aadressiga. Saatja aadressiks pannakse rünnatav IP.
nimeserverid vastavad võltsitud aadressile, viimane saab korraga palju UDP liiklust mis lähtub erinevatest geograafilistest lokatsioonidest üle kogu maailma, mis ummistab rünnatava sidekanali(d).

Rünne on efektiivne tänu võimendusefektile, mis tuleneb küsimuse ja vastuse bitisuuruste erinevusest. Võimendusefekti lisab DNS protokolli laienduse kasutamine, mis võimaldab pärida/saata mahult suuri vastuseid. Sellisel puhul loob ründe teostaja tavaliselt eelnevalt domeeninimime mahuka TXT kirje ja suure TTLiga mida "küsida" rekursiivsetelt võltsitud UDP paketi aadressiga.

Ründe saab hetkel ära hoida vaid seadistades rekursiivsed nimeserverid teenindama ainult "omi" kliente. Vastutus on kõigil süsteemiadministratoritel, kes haldavad nimeservereid, sest ebakorrektne seadistus võib viia selleni, et osaled enda teadamata rünnakus "pahade" poolel.

Puhvrimürgitamise rünne

Puhvri mürgitamise eesmärgiks on suunata ohvrite liiklus ümber nende endi teadmata. Saavutatakse see selliselt, et "sokutatakse" rekursiivse nimeserveri puhvrisse valed andmed nimelahenduse kohta. Näiteks: kui klient soovib külastada panka domeeninimega minupank.ee mille IP aadress on 1.2.3.4 ja pahalastel õnnestub sooritada puhvri mürgitamise rünne mille tagajärjel arvab rekursiivne nimeserver, et minupank.ee IP aadress on hoopis 6.6.6.6 ning sellel aadressil serveeritakse veebilehti mis äravahetamiseni sarnased panga minupank.ee omadega, siis on võimalikuks tagajärjeks rahast ilmajäämine.

Kergeim ellu viia selliste rekursiivsete nimeserveritega mille päringute nummerdamine ja vastuse pordi number on ennustatav. Riski võimalik vähendada tarkvarauuendusega mis implementeerib korralikumalt päringute nummerdamise. 100% kindlust ei anna aga seegi, sest päringu identifitseerimiseks kasutatava elemendi väärtuste arv ei ole tänastes tingimustes väga suur (16bitti). Testida saab oma nimesererveid abivahendite abil mis asuvad sellel lehel.

Kasutatud materjalid

Lingid

Puust ja punaseks ühe DNSi vea seletus koos värviliste piltidega. Väga ilus töö. http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

https://wiki.itcollege.ee/index.php/Nimeserveri_seadistamine_BIND9_näitel

http://code.google.com/p/namebench/ google nimeserverite test

DNS ja BIND