djbdns

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(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)
  • Nem szabad szoftver (nem terjeszthető) (néhány hónapja a public domainbe helyezte a szerző)
  • 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ű)
Személyes eszközök