Kuchařka BINDu, tipy, omezení DNS a co se jinam nevešlo.
BIND make it quick.
přeskoč a hezky pomalu
- BIND v9.2.2 .de mirror tu
- nakopnutí s chroot a BIND tu
- veřejný klíč ISC tu
- podpis BINDu tu
- PDF BIND v9 Administrator Reference Manual (A.R.M.) tu nebo se zdrojáky html
- Konfiguraci znáš, ne? Vážně ne? Tak zpomal.
přeskoč historii
Již Staří Římané potřebovali DNS. EHM. Pardon, no určitě by potřebovali,¨kdyby znali Internet a nevymysleli něco mnohem lepšího.
Před DNS byla tma. No to možná taky ne.
Na třetí pokus to snad vyjde. Já už pamatuji jen DNS, ale jedna legenda(rfc1034 kapitola 2.1;) říká, že dřív se k překladu adres a jmen na celém Internetu používal soubor HOSTS.TXT. Administrátor si dal kafe nebo čaj, stáhnul z nejmenovaného stroje z ftp HOSTS.TXT a uložil na místo, kde systém předpokládal jeho existenci. (? snad to bylo na unixech odjakživa /etc/hosts ?)
Když už těch kafí bylo víc a víc a za několik měsíců od upgradu na linku s vyšší kapacitou, při stahování HOSTS.TXT zase tak stejně, bylo dost času přemýšlet o tom, jak změnit a taky snížit výdaje NICu (správce HOSTS.TXT) i provozovatele toho kterého systému. Příčina rychlého nárůstu záznamů v HOSTS byla změna struktury připojených sítí do internetu, kde se místo terminálů a sdílených strojů stále častěji objevovali jednouživatelské pracovní stanice.
Dalším nedostatkem, kromě rostoucí velikosti, byla přílišná centralizovanost této služby. Změnu v HOSTS musel provést NIC, požadovat změnu u NIC pro existující doménu taky nemohl každý, a kdo ví jaká další organizační (interní) omezení měly jednotlivé připojené sítě. A když už se záznam dostal do HOSTS.TXT, zbývalo jen čekat, než se rozkopíruje na potřebná místa.
Dál se ještě legenda zmiňuje o stále chytřejších programech, které vytvořily poptávku po dostatečně obecné službe dotazovatelné jménem. Zde zbývá prostor pro další spekulace, zda jde o USENET a MTA. (historikové prosím upřesněte)
přeskoč požadavky
A protože kafí bylo víc než dost a s rostoucím množstvím připojených uživatelů čím dál častěji, napadalo lidi, co vše je třeba vyřešit: (rfc1034 kapitola 2.2)
- jmenný prostor nezávislý na topologii sítě, tedy stejný pro libovolného účastníka
- distribuovaný návrh systému, který
- přesouvá většinu změn a rozhodování o updatech a aktuálnosti dat v cache směrem k vlastníkovi jména (provozovteli DNS serveru),
- není ovlivněn funkcí špatně nastavených nepotřebných částí
- a obsahuje různé typy dat, použitelné různými programy,
- rozlišuje různé třídy dat podle protokolu kterého se týkají,
- příliš nevynucuje, zda používat datagramy (UDP) nebo virtuální okruhy (TCP).
přeskoč jmenný prostor, RR, RR-Set, resolver a server až k druhům serverů
Výsledný systém má dodnes 3 základní části: (rfc1034 2.4., rfcFIXME(rrset))
- První částí je provázaná skupina: Jména a jejich data (RR a RR-Set).
přeskoč jména, RR a RR-Set k resolveru
Tedy jména, RR a RR-Set tvoří první část.
Zde bych si dovolil malou odbočku a poprosil čtenáře o zapamatování si několika typů dat, které budou ještě často zmíněny před samotným popisem všech nejčastějších typů:
- SOA - typ záznamu, který označuje, jak aktuální jsou data. Aktuálnost několika úrovní:
- hodnota SERIAL - číslo konfigurace zóny,
- a ostatní hodnoty, které nastavují doby, do kdy nejvíš jsou data platná v sekundárním serveru a od kdy už by se měl snažit získat nová data.
- NS - Typ který udává jméno autority (autoritativního serveru). Toho, kdo rozhoduje o hodnotách dat k části jmen.
- AXFR a IXFR - Speciální typy které mohou být pouze v otázce. Nemjí žádná data a jediná informace kterou nesou je jejich přítomnost v dotazu. Vynucují si přenos všech dat ze serveru nebo u IXFR jen části nových. Takovým přenosům se pak říká stejně jako typům, které je vyvolaly.
- Druhá část je "resolver".
přeskoč resolvery
Je to ten, kdo se ptá a tvoří uživateli/programu rozhranní pro získání dat z DNS.
přeskoč nastavení GLibC a DNS resolveru k různým druhům resolverů
V glibc může být takový DNS resolver volitelně, jako rozšíření. Pokud máte glibc(libc6) řady 2.2, můžete si přímo spuštěním /lib/libc* zjistit, jakou verzi resolveru používáte. Př.:
Available extensions:
BIND-8.2.3-T5B
Rozhranním pro program jsou obecnější funkce gethostbyname a gethostbyaddr, které mohou používat více dotazovacích mechanismů.
Funkce DNS resolveru najdete v man 3 resolv. Jestli se použije právě DNS při zavolání gethostby* ovlivní nastavení v /etc/nsswitch.conf. Pro networks a hosts hodnota dns, případně podmíněná nebo kombinovaná s další službou.
Knihovna obecného resolveru se dá najít pod jménem /lib/libnsl*.
Zatím co DNS resolver pod /lib/libnss_dns*.
Pokud nemáte rádi DNS nebo nevyhovuje správě sítě, můžete nechat glibc, ať třeba používá netbios jména stejně jako samba. Použijete k tomu jinou knihovnu (resolver) a to třeba /lib/libnss_winbind*.
U jiných verzí libc mohou být soubory /lib/libns* linkované a uložené přímo v /lib/libc*, proto nepanikařte. ;)
Další chování resolveru ovlivní soubory:
- /etc/resolv.conf
- /etc/host.conf
Zde trochu splývá co ovlivní pouze DNS resolver a co ovlivní glibc a zpracování odpovědí z konkrétního resolveru. Můj první odhad říká, že resolv.conf nastavuje DNS resolver, kdežto host.conf ovlivní chování glibc a tudíž nejen DNS resolver.
man 5 nsswitch.conf
man 5 resolv.conf
man 5 host.conf
A jaké různé resolvery jsou?
přeskoč k serveru
- Tak prvně ten, který umí pracovat ve všech definovaných stavech, aby se dopracoval k odpovědi. Označuje se prostě resolver.
- A light verze, která dokáže pracovat správně jen pokud na otázku dostane co nejůplnější odpověď. Označuje se stub resolver.
Rozdíl plyne z protokolu a je vidět v hlavičce dns zprávy, kde stub resolver pošle otázku s nastaveným bitem,
RD - recursion desired, požadovaná rekurse
a dokáže korektně pracovat jen s odpovědí která (obvykle) má nastavený bit,
RA - recursion availaible, rekurse k dispozici a neobsahuje pouze odkaz, kde se ptát na přesnější informace.
- A nakonec poslední část DNS.
přeskoč k druhům serverů
Někdo kdo má data asociovaná se jmény a je ochoten je poskytnout dál, obsloužit třeba právě resolver, který se táže na data ke jménu. Tedy poslední část DNS je server.
přeskoč všechny servery k zóně
přeskoč neautoritativní servery
Jaké servery existují? To je závislé od různých funkcí nad různými daty. Tak snad nejdřív jaká data můžeme mít. (rfc1035 kapitola 2.1 odstavec 4)
- Data v cache, o kterých jediné co můžeme říct je, že existují, neexistují (rfc2308) po nějakou dobu nebo nevíme, nepamatujeme si, že by jsme nedávno viděli taková data a nenáleží nám rozhodovací pravomoc nad dotazovanou částí jmeného prostoru.
- Dál se dá o datech (zóně) říct, kde je získat. Část jmenného prostoru, přiřazená a nepřiřzená data. O tom je někdo oprávněn rozhodnout (je Autoritou), skupina autoritativních serverů.
z BIND v9 A.R.M. kapitoly 1.4.5.
Tedy servery podle dat, nad kterými pracují, se dají rozdělit na cache, kombinované s cache a ty ostatní. Cache zachytává průchozí data a odpovídá na otázky, ke kterým má platná data. V protokolu takovou odpověď z cache můžete odhalit v hlavičce pomocí NEnastaveného (nastaveného na 0) bitu,
AA - authoritative answer, (ne)autoritativní odpověď.
Zde je snad vhodné místo pro forward nastavení, při kterém požadavky můžeme "nakopnout" směrem do velké cache nebo DNS-gateway. Cache "na pomezí", pokud nemáme cestu do Internetu, ale jen DNS-gateway a http/ftp/... gateway.
z BIND v9 A.R.M. kapitola 1.4.5.1.
Podle další funkce, již popsané jako podmínka fungování stub resolverů, se dají dělit na:
- rekursivní (případně nejčastěji rekursivní jen pro některé klienty)
- a nerekursivní.
Rekursivní se snaží sezbírat co nejůplnější odpověď za klienta a tu mu následně předat.
A na autoritativní servery,
přeskoč je na roztřízení
z rfc1996 kapitoly 2.1. a taky BIND v9 A.R.M. kapitoly 1.4.4.
Podle vlastnictví/získávání, předávání dat a viditelnosti jejich autority pro zóny:
- Master je libovolný server, který vystupuje jako zdroj při přenosech zóny (AXFR a IXFR) na sekundární (slave) servery. Sekundární server může působit jako master pro další sekundární server, který z něj získá data.
- Primární Master by měl být jen jeden. Má zóny přímo od administrátora nebo administračního mechanismu DNS Update (rfc2136), či Secure DNS Dynamic Update (rfc3007). Obvykle si drží kopii na disku v čitelné formě. V případu BINDv9 a dynamických změn je zóna (data) v aktuálnější verzi než čitelné soubory v "nečitelném" žurnálu. Občas zapsaném na disk a v paměti pro okamžité odpovězení.
Kdo je primární server je definováno v konfiguračních souborech polem MNAME v typu SOA.
- Sekundární/Slave servery si získávají data z Master serveru mechanismem:
AXFR a IXFR - králíci z klobouku.
- query s typem AXFR přenese celou jednu zónu nebo
- query s typem IXFR (rfc1995) přenese posledních několik změn v jedné zóně.
Přibližně jako patch, kde navíc kontrolu co patchovat na co, zajistí data typu SOA a hodnota v poli SERIAL.
Tato data si získají "svévolně" (po vypršení doby uvedené v SOA), nebo když uslyší na DNS Notify (rfc1996).
Proč králíci z klobouku? ;) No AXFR, Bob, ten starší vždy vstává první a to je první kopírování dat na slave server. A ten mladší, menší a línější IXFR, Bobek, se nikdy nepředře a nekdy jenom práci načne a dodělat ji musí Bob.
- Neregistrovaný (stealth) server je druh serveru, který není zmíněn v odpovědích ve skupině autoritativních nameserverů, přestože jím pro nastavené resolvery a servery je.
Ptáte se: "Kam zařadit autoritativní server?"
mám v tom jasno skáču na zónu
a nebo rovnou na protokol
- Z pohledu dat v přenosu IXFR, AXFR, Notify:
- Master - zdroj dat.
- Slave - ten kdo získává data.
Snad jen pozor na firewall na cestě, proto ještě master a slave z pohledu iniciátora spojení:
- U query typu AXFR a IXFR se ptá slave, jestli master nemá nová data.
- U notify se master ptá:"Už máš tyto data?", a snaží se je podsunout slave-ovi. Případně slave po čase začne AXFR/IXFR.
- Z pohledu vlastnictví nastavení zóny. Přesnější definice jako kořen AXFR a IXFR přenosů.
- Primary - originál.
- Secondary - kdo ví kolikátá kopie.
V případě "lab.fi.muni.cz." bude muset mít každá skupina vlastní primární server, což nemusí být žádná chyba. Ovšem v momentě, kdy budeme chtít zprovoznit dynamický update zón, mohou nastat (nastanou) komplikace. Převážně u několikátého update v pořadí s prerkvizitami a s tím, že některý primární server mohl být u dřívějšího update nedostupný. Pokud jako komplikaci ignorujeme fakt, kdy updaty s prerekvizitami provedené v krátkém časovém úseku se mohou na lince předběhnout a neprovést se. Tedy i v případě dostupných více primárních serverů bude komplikovné udržet konzistentní zóny.
- Z pohledu viditelnosti jako autority zóny.
- Stealth - nesmí se objevit v odpovědi z non-stealth serveru v sekci autorit.
- non-stealth - ti ostatní
Co to asi tak je ta zóna?
to vím naprosto přesně, tak raději skáču na protokol
Kolikrát zde padlo slovo zóna? Čemu někdo říká zóna? Snad uvedu na správnou míru příkladem ZÓNY:
Pro příklad si vezmeme snad se dá říct "realitu". Celý jmenný prostor začínající "." (root servery), který se dál rozpadá na jednotlivé domény.
.
/c c\
/ z o \
/ m \
/ \
Mějme podstrom "muni.cz.", který pro tento příklad patří do správy ÚVT MU.
.
m
u
n
i
.
/ \
/f a i\
/ i s c \
/ c s \
/ s \
A domény "fi.muni.cz." patřící do správy CVT FIMU a "ascs.muni.cz." patřící do správy ASCS. Nakonec "ics.muni.cz." stále ještě ve správě ÚVT MU.
Pak zóna ve správě CVT je doména "fi.muni.cz." a její RR a obsahuje úplný podstrom. Podobně bude vypadat zóna Spolku Informatiků "ascs.muni.cz.".
Ale zóna ve správě ÚVT v tomto příkladě obsahuje RR domény "ics.muni.cz." a informace z muni.cz.
Tedy zóna je myšlena jako záznamy(RR) z podstromu od nějakého kořene bez vnořených zón, o které se stará někdo jiný.
Pseudo rovnice popisující zónu pod ÚVT by vypadala přibližně:
zone("muni.cz.")= RRs(domain("muni.cz.")) -
- RRs(domain("fi.muni.cz.")) -
- RRs(domain("ascs.muni.cz."))
Zóny si správce může libovolně rozsekat na více zón pro zpřehlednění. V BIND v9 pro přehlednost používejte raději $INCLUDE. Ale spíš je rozumější rozdělit zóny, pokud chceme kontrolovat velikost AXFR nebo chceme různé časy v SOA.
přeskoč k BINDu
Pro úplnost hlavičku dns zprávy: (rfc1035 kapitola 4.1.1.)
takže se nic moc nestane, když ji přeskočím na mechanismy nebo taky druhy zpráv v DNS
- ID - náhodné číslo, aby si resolver dokázal snadno spojit do páru
otázka 1 - odpověď 1 a
otázka 2 - odpověď 2,
když pošle obě otázky stejnému serveru dřív, než dorazí odpověd 1 nebo odpověď 2.
- QR - bit určující zda jde o otázku či odpověď.
- OpCode - číslo udávající druh zprávy a následně odlišný význam zbytku zprávy.
- AA - autoritativní odpověď,
- TC - useknutá udp zpráva (nevešly se všechny data do odpovědi),
- RD - požadovaná rekurse,
- RA - poskytovaná rekurse,
- Z - 3 bity 0, později přidán význam u podepsaných odpovědí a cachování podepsaných odpovědí,
- RCODE - hodnota označujíci druh chyby serveru.
---dál neplatí pro všechny OpCode stejný význam, ale nejčastěji---
- QDCOUNT - počet RR v otázce,
- ANCOUNT - počet RR v odpovědi,
- NSCOUNT - počet RR typu NS (autoritativní nameserver) ve výčtu autoritativních serverů nebo taky jeden SOA záznam.
- ARCOUNT - dodatečné RR. Předbíhání odpovědi před otázkou, kdy se předpokládá, že by se mohl resolver zeptat například na RR typu A pro libovolný uvedený NS, tak tuto odpověď dostane ještě dřív, než se zeptá.
Druhy zpráv a s nimi související mechanismy,
přeskoč na třídy dat
které se mohou objevit, se poznají podle 4bitů OpCode v hlavičce.
- Status - rfc1034 uvádí existenci této hodnoty opcode, ale místo definice zbytku zprávy a účelu rychle končí slovem (Experimental) a větou: "To be defined." Nejspíš nejde o zprávy, které používá rndc k ovládání BINDu, možná ano. Pouze spekulace.
- Notify - Oznámení o změně v zóně přijde vhod v situaci, kdy v SOA je dlouhý čas pro refresh (dobu kdy se má pokusit sekundární server o přenos zóny z primárního/jiného master serveru) a přesto je požadovaná dostatečně rychlá změna údajů v sekundárních serverech při změně a přitom nežádoucí časté dotazování se na změny u primárního/jiných master serverů.
Rfc1996 vyžaduje stromovitou strukturu, tedy bez cyklů, do které jsou uspořádány master/slave servery s kořenem primary master. Dál definuje Notify Set. Skupinu serverů, která má dostat oznámení.
V BIND v9 je tato vlastnost použita k oznámení změny zóny pomocí SOA. Notify otázka obsahuje novou SOA primary, či master serveru, který se ptá při změně v zóně všech autoritativních serverů. Ptá se jich: "Mám takovéhle SOA.SERIAL a co ty už máš nová data?" Přidat stealth servery do oznámení můžete podle "BIND v9 A.R.M. 6.2.14.6." pomocí "also-notify" v kontextu "options". Př: also-notify { 1.2.3.4; 2.3.4.5 port 456};
Pochopitelně BIND nic neoznamuje primárnímu serveru, protože jde o iniciátora notify zpráv.
Notify samotný je o něco obecnější mechanismus, kdy se mohou poslat jakékoliv změněné RR v části odpovědí už při otázce na aktuálnost dat. Tedy po změně zóny "fi.muni.cz." přidáním RR(aisa.fi.muni.cz.,A,IN,5678,1.2.3.4) a RR(fi.muni.cz.,SOA,IN,5678,serial,..refresh,..), múže být oznámené obojí a předejde se IXFR nebo AXFR. Tato vlastnost je nejspíš zatím jen v rfc a zdá se, že není k dispozici v BINDU (teda podle neověřené zmínky z A.R.M.).
Přednostně má být pro notify použito UDP, s vyjímkou, že master (zdroj dat, tedy zdroj oznámení) je nastaven na TCP, kvůli firewallu na cestě nebo se data nevlezou do jedné UDP zprávy. Notify "otázka" z mastera se pošle právě jednou do vypršení času, ve kterém se předpokládá přijetí notify odpověďi.
- Update - umožňuje lépe programově řešené změny zóny.
Příkladem může být provozování DNS služby spolu s nmbd/wins/winbind (součást samby). S tím, že změny jmen na sambě prováděné správci jednotlivých stanic, mění rovněž jména v DNS. Pokud ovšem používají rozšíření wins, kterým informují o změně netbios jména příslušný wins/winbind server, který se při složitější topologii nemusí o změně vůbec dozvědět, pokud ho přímo klient neinformuje. WinS potom provede update DNS. V případě samby 2.2.5 půjde o přepínač wins_hook, který může zavolat k sambě přiložený ukázkový skript, a ten zavolá program nsupdate z BINDu, který vygeneruje a odešle update požadavek. Tento wins_hook zavádí parametr "operation", jehož funkce je někdy i zavádějící, protože ve skutečnosti se provede právě to, co dostane nsupdate.
Rfc2136 definuje ekvivalenci RR, operace nad RR-Set, také typy které v principu nemohou tvořit RR-Set, proto jejich update nebude doplnění RR do RR-Setu, ale půjde o změnu původního záznamu. Dál definuje formát zprávy, kde kromě hlavičky a zóny ke změně nechává místo pro "prerekvisity", podmínky, které musí platit bez vyjímky, aby se mohl uskutečnit update popsaný nasledující částí zprávy.
- Inverse Query (IQuery) - prohlášena za překonanou (OBSOLETED). Strukturou totožná s následující Query, jen význam je opačný. Otázka spočívá v poslání dat v části odpovědi, ke kterým chce najít všechny otázky pro dotazovaný server, které způsobí odpověď s daty na která se ptáme v části odpovědi.
- Query (Standard Query/ stdquery) - nejčastější DNS provoz. Tento typ dotazů používají hlavně resolvery k dotazování serverů a servery v nich odpovídají daty. Stejně je tato zpráva použita také k IXFR a AXFR. Za hlavičkou je část s otázkami, následují odpovědi, potom seznam autorit a také odpovědi na ještě nevyřčené otázky. U IXFR se do seznamu autorit už při dotazu napíše SOA s SERIAL číslem od kterého po nejaktuálnější chceme získat záznamy.
Vysvětlení AXFR a IXFR se zatoulalo kousek víš.
Tak teď už ke konkrétním třídám.
přeskoč na typy dat
Jak bylo řečeno, návrh DNS předpokládal uchovávání dat pro více protokolů, proto vznikly třídy.
Pro účely nastavování serveru si stačí pamatovat IN jako Internet a zbytek zapomenout. A navíc dig od jisté verze odmítá používat při dotazech třídu ANY.
Ještě poznámka, BIND v9 má IN jako implicitní třídu, a nemusí se uvádět, takže třídy můžete s klidným svědomím zapomět.
No a konečně několik nejobvyklejších základních typů dat,,
přeskoč k nastavení serveru
bez kterých se nejspíš neobejdete, ale zároveň s nimi vystačíte nad IPv4:
- A jako Adresa udává IPv4 adresu ke jménu s kterým je spojená.
Př: aisa.fi.muni.cz. 86400 IN A 147.251.48.1 říká přibližně: "aisa... má IPv4 adresu..."
- NS jako Name Server. Říká, "Strom od kořene "jméno" má autoritativní server "jména"."
Př: fi.muni.cz. 86400 IN NS anxur.fi.muni.cz., říká přibližně: "fi... má nameserver anxur..."
- CNAME jako Canonical NAME je jako alias. Říká, "Nemám další data, ale ptej se tady."
Př: www.fi.muni.cz. 86400 IN CNAME aisa.fi.muni.cz., říká přibližně: "Data k www.fi... hledej pod aisa..."
- SOA jako Start Of Authority. Obsahuje informace společné pro zónu.
- Jméno primárního serveru, který má originální konfiguraci.
- Mailbox, kde se zkusit zeptat, pokud chcem do zóny přidat data nebo kam posílat stížnosti na nastavení zóny, atd.
- SERIAL - číslo verze zóny. Označení aktuálnosti dat.
a dál časy v sekundách:
- REFRESH - Za jak dlouho se sekundární zeptá na změny.
- RETRY - Za jak dlouho opakovat REFRESH v případě neůspěchu.
- EXPIRE - Kdy budou data prohlášena za neplatná a bude asi lepší nemít žádná data, než potenciálně špatná data.
- MINIMUM - Nejkratší povolená životnost libovolných dalších dat z této zóny. Jedna z funkcí je životnost při negative caching, tedy data o kterých můžeme říct, že určitě nejsou (typicky chybné jméno asdf.muni.cz. a odpověď s chybovým kódem RCODE=NXDOMAIN). Říká po jakou dobu si cache může dovolit tvrdit, že jméno asdf.muni.cz. neexistuje a vracet z cache odpovědi s chybou NXDOMAIN. dig asdf.muni.cz. any - 3600 vteřin.
př: fi.muni.cz. 86400 IN SOA anxur.fi.muni.cz. root.fi.muni.cz. 2003030602 10800 900 1209600 86400, říká přibližně: "fi... má primární server anxur..., dotazy posílejte rootovi@fi..., verze dat je 2003030602 (asi druhá úprava z 6. března 2003), sekundární servery si mají ověřovat, jestli nejsou nová data, po uplynutí 10800 od zjištění, že jsou nebo nejsou nová data. Pokud se jim nepodaří zjistit (ne)existenci nových dat, tak to mají zkusit po 900 vteřinách. Data budou platná nejdéle po dobu 1209600 vteřin od tohoto zjištění a data zóny platí nejmíň 86400 vteřin.
- PTR jako PoinTeR. Zavedený kvuli tomu, aby doplnil funkci, kterou DNS samo od sebe rozumě neumí a hosts.txt uměl. A to konkrétně přiřadit číselné adrese jméno. Skrývá se pod přiřazením speciální jméno - jméno.
Př: 1.48.251.147.in-addr.arpa. 86400 IN PTR aisa.fi.muni.cz.
- MX jako Mail eXchange. Obsahuje informaci o tom, kdo zpracuje poštu. Záznam tvoří číslo udávající prioritu mail serveru a jméno samotného serveru.
Př: aisa.fi.muni.cz. 86400 IN MX 50 relay.muni.cz.
Seznam všech přidělených/definovaných typů najdete na www.iana.org./assignments/dns-parameters a popis v odkazovaných rfc nebo taky v BIND v9 A.R.M.
BIND mě nezajímá skáču na kuchařku, tipy, trable a omezení DNS.
přeskoč na konfigurák zóny
jaký jsou ty typy dat pro zónu?
co že tu bylo a named.conf?
čím se dají kontrolovat konfigy?
Jde o produkt Internet Software Consorcia a stáhnout se dá z http://www.isc.org./products/BIND/bind9.html
Na stránce ISC se taky dozvíte o součsných známých ještě neodstraněných problémech na jednotlivých platformách a kombinacích nastavení. Dál taky o vlastnostech a minmálních verzích jiných knihoven (OpenSSL). Nepřehlédněte rovněž odkaz na PDF verzi dokumentu BIND v9 Administrator Reference Manual - velmi užitečné čtení, mimo jiné v html verzi je součástí tgz blíku se zdrojovým kódem. Najít se dá v ./doc/arm/
Minimální nastavení nezávislé na distribuci spočívá v:
- vytvoření konfiguračního souboru jeho kontrola s named-checkconf,
- případně souborů zón a jejich kontroly s named-checkzone,
- spuštení named s příslušnými parametry,
- ukončení named signálem SIGTERM nebo SIGINT,
- nebo znovu načtení konfigurace po signálu SIGHUP,
- případně ovládání běžícího BINDa programem rndc, pokud je k tomu nastavený.
Jak vypadá konfigurace zóny.
přeskoč na named.conf
Možná jste si všimli, že už v předchozí části, se v textu povalovaly řádky z programu dig ve formátu použitelném pro nastavení BINDu. Vlastně všechny příklady u typů dat by snad měly jít bez úpravy použít v konfiguračním souboru zóny začínající kořenem "fi.muni.cz." (až na PTR).
Pamatujete si doufám, co všechno může být zóna?
Naváži tedy několika $-direktivami, které se vyskytují v nastavení zóny.
- $ORIGIN - říká, jak se mají doplnit následující neůplná jména na FQDN (full qualified domain name). Prostě pokud není jméno ukončeno tečkou (nemá na konci root domain), tak čím se má doplnit na FQDN. Pokud se chcete zasmát, a podívat se, proč je dobré používat ORIGIN, a jak vypadá reversní záznam IPv6, tak se podívejte na kapitoly 4.8.3 a 4.8.4 z BIND v9 A.R.M.
Pro jistotu: "Nezapomínejte na tečku na konci jména u ORIGIN!" A naučte se ho běžně používat, protože šetří psaní a snad i vám zkrátí kontroly zón. Dokud neuvedete ORIGIN bude se brát implicitní hodnota $ORIGIN zone-name. Zde trochu předběhnu a vysvětlím, co je zone-name. Jde o hodnotu, která je v hlavním konfigurčním souboru a říká, že se server stará o zónu: zone "muni.cz." { ... type master; file "./zone-muni"; }; a zone-name je právě to muni.cz.
- $INCLUDE - zóna může být pro přehlednost rozsekána na více souborů, a přsto z pohledu AXFR/IXFR (SOA) tvořit jednu souvislou zónu. INCLUDE říká, jaký další soubor obsahuje část zóny. Můžeme vkládat více souborů a navíc každý z nich může mít svůj vlastní ORIGIN, který platí jen a pouze pro něj.
Gramatika include je následující: $INCLUDE <file-name> [<domain-name>] [<comment>]
Př. souboru zone-muni:
$ORIGIN muni.cz. #nebo vypustit a použije se implicitní hodnota
...
ns A 147.251.4.33
...
$INCLUDE ./zone-muni-part-ics
...
ns1 A 147.251.6.10
...
doplní se na ns.muni.cz. a ns1.muni.cz. přestože je vložen soubor s direktivou ORIGIN
př. souboru zone-muni-part-ics:
$ORIGIN ics.muni.cz.
...
www CNAME dior
dior A 147.251.6.10
...
- $TTL - hodnota TTL která se má přiřadit záznamům, které nemají uvedenu žádnou TTL
- $GENERATE - generování čísel z rozsahu... nenapadá mě k čemu ji použít v nastavení v semináři.
Pokud si chcete zkrátit psaní, tak až budete psát lab.fi.muni.cz., můžete využít možnosti neuvést vlastníka (asociované jméno) dat s tím, že BIND použije předchozí. A ještě dřív zmíněný ORIGIN a TTL, pak tedy místo:
fi.muni.cz. 86400 IN SOA
anxur.fi.muni.cz. root.fi.muni.cz. 2003030700 10800 900 1209600 86400
aisa.fi.muni.cz. 86400 IN A 147.251.48.1
aisa.fi.muni.cz. 86400 IN MX 50 relay.muni.cz.
aisa.fi.muni.cz. 86400 IN MX 500 adis.cesnet.cz.
Můžete psát:
$TTL 86400
$ORIGIN fi.muni.cz. ;nebo využít implicitní hodnoty ORIGINu
@ SOA anxur root 2003030700 10800 900 1209600 86400
aisa A 147.251.48.1
MX 50 relay.muni.cz.
MX 500 adis.cesnet.cz.
@ je jméno které je v momentě použití v $ORIGIN
* - žolík(wildcard). Zástupný znak za všechny možné "labely". Čeho se pak vyvarovat nebo nebýt překvapení z, při vícenásobném užití * a jmen, která nejsou v FQDN najdete v rfcFIXME(???)
() můžete použít k seskupení dat roztahaných po více řádcích.
Jak vypadal konfigurák zóny se můžete kouknout v rfc1035 kapitola 5. s příkladem v 5.3. a přesvědčit se, že se dodnes příliš nezměnil.
named.conf
přeskoč na kontrolu konfigů
Tak to by byla zóna primárního serveru, která má svůj kořen. No, ale říkáte si: "Jak BIND ví, pro jaké zóny je autoritativní server? Jestli je primární nebo sekundární? Jestli jako sekundární má umožnit přenosy zóny dál a být pro někoho masterem?" To všechno a ještě mnohem víc rozhoduje obvykle soubor named.conf
Místo vysvětlování syntaxe named.conf vás odkážu na kapitolu 3.1. BIND v9 A.R.M., která uvádí ukázková nastavení. Spolu s tím co jsem psal o protokolu bude snad intuitivně jasné, co který pepínač znamená.
Nastavení forwardování najdete v 6.2.14.2 BIND v9 A.R.M. Nepřehlédněte zmínku o slově only, které mírně pozmění chování, tak aby odpovídalo poslední větě kontroly Úkolu. Obojí patří pod options {}; jak se můžete dozvědět v kapitole 6.2.13.
A pokud vážně chcete používat BIND a nastavit jej pořádně, tak přeji příjemné čtení kapitoly 6. a co nejméně rozbitých klávesnic s okomentovnou gramatikou.
kde je chyba v konfiguráku?
přeskoč na kuchařku, tipy, trable a omezení DNS.
Při odstraňování chyb v nastavení zóny na primárním serveru může pomoci program named-checkzone. Pro naši fiktivní zónu kořene muni.cz. která bude uložená v /var/lib/named/zone-muni se bude spouštět příkazem
named-checkzone muni.cz. /var/lib/named/zone-fi
Pro kontrolu souboru named.conf může posloužit program named-checkconf, který pro bind spouštěný příkazem named -c /named.conf -t /var/lib/named/ ..., tedy pro konfigurační soubor /var/lib/named/named.conf a chrootovný BIND se změněným kořenem uvnitř /var/lib/named/ se bude spouštět příkazem
named-checkconf -t /var/lib/named/ /named.conf
Poslední perličkou je program rndc-confgen. Podle parametrů sestaví konfigurák pro rndc a na konec napíše i zakomentované ukázky, kde co povolí funkci rndc v named.conf, aby jste mohli používat rndc k ovládání BINDu. Stačí zkopírovat poslední část do named.conf, změnit ACL u allow {} uvnitř controls {}, odkomentovat a být schopen udržet tajemství.
- Chroot BIND v9:
- Část 7.2. BIND v9 A.R.M. je téměř povinná četba a docela kratičká.
Obsahuje seznam všech možných souborů, a přepínačů které mohou
mít přímý vliv na funkci serveru (umístnění souborů), výrazné
zhoršení šancí na úspěšný útok známý jako "cache poisoning"
(pokud ovšem server skutečně provádí sledování spojení a posledním
tenkým místem je málo náhodné ID v hlavičce), a logování
a správné časy v logu. Jak spustit chroot BIND a co nezapomět
před prvním startem.
- Jinak ještě se teď mihlo na .cz.comp.linux
ftp.linux.cz./pub/users/kas/bind-chroot/ (9.2.1-1)
Balíček obsahující místa kam co přijde. Snad jen upozornění, od autora,
že v systému musí již být přítomna skupina named a ode mě, pokud
máte čas v UTC, tak chybí nakopnutí, kam dát soubor s popisem
lokalní časové zóny, aby došlo ke správným překladům.
- forwardování se vešlo sem
- Pokud se někomu povede zadat SERIAL v SOA do budoucnosti a bude chtít čísla
ze současnosti, tak důsledek definice sequence space aritmetic a celý návod
jak se dostat do současnosti je k dispozici v 8.2. BIND v9 A.R.M.
- Délka labelu, tak jak je vidět v konfiguráku, je maximálně 62 znaků, je to
dáno omezením v paketu, kde se navíc jako 63-tí počítá 8bitů, kde horní 2 udávají
typ labelu (koukni dál na rozepsaná syrová data v paketu z tcpdump) nebo dolních 6 udává
délku. A navíc se počítá se zarovnáním na 64 znaků a že interně v serveru může
být label reprezentován jako řetězec ukončený "NULL" obsahující i úvodní záznam,
aby to šlo přímo zkopírovat do odchozího paketu.
(typ+len)1 + 62 + 1(možný null) je pěkné kulaté číslo.
- Délka celého jména je maximálně 255 znaků a do toho se počítají i ty ůdaje
o typu labelu a jeho délce. Nezapomínejte na koncovou/počáteční "." která
se počítá jako "label typu 0 délky 0" čili těch 8bitů sice nulových,
ale přítomných.
- S tím (root domain ".") souvisí proč nesmíte mít ve jméně ".."
ta druhá tečka(pokud je root-domain vpravo ve jméně) by po přečtení asi označovala
prázdný label, tedy právě root-domain, ale uprostřed jména.
V paketu by to znamenalo, na některých místech problém
(kdekoliv mimo RDATA), který předčasně ukončí jméno a rozhodí zbytek
paketu a v RDATA by vznikl problém dvojí interpretace.
- Pokud si budete chtít přečíst syrová(raw) data z tcpdump -w /tmp/file
která putují ze serveru, tak si asi moc nepočtete, protože u jména, které
má suffix (tedy pokud je root-domain vpravo, jinak pokud jste zvyklí na jména
.cz.muni.fi.aisa, tak to bude prefix i když v paketu jde skutečně o suffix,
aby se ušetřil byte s počtem labelu nebo delkou jména je tato informace
implicitně kódována jako počátek jména určený logickou strukturou paketu
(okolím jména) a ukončené je pomocí labelu root-domain tedy ve jméně jediné hodnoty
"0"(2bity typ labelu - 0, 6bitů délka labelu - 0)). No tedy u jména které
má suffix shodný jako už použité jméno nekdy dřív bude nejdelší možný suffix
povině nahrazen 16bity (2bity typ labelu ukazatel v paketu, 14bitu pozice)
říkajícími kde najít zbytek jména.
př: nečitelnou se stává už i odpověď co dostává resolver
který se ptal dejme tomu na A záznam aisa.fi.muni.cz.
V odpovědi bude zkopírovaná otázka beze změny, tedy hlavička
s 1RR v otázce, 1RR v odpovědi, 3RR autorit, 2RR relevantních dat.
- QRR(1): bude obsahovat celé jméno "(4)aisa(2)fi(4)muni(2)cz(0)"
- RR(2): už jen odkaz, protož nejdelší prefix je celé jméno
(typ ptr tedy 3 v prvním oktetu v nejvyšších 2bitech
a pozice 12 v paketu následujících 14 bitech
(proč 12? ukazatele se počítají od začátku dns dat v paketu
těmi je hlavička a ta má pevnou délku 12 oktetů(12x8bitů)
po hlavičce v Query následuje sekce otázky která obsahuje
redukovaný QRR a RR začíná ihned jménem ke kterému jsou
následující data přiřazena))
- RR(3): autorita bude nad "fi.muni.cz.", což bude zase místo jména
ukazatel podobně jako v předchozím případě
a první autorita bude mít jako data při troše štěstí anxur.fi.muni.cz.
tedy v tomto paketu na tomto místě bude vypadat jako
(5)anxur (PTR 3, zbylé bity = ?? zkuste si dopočítat
nebo dohledat, jestli jsem se nespletl, tak to bude 17)
- atd.
- A ještě odměna pro pečlivé a chápající čtenáře, kteří se prokousli až sem.
Pokud chcete ušetřit polovinu psaní s nastavováním lab.fi.muni.cz.,
tak mám pro vás několik kouzelných slov.
dig, přenos celé zóny, paste
- Obrácené pořadí čísel v in in-addr.arpa. Tedy pro aisu s adresou
aisa.fi.muni.cz. 86400 IN A 147.251.48.1
je reverzní záznam ve tvaru
1.48.251.147.in-addr.arpa. 86400 IN PTR aisa.fi.muni.cz.
- Pokud náhodou máte povolený dynamický update a chcete přidat ručně záznam
do zóny v BIND v9, tak si nejprve přečtěte 4.1.1. kde se dozvíte co udělat,
aby se taková změna provedla.