Kuutõrvaja - Kasutaja kaastöö [et]

DNS ja BIND

2009-09-01T13:50:41Z

Juhani:

= 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:

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

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 - [http://www.ietf.org/rfc/rfc3490.txt 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:

<tt>
.
/
ee
/
neti
/ \
www ns
\
h01
</tt>

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 ''neti''i
* ''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:

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

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 [http://kuutorvaja.eenet.ee/wiki/DNS 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:

<tt>
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.
</tt>

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)

<tt>
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
</tt>

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

*''test-domeen.ee'' on domeen, mille suhtes ollakse '''pädev'''
*''type master'' viitab sellele, et tegemist on '''primaarse''' nimeserveriga
*''also-notify''s 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:'''
<tt>
$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"
</tt>

* '''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.conf''is ''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.conf''is 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:'''
<tt>
zone "4.168.192.in-addr.arpa" {
type master;
file "/etc/bind/pri/4.168.192.in-addr.arpa";
};
</tt>

'''2. kirjeldame pöördteisenduse tsooni'''

<tt>
$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.
</tt>

*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:
<tt>
zone "test-domeen.ee" {
type slave;
masters { 192.168.4.1; };
file "/etc/bind/sec/test-domeen.ee";
};
</tt>

*'''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 '''
<tt>
zone "." {
type master;
file "/etc/bind/db.root";
};
</tt>

'''2. Värske versioon vihjefailist''' on alati saadaval [http://www.internic.net/zones/named.root 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 [http://www.openspf.org/SPF_Record_Syntax 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 teama 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/null''i, 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 [https://www.dns-oarc.net/ sellel lehel].

 
 
 

= Kasutatud materjalid =

* [http://kuutorvaja.eenet.ee/wiki/Interneti_domeeninimede_s%C3%BCsteem Domeeninimede süsteem by Imre Oolberg]
* [https://www.isc.org/software/bind BINDi kodu Internetisüsteemide konsortsiumi lehel]
* [http://www.ietf.org/rfc/rfc1034.txt RFC 1034]
* [http://www.ietf.org/rfc/rfc1035.txt RFC 1035]
* [https://www.isc.org/files/Bv9.6ARM.pdf BINDi administraatori käsiraamat]
* [https://www.dns-oarc.net/ DNS Operations, Analysis and Research Centeri veebileht]

LVM

2009-05-18T15:36:12Z

Juhani: /* LVM kolimine ühelt füüsiliselt kettalt teisele */

===LVM===

LVM moodustab kihi failisüsteemi ja füüsilise kõvaketta vahele. Kui kasutusel on ka RAID, siis võiks kujutleda kihte selliselt

* Failisüsteemid
* LVM
* RAID
* Füüsilised plokkseadmed

LVM võimaldab teha failisüsteemidest snapshotte ning kui failisüsteem seda toetab, siis ka olemasoleva failisüsteemi suurust muuta.

===Tuuma seadistamine===

Linuxi 2.6 tuuma puhul on oluline lisaks füüsiliste ketaste draiveritele valida eriti device-mapper, ühe olulise mooduli nimi on dm_mod, fail dm-mod.ko

Device Drivers -> Multi-device support (RAID and LVM) -> valida kõik

2009 aastal aga on vaevalt tarvis tavakasutajal reeglina omale ise tuuma kompileerima hakata, sobib ja on soovitav kasutada distributsiooni tuuma.

===LVM seadistamine===

LVM lahenduse seadistamiseks sobib kasutada tarkvara lvm2 http://sourceware.org/lvm2/, reeglina on see distributsiooni jaoks pakendatud.

LVMi tuleks käsitleda kolmekihilisena

# Plokkseadmed tuleb LVM juures kasutamiseks spetsiaalselt märgistada.
# Plokkseadmed on organiseeritud voluum gruppidesse, mis on konteinerid loogilistele voluumidele.
# Loogilised voluumid on kõige otsekohesemalt kasutatavad, sinna peale moodustatakse tavaliselt failisüsteemid.

Iga kihi tegevusteks kasutatakse oma utiliite, vastavalt nimedega pv*, vg* ja lv*.

Esmalt tuleb olemasolevad blokkseadmed (füüsilised kõvakettad või RAID seadmed) märkida füüsilisteks voluumideks

aix:~# pvcreate /dev/md0

Tulemust näeb sedasi

aix:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name voluum
PV Size 465.77 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 119237
Free PE 106949
Allocated PE 12288
PV UUID dC1zcu-3caT-Uirt-sbB9-r7j0-Yf06-FUGVmP

Seejärel tuleb moodustada loogiline grupp

aix:~# vgcreate voluum /dev/md0

Tulemust näeb selliselt

aix:~# vgdisplay voluum
--- Volume group ---
VG Name voluum
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 16
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 465.77 GB
PE Size 4.00 MB
Total PE 119237
Alloc PE / Size 12288 / 48.00 GB
Free PE / Size 106949 / 417.77 GB
VG UUID j8OONB-HABJ-HH1g-7Ywx-RLVG-1OzZ-IA68j9

Lõpuks moodustada loogilised voluumid

aix:~# lvcreate -L 16G -n vm01 voluum
Logical volume "vm01" created
aix:~# lvcreate -L 16G -n vm02 voluum
Logical volume "vm02" created
aix:~# lvcreate -L 16G -n vm03 voluum
Logical volume "vm03" created

Tulemust näeb selliselt

aix:~# lvdisplay /dev/voluum/vm01
--- Logical volume ---
LV Name /dev/voluum/vm01
VG Name voluum
LV UUID dXfxk5-0jmz-TfQY-hTwz-XxKw-XtgS-H1IOvz
LV Write Access read/write
LV Status available
# open 0
LV Size 16.00 GB
Current LE 4096
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:0

Voluum saab olla available või NOT available olekus. Kasutada saab available voluume, kusjuures lvcreate järgselt viiakse voluum automaatselt available olekusse.

Voluumi eemaldamiseks tuleb esmalt ta viia NOT available olekusse

aix:~# lvchange -a n /dev/voluum/vm01

ning seejärel

aix:~# lvremove /dev/voluum/vm01

Voluumigruppide eemaldamiseks tuleks öelda

aix:~# vgremove /dev/voluum

Peale arvuti käivitamist tuleb näiteks Debian GNU/Linuxi puhul öelda

aix:~# /etc/init.d/lvm start

/dev kataloogi seadmete moodustamiseks ning ennem arvuti seiskamist

aix:~# /etc/init.d/lvm stop

===Snapshot===

Snapshot tekitab koopia tema moodustamise ajahetkele vastavast loogilise seadme olekust, mida saab seejärel kasutada nagu tavalist failisüsteemi. Snapshoti tegemise eelduseks on, et samas voluumi grupis on piisavalt vaba kasutamata ruumi, st mida pole omistatud ühelegi loogilisele voluumile.

aix:~# lvcreate -L2G -s -n vm01_snapshot /dev/voluum/vm01

Tavaliselt on snapshoti moodustamise põhjuseks soov olemasoleva failisüsteemi seisuga mingi muudatus järgi proovida, näiteks tarkvara uuendamine ilma, et see töötavat süsteemi segaks. Sel juhul tuleb peale snapshoti moodustamist ta külge ühendada

aix:~# mount /dev/voluum/vm01_snapshot /mnt/vm01_snapshot

Snapshoti vabastamiseks tuleb esmalt ta lahti ühendada ja siis öelda

aix:~# lvremove /dev/voluum/vm01_snapshot

Snapshoti moodustamine kasutab mõni MB arvuti mälu, mis snapshoti eemaldamisel vabastatakse. Lisaks tuleb arvestada, et kui labelit kasutavast juurifailisüsteemist teha snapshot, siis on sama label kahel failisüsteemil ning operatsioonisüsteemi alglaadimine ei õnnestu sellises olukorras. Lahenduseks võiks olla snapshotile muu labeli omistamine öeldes

bash# e2label /dev/voluum/juurikas uuslabel

===LVM kolimine ühelt füüsiliselt kettalt teisele===

Kui soovida kolida juurpartitsiooni sisaldav LVM voluum teisele füüsilisele kettale või mdadm abil tehtud mirrorile, siis kõigepealt installeerime mdadm

apt-get install mdadm

Siin tuleks valida küsimusele vastuseks "all" devices

Järgnevalt teeme mirrori

debian:~# mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sdc2 missing

Ning kolime juurfailisüsteemi sisaldava voluumgrupi ümber /dev/md0

debian:~# lvm
lvm> pvcreate /dev/md0
Physical volume "/dev/md0" successfully created
lvm> vgextend juur /dev/md0
Volume group "juur" successfully extended
lvm> pvmove /dev/sda2 /dev/md0

Ootame, kuni move käsk lõpetab töö ja edasi:

lvm> vgreduce juur /dev/sda2
lvm> quit

Kui /dev/sda2 on täpselt sama suur, kui /dev/sdc2, siis soovitavalt peale rebooti saame panna sda2 lisaks md0 mirrorisse.

Antud kolimise näide peaks kehtima juhul, kui partitsioon, kuhu kolitakse on piisavalt suur, et mahutada kõik sellel kettal olevad Logical Volumed (lvm -> käsk pvs), samuti peaks see võimaldama kopeerida ka ainult üht ketast mitmest kettast koosnevate LVMide puhul. Mõistlik on sellist operatsiooni teha siiski eelnevalt kontrollides varukoopiate olemasolu ja cd-lt buutides.

===Veel toredaid programme===

Programm lvm töötab interaktiivses režiimis

aix:~# lvm
lvm> pvs
PV VG Fmt Attr PSize PFree
/dev/md0 voluum lvm2 a- 465.77G 167.77G

lvm> lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
kraam250 voluum -wi-ao 250.00G
vm01 voluum -wi-ao 16.00G
vm02 voluum -wi-ao 16.00G
vm03 voluum -wi-ao 16.00G

lvm> vgs
VG #PV #LV #SN Attr VSize VFree
voluum 1 4 0 wz--n- 465.77G 167.77G

lvm> lvscan
ACTIVE '/dev/voluum/vm01' [16.00 GB] inherit
ACTIVE '/dev/voluum/vm02' [16.00 GB] inherit
ACTIVE '/dev/voluum/vm03' [16.00 GB] inherit
ACTIVE '/dev/voluum/kraam250' [250.00 GB] inherit

lvm> vgscan
Reading all physical volumes. This may take a while...
Found volume group "voluum" using metadata type lvm2

lvm> pvscan
PV /dev/md0 VG voluum lvm2 [465.77 GB / 167.77 GB free]
Total: 1 [465.77 GB] / in use: 1 [465.77 GB] / in no VG: 0 [0 ]

===Voluumi ümbernimetamine===

Voluumi nime muutmiseks tuleb esmalt voluumi kasutamine lõpetada, nt vastav failisüsteem lahti ühendada ning märkida voluum mitte-aktiivseks ning seejärel näidata vana ja uus nimi

bash# lvchange -a n /dev/voluum/voluuminimi
bash# lvrename /dev/voluum/voluuminimi /dev/voluum/voluumi_uus_nimi

Seejärel märkida voluum uuesti aktiivseks ning kasutada tavapäraselt moel

bash# lvchange -a y /dev/voluum/voluumi_uus_nimi

===Märkused===

* loogilise voluumi moodustamisel saab määrata suurust LVMi jaoks kõige nö loomulikumates mõõtühikutes, extent'ides, nt kogu volume groupi suuruse logical volume tekitamiseks tuleb öelda

# lvcreate -l 100%VG -n voluuminimi grupinimi

* Tihtipeale ei ole LVM seadistusfailis /etc/lvm/lvm.conf tarvis muudatusi teha, aga seal saab juhtida filter direktiiviga, milliseid seadmeid LVM käsitleb võimaliku ressursina LVM moodustamiseks või nt kuivõrd LVM utiliitidega sooritatud tegevusi logitakse sh kuhu. Kusjuures, kui filter parameetrit muuta tuleb seejärel öelda 'vgscan', et LVM cache failis /etc/lvm/.cache uuendataks.
* Kõigi LVM volume grupi voluumide aktiivseks (või mitteaktiivseks) muutmiseks sobib öelda vastavalt

# vgchange -a y volumegrupinimi
# vgchange -a n volumegrupinimi

* Kui pvdislay ei näita seadmete nimekirjas oodatavat seadet, maksab küsida otse

# pvdisplay /dev/md0

* Voluumi grupi eemaldamisel kututatakse kõik grupis olevad voluumid

# vgremove data
Do you really want to remove volume group "data" containing 32 logical volumes? [y/n]: y
Logical volume "fs" successfully removed
Logical volume "moraal" successfully removed
Logical volume "cyrus_data" successfully removed
...
Volume group "data" successfully removed

LVM

2009-05-18T15:29:27Z

Juhani:

===LVM===

LVM moodustab kihi failisüsteemi ja füüsilise kõvaketta vahele. Kui kasutusel on ka RAID, siis võiks kujutleda kihte selliselt

* Failisüsteemid
* LVM
* RAID
* Füüsilised plokkseadmed

LVM võimaldab teha failisüsteemidest snapshotte ning kui failisüsteem seda toetab, siis ka olemasoleva failisüsteemi suurust muuta.

===Tuuma seadistamine===

Linuxi 2.6 tuuma puhul on oluline lisaks füüsiliste ketaste draiveritele valida eriti device-mapper, ühe olulise mooduli nimi on dm_mod, fail dm-mod.ko

Device Drivers -> Multi-device support (RAID and LVM) -> valida kõik

2009 aastal aga on vaevalt tarvis tavakasutajal reeglina omale ise tuuma kompileerima hakata, sobib ja on soovitav kasutada distributsiooni tuuma.

===LVM seadistamine===

LVM lahenduse seadistamiseks sobib kasutada tarkvara lvm2 http://sourceware.org/lvm2/, reeglina on see distributsiooni jaoks pakendatud.

LVMi tuleks käsitleda kolmekihilisena

# Plokkseadmed tuleb LVM juures kasutamiseks spetsiaalselt märgistada.
# Plokkseadmed on organiseeritud voluum gruppidesse, mis on konteinerid loogilistele voluumidele.
# Loogilised voluumid on kõige otsekohesemalt kasutatavad, sinna peale moodustatakse tavaliselt failisüsteemid.

Iga kihi tegevusteks kasutatakse oma utiliite, vastavalt nimedega pv*, vg* ja lv*.

Esmalt tuleb olemasolevad blokkseadmed (füüsilised kõvakettad või RAID seadmed) märkida füüsilisteks voluumideks

aix:~# pvcreate /dev/md0

Tulemust näeb sedasi

aix:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name voluum
PV Size 465.77 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 119237
Free PE 106949
Allocated PE 12288
PV UUID dC1zcu-3caT-Uirt-sbB9-r7j0-Yf06-FUGVmP

Seejärel tuleb moodustada loogiline grupp

aix:~# vgcreate voluum /dev/md0

Tulemust näeb selliselt

aix:~# vgdisplay voluum
--- Volume group ---
VG Name voluum
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 16
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 465.77 GB
PE Size 4.00 MB
Total PE 119237
Alloc PE / Size 12288 / 48.00 GB
Free PE / Size 106949 / 417.77 GB
VG UUID j8OONB-HABJ-HH1g-7Ywx-RLVG-1OzZ-IA68j9

Lõpuks moodustada loogilised voluumid

aix:~# lvcreate -L 16G -n vm01 voluum
Logical volume "vm01" created
aix:~# lvcreate -L 16G -n vm02 voluum
Logical volume "vm02" created
aix:~# lvcreate -L 16G -n vm03 voluum
Logical volume "vm03" created

Tulemust näeb selliselt

aix:~# lvdisplay /dev/voluum/vm01
--- Logical volume ---
LV Name /dev/voluum/vm01
VG Name voluum
LV UUID dXfxk5-0jmz-TfQY-hTwz-XxKw-XtgS-H1IOvz
LV Write Access read/write
LV Status available
# open 0
LV Size 16.00 GB
Current LE 4096
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:0

Voluum saab olla available või NOT available olekus. Kasutada saab available voluume, kusjuures lvcreate järgselt viiakse voluum automaatselt available olekusse.

Voluumi eemaldamiseks tuleb esmalt ta viia NOT available olekusse

aix:~# lvchange -a n /dev/voluum/vm01

ning seejärel

aix:~# lvremove /dev/voluum/vm01

Voluumigruppide eemaldamiseks tuleks öelda

aix:~# vgremove /dev/voluum

Peale arvuti käivitamist tuleb näiteks Debian GNU/Linuxi puhul öelda

aix:~# /etc/init.d/lvm start

/dev kataloogi seadmete moodustamiseks ning ennem arvuti seiskamist

aix:~# /etc/init.d/lvm stop

===Snapshot===

Snapshot tekitab koopia tema moodustamise ajahetkele vastavast loogilise seadme olekust, mida saab seejärel kasutada nagu tavalist failisüsteemi. Snapshoti tegemise eelduseks on, et samas voluumi grupis on piisavalt vaba kasutamata ruumi, st mida pole omistatud ühelegi loogilisele voluumile.

aix:~# lvcreate -L2G -s -n vm01_snapshot /dev/voluum/vm01

Tavaliselt on snapshoti moodustamise põhjuseks soov olemasoleva failisüsteemi seisuga mingi muudatus järgi proovida, näiteks tarkvara uuendamine ilma, et see töötavat süsteemi segaks. Sel juhul tuleb peale snapshoti moodustamist ta külge ühendada

aix:~# mount /dev/voluum/vm01_snapshot /mnt/vm01_snapshot

Snapshoti vabastamiseks tuleb esmalt ta lahti ühendada ja siis öelda

aix:~# lvremove /dev/voluum/vm01_snapshot

Snapshoti moodustamine kasutab mõni MB arvuti mälu, mis snapshoti eemaldamisel vabastatakse. Lisaks tuleb arvestada, et kui labelit kasutavast juurifailisüsteemist teha snapshot, siis on sama label kahel failisüsteemil ning operatsioonisüsteemi alglaadimine ei õnnestu sellises olukorras. Lahenduseks võiks olla snapshotile muu labeli omistamine öeldes

bash# e2label /dev/voluum/juurikas uuslabel

===LVM kolimine ühelt füüsiliselt kettalt teisele===

Kui soovida kolida juurpartitsiooni sisaldav LVM voluum teisele füüsilisele kettale või mdadm abil tehtud mirrorile, siis kõigepealt installeerime mdadm

apt-get install mdadm

Siin tuleks valida küsimusele vastuseks "all" devices

Järgnevalt teeme mirrori

debian:~# mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sdc2 missing

Ning kolime juurfailisüsteemi sisaldava voluumgrupi ümber /dev/md0

debian:~# lvm
lvm> vgextend juur /dev/md0
Volume group "juur" successfully extended
lvm> pvmove /dev/sda2 /dev/md0

Ootame, kuni move käsk lõpetab töö ja edasi:

lvm> vgreduce juur /dev/sda2
lvm> quit

Kui /dev/sda2 on täpselt sama suur, kui /dev/sdc2, siis soovitavalt peale rebooti saame panna sda2 lisaks md0 mirrorisse.

Antud kolimise näide peaks kehtima juhul, kui partitsioon, kuhu kolitakse on piisavalt suur, et mahutada kõik sellel kettal olevad Logical Volumed (lvm -> käsk pvs), samuti peaks see võimaldama kopeerida ka ainult üht ketast mitmest kettast koosnevate LVMide puhul. Mõistlik on sellist operatsiooni teha siiski eelnevalt kontrollides varukoopiate olemasolu ja cd-lt buutides.

===Veel toredaid programme===

Programm lvm töötab interaktiivses režiimis

aix:~# lvm
lvm> pvs
PV VG Fmt Attr PSize PFree
/dev/md0 voluum lvm2 a- 465.77G 167.77G

lvm> lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
kraam250 voluum -wi-ao 250.00G
vm01 voluum -wi-ao 16.00G
vm02 voluum -wi-ao 16.00G
vm03 voluum -wi-ao 16.00G

lvm> vgs
VG #PV #LV #SN Attr VSize VFree
voluum 1 4 0 wz--n- 465.77G 167.77G

lvm> lvscan
ACTIVE '/dev/voluum/vm01' [16.00 GB] inherit
ACTIVE '/dev/voluum/vm02' [16.00 GB] inherit
ACTIVE '/dev/voluum/vm03' [16.00 GB] inherit
ACTIVE '/dev/voluum/kraam250' [250.00 GB] inherit

lvm> vgscan
Reading all physical volumes. This may take a while...
Found volume group "voluum" using metadata type lvm2

lvm> pvscan
PV /dev/md0 VG voluum lvm2 [465.77 GB / 167.77 GB free]
Total: 1 [465.77 GB] / in use: 1 [465.77 GB] / in no VG: 0 [0 ]

===Voluumi ümbernimetamine===

Voluumi nime muutmiseks tuleb esmalt voluumi kasutamine lõpetada, nt vastav failisüsteem lahti ühendada ning märkida voluum mitte-aktiivseks ning seejärel näidata vana ja uus nimi

bash# lvchange -a n /dev/voluum/voluuminimi
bash# lvrename /dev/voluum/voluuminimi /dev/voluum/voluumi_uus_nimi

Seejärel märkida voluum uuesti aktiivseks ning kasutada tavapäraselt moel

bash# lvchange -a y /dev/voluum/voluumi_uus_nimi

===Märkused===

* loogilise voluumi moodustamisel saab määrata suurust LVMi jaoks kõige nö loomulikumates mõõtühikutes, extent'ides, nt kogu volume groupi suuruse logical volume tekitamiseks tuleb öelda

# lvcreate -l 100%VG -n voluuminimi grupinimi

* Tihtipeale ei ole LVM seadistusfailis /etc/lvm/lvm.conf tarvis muudatusi teha, aga seal saab juhtida filter direktiiviga, milliseid seadmeid LVM käsitleb võimaliku ressursina LVM moodustamiseks või nt kuivõrd LVM utiliitidega sooritatud tegevusi logitakse sh kuhu. Kusjuures, kui filter parameetrit muuta tuleb seejärel öelda 'vgscan', et LVM cache failis /etc/lvm/.cache uuendataks.
* Kõigi LVM volume grupi voluumide aktiivseks (või mitteaktiivseks) muutmiseks sobib öelda vastavalt

# vgchange -a y volumegrupinimi
# vgchange -a n volumegrupinimi

* Kui pvdislay ei näita seadmete nimekirjas oodatavat seadet, maksab küsida otse

# pvdisplay /dev/md0

* Voluumi grupi eemaldamisel kututatakse kõik grupis olevad voluumid

# vgremove data
Do you really want to remove volume group "data" containing 32 logical volumes? [y/n]: y
Logical volume "fs" successfully removed
Logical volume "moraal" successfully removed
Logical volume "cyrus_data" successfully removed
...
Volume group "data" successfully removed