djbdns
(→Zónafájl-formátum: 2008-as átdolgozás, v2) |
(→A djbdns hátrányai: átdolgozás 2008) |
||
210. sor: | 210. sor: | ||
* Gyakorlatilag lehetetlen egy IP-n futtatni a cache-t és az autoritatív szervert (bár BIND esetében se ajánlott) |
* Gyakorlatilag lehetetlen egy IP-n futtatni a cache-t és az autoritatív szervert (bár BIND esetében se ajánlott) |
||
* Körülményes a BIND-szerűségeket futtató secondaryk támogatása (pl. nincs beépített lehetőség arra, hogy NOTIFY-t küldjünk, külső scripttel kell) |
* Körülményes a BIND-szerűségeket futtató secondaryk támogatása (pl. nincs beépített lehetőség arra, hogy NOTIFY-t küldjünk, külső scripttel kell) |
||
− | * Nem szabad szoftver (nem terjeszthető) |
+ | * <s><del>Nem szabad szoftver (nem terjeszthető)</del></s> (néhány hónapja a public domainbe helyezte a szerző) |
* Nincs IPv6-támogatás (egyelőre nem túl fontos) |
* Nincs IPv6-támogatás (egyelőre nem túl fontos) |
||
* Nincs DNSSEC-támogatás (egyelőre nem túl fontos) |
* Nincs DNSSEC-támogatás (egyelőre nem túl fontos) |
A lap 2008. október 28., 00:09-kori változata
Tartalomjegyzék |
1 Motiváció
- feladatok szétválasztása
- egyszerűség
- robusztusság
- alapértelmezés szerint is szigorú erőforráskorlátokkal fut
- biztonságosság
- chrootban fut, mezei userként
- kényelmi funkciók
- BIND-bugok elkerülése
2 A csomag tartalma
- tinydns
- csak autoritatív szerver
- csak UDP-kéréseket szolgál ki
- sosem kell újraindítani
- minimális a memóriaigénye (mert az adatok a cdb-ben vannak); kb. 24kB kód, kb. 356kB data
- axfrdns
- csak autoritatív és AXFR-szerver
- csak TCP-kéréseket szolgál ki
- dnscache
- csak rekurzív, cache-elő szerver
- UDP-t és TCP-t egyaránt támogat (mert muszáj)
- csak autoritatív szervertől fogad el választ (a cache poisoning legdurvább eseteit kizárja)
- egyszerű hozzáférésvezérlés: touch ip/a.b.c.d
- egyszerű "DNS-torzítás": echo "a.b.c.d" >servers/doma.in
- minden (akár ismeretlen) rekordtípust támogat
- walldns
- generikus PTR-rekordokat előállító autoritatív szerver
- pl: 1.2.3.4 PTR rekordjának tartalma 4.3.2.1.in-addr.arpa, és ehhez kapunk egy A rekordot is, ami pont az ellentétes irányú megfeleltetést valósítja meg
- felhasználása: pl. nagyszámú cégen belüli munkaállomás "nevesítése"
- csak akkor használhatjuk, ha megkapjuk a reverse delegációt is
- rbldns
- IP-alapú feketelistákhoz; 4.3.2.1.valamilyen.domain jellegű nevekre vonatkozó A és TXT kérdésekre tud válaszolni
3 tinydns
Főbb tulajdonságai:
- chrootban fut;
- az összes zóna-adatot egyetlen bináris zónafájlból, a data.cdb-ből veszi;
- csak olyan kérdésre válaszol, amelyre autoritatív választ tud adni.
Nyújt pár extrát:
- Kliens-IP szerint változó válasz.
- Pl. az irodából vagy a VPN fölött nézve a céges webszerverek a VPN-es IP-jükön vannak, az Internet felől nézve a nyilvános IP-n.
- Ez az ún. split-horizon DNS.
- Minden rekordnak lehet érvényességi ideje.
- A kezdete előtt olyan, mintha nem lenne.
- A lejáratához közeledve a tinydns automatikusan egyre kisebb TTL-lel szolgálja ki.
3.1 Zónafájl-formátum
Tervezési szempontok:
- Könnyen parse-olható legyen.
- Scriptből generálható legyen.
- A gyakorlatban előforduló esetekben legyen egyszerű.
- Nincs külön forward és reverse zóna, egyetlen sorral megadhatjuk az A és a PTR rekordot is (így legalább biztosan összhangban vannak).
- Támogasson tetszőleges rekordtípusokat.
- Legyenek értelmes defaultok, ne kelljen mindent kézzel megadni.
- Ne legyen merev fájl-zóna megfeleltetés (egy zóna lehet több fájlban, több zóna lehet egy fájlban).
- Használhassunk wildcardokat.
Felépítése: egy sor egy "adatelemet" ad meg, ami több rekordot is jelenthet. A sorok mezőkből állnak, ezeket kettőspont választja el egymástól (mint a /etc/passwd). A sor első karaktere a sor "típusa", ez dönti el, hány és milyen rekord fog generálódni belőle.
Egy csomó mező opcionális; a sorvégi üres mezőket egyáltalán nem kell jelölni. A következő két sor ekvivalens:
+valami.név:1.2.3.4:::: +valami.név:1.2.3.4
Minden sorban állhat TTL és egy TAI64N időbélyeg; ha a TTL 0, az időbélyeg a rekord lejárati idejét adja meg, ha pozitív, akkor pedig az érvényesség kezdetét.
Sor-típusok:
- # comment: megjegyzés
- %lo:ipprefix: kliens-osztályt definiál az IP-prefix alapján. Az osztály neve egy vagy két karakterből állhat (itt "lo"); egy kliens pontosan egy osztályba tartozik (több illeszkedés esetén abba, amelynek a leghosszabb a prefixe).
Példa:
# a 10.0.0.0/8 a belső hálózat %in:10 # az "a" jelű partner a 192.168.0.0/16-ot használja %a:192.168 # ezen belül megkülönböztetjük a "b" jelű subnetet: %b:192.168.42 # mindenki más külsős %ex
- .domainnév:a.b.c.d:x:ttl:timestamp:lo: domainnév nameserverét adja meg. A következő rekordok generálódnak belőle (BIND notációban):
- domainnév. IN NS x.ns.domainnév.
- x.ns.domainnév. IN A a.b.c.d
- domainnév. IN SOA x.ns.domainnév. hostmaster.domainnév. automatikusan-generált-sorozatszám 16384 2048 1048576 2560
- az IP-t nem kell itt megadnunk, ha van olyan másik sor, amiben megadjuk
- a sorozatszám az aktuális dátumból generálódik, nemigen kell foglalkoznunk vele
- lo az a kliensosztály, amely láthatja ezeket a rekordokat
- ilyen sort akkor használunk, ha a saját zónáinkat írjuk le
- ha egy domainhez nincs a cdb-ben SOA rekord, akkor a tinydns nem tekinti magát autoritatívnak arra a domainre
- .domainnév:a.b.c.d:ns.valami.dom:ttl:timestamp:lo: mint fent, de a nameserver ns.valami.dom lesz, nem ns.valami.dom.domainnév (ha van benne pont, akkor feltételezi, hogy az egész nevet megadtuk)
Példa:
# a.ns.panic.mil a panic.mil nameservere, az IP-je 1.8.7.55: .panic.mil:1.8.7.55:a # a másik szerverünk nevére nem vagyunk autoritatívak, ezért itt nincs értelme megadni az IP-t: .panic.mil::a.ns.heaven.af.mil
- &domainnév:a.b.c.d:x:ttl:timestamp:lo: mint fent (.domainnév), csak SOA rekord nélkül.
- akkor használjuk, ha a domainnevet egy másik szervernek delegáljuk
- =név.doma.in:a.b.c.d:ttl:timestamp:lo: A és PTR rekord egyben.
Példa:
=torpapa.eik.bme.hu:152.66.115.35:14400 =www.eu.int:147.67.243.9
- +név.doma.in:a.b.c.d:ttl:timestamp:lo: csak A rekord, PTR nélkül (újabb név az adott IP-hez, vagy újabb IP az adott névhez)
- ha egy névhez több IP tartozik, a tinydns véletlenszerű sorrendben sorolja fel őket a válaszokban; ha nyolcnál több van, akkor véletlenszerűen kiválaszt nyolcat, és azokat sorolja fel véletlen sorrendben
- -név.doma.in:a.b.c.d:ttl:timestamp:lo: ideiglenesen kikapcsolt A rekord, pl. halott szerver címe
- @fqdn:a.b.c.d:név:prioritás:ttl:timestamp:lo: MX.
- fqdn. IN MX prioritás név.mx.fqdn.
- név.mx.fqdn. IN A a.b.c.d
- Ha név tartalmaz pontot, akkor nem kerül mögé az, hogy "mx.fqdn".
- 'fqdn:sztring:ttl:timestamp:lo: TXT rekord. A sztring tartalmú TXT rekordot hozza létre az fqdn névhez. A sztringben használhatunk \xxx alakú oktális escape-eket; pl. a \072 a kettőspont.
- ^d.c.b.a.in-addr.arpa:név.doma.in:ttl:timestamp:lo: PTR rekord
Példa:
# classless delegációt kellett fogadnunk... ^129.128/26.3.2.1.in-addr.arpa:www.cégnév.hu:1200
- Cfqdn:hova.mut.at:ttl:timestamp:lo: CNAME rekord
- Ha csak több nevet szeretnénk egy IP-nek, használjunk inkább "+" sort
- Zfqdn:primarydns:admincontact:serial:refresh:retry:expire:minimumtime:ttl:timestamp:lo: SOA rekord, ha kézzel akarjuk megadni az adatait
- :fqdn:n:rdata:ttl:timestamp:lo: generikus rekord
Az így elkészített szövegfájlból a tinydns-data csinál cdb-t.
Egy lehetséges megoldás arra az esetre, ha több alkönyvtárban, több fájlban szeretnénk tartani a DNS-adatainkat:
- Legyen egy könyvtárunk, ennek az alkönyvtáraiban vannak a szöveges zónafájlok (pontosan egy szint mélységben)
- Egyetlen megkötés: a zónafájl neve a "zone-" sztringgel kezdődik
Ebben az esetben a következő Makefile segítségével automatikusan "lefordíthatjuk" a zónákat, ha megváltoztak, ill. be is committálhatjuk egy subversion-repositoryba a változásokat:
all : commit data.cdb data commit : data.cdb svn status | egrep -v 'data.cdb' | grep -q '^M' && svn -m 'make' commit || true touch $@ data.cdb : data */zone-* tinydns-data chown :dnsadmin data.cdb chmod 664 data.cdb data : */zone-* cat `find . -name "zone-*" | fgrep -v /.svn` >data chown :dnsadmin data chmod 664 data
4 Zónareplikáció DJB-módra
- "Az AXFR rossz, értem?"
- Helyette: rsync over ssh, mert:
- A "slave" és a "master" is kezdeményezheti
- Azonnal replikál, nem "egyszercsak"
- Mindenképpen csak a fájlok különbségeit viszi át
- A BINDhoz van IXFR, de csak akkor működik, ha nagyon óvatosan bánunk a zónafájlokkal
- Az rsync eredménye a kezdeményező oldalán azonnal lászik
- Automatikusan, további konfiguráció nélkül átviszi az összes új zónát
- Automatikusan, minden erőfeszítés nélkül átvisz minden, akár ismeretlen rekordtípust
- Átviszi a BIND által nem támogatott rekord-tulajdonságokat (érvényességi idő, kliens-IP-alapú differenciálás)
- Tömörített
- Titkosított
- Tetszőleges módszerrel történhet a hitelesítés (PAM...)
- Vagy: subversion
- Mint fent, de van verziókövetés is
Az rsync és a subversion közös hátránya, hogy csak akkor használható, ha a két szerver ugyanazokat a zónákat szolgálja ki (tehát nincs olyan zóna, amit az egyik igen, de a másik nem).
5 A djbdns hátrányai
- Gyakorlatilag lehetetlen egy IP-n futtatni a cache-t és az autoritatív szervert (bár BIND esetében se ajánlott)
- Körülményes a BIND-szerűségeket futtató secondaryk támogatása (pl. nincs beépített lehetőség arra, hogy NOTIFY-t küldjünk, külső scripttel kell)
-
(néhány hónapja a public domainbe helyezte a szerző)Nem szabad szoftver (nem terjeszthető) - Nincs IPv6-támogatás (egyelőre nem túl fontos)
- Nincs DNSSEC-támogatás (egyelőre nem túl fontos)
- Szinte olvashatatlan a kód (bár ettől eltekintve jó minőségű)