DNS ja BIND

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 on ü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 - legaalne on tee:

. -> 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)

Nimede 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 - [3490].

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" - tsoon sisaldab terviklikku pilti oma taseme domeeninimedest ja domeenide delegatsioonidest - lähtudes tundub mõistlik olevat tarkvara loomisel lähtuda sest kui me lähtuksime tarkvara luues domeenist, siis tekiks palju segadusi mis on seotud alamdomeenide ja domeenide delegatsioonidega. Ilmselt ei ole eriti üllatav seega 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 nimest IPks ja IPst DNS nimeks 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.

Siit on kaks olulist infokillukest, mida süsteemiadministraator peaks teadma:

 domeeninimega või domeeniga seotud soovid ja mured tuleb esitada TLD valdajale
 pöördteisendusega seotud soovid ja mured tuleb esitada ISPle

Puhverdav nimeserver

Puhverdav nimeserver (tuntud ka rekursiivse nimeserveri nime all) ei ole pädev ühegi domeeni suhtes, aga kindlasti on seal kirjeldatud tsoon "." (punkt) s.t. nimeserverid kes teavad vastuseid punktist järgmise sammu 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 domeenidest. Puhvris hoitakse domeeninimesid TTLiga määratud aeg, aeg ajalt võib osutuda vajalikuks puhvri tühjendamine. Tänasel päeval on süsteemiadministraatoril vajalik täiendavalt kaitsta puhverdavat nimeserverit. Miks ja kuidas, sellest tuleb juttu allpool.

BINDi seadistamine

Selgitame BINDi seadistamist reaalelulise näite varal, seadistades BINDi serveerima domeeni domeen.ee kõikvõimalikel viisidel ja kõikvõimalikes seadistustes.

Tagasi "juurte" juurde

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

Kasutame selleks nimepärimise vahendit dig, mis on tarkavrapaketi BIND osana kliendi tööriist, ja otsime selle abil vastuse:

zyx@tux$ dig ee NS

<<>> DiG 9.5.1-P2 <<>> ee NSglobal options printcmd Got answer ->>HEADER<<- opcode QUERY, status: NOERROR, id: 55277 flags qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0QUESTION SECTIONee. IN NSANSWER 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 msee. 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 msee. 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

Ülaltoodu võib tekitada lisaküsimusi:

miks on nii palju nimeservereid ühe tsooni kohta? 
kust teadis lokaalne nimeserver "." nimeserverit, millelt edasi pärida?

Alustades viimasest - kust teadis lokaalne nimeserver "juurte" aadresse? Vastus lihtne - internetist allalaetud vihjete abil! Värske versioon nimetet vihjefailist on alati saadaval [[1]] ja sisaldab ta infot kuidas leida juurnimeservereid, kellelt nimeinfot edasi pärida.

Primaarse 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";

}; Kus:

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.1IN MX 10 mx

mx IN A 172.16.34.10 www IN CNAME @ @ IN TXT "see on domeen"

Kus:

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 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";

};

Vaated aka split zone

TTLi olulisusest

DNSSEC

IPv6

Ründed

"Punkti" küsimine

Puhvrimürgitamine

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