Dinamikus DNS házilag

A közelmúltban több helyen is felmerült az a kérdés, hogy hogyan lehetne dinamikus DNS-t csinálni otthonra. Először is több szolgáltató is kínál ilyeneket: dyn.com, noip.com, dnsdynamic.org, és még egy halom, a google kidob párat. Talán olyan is akad, amelyik – esetleg csekély díjazás fejében – a saját domain-ünket is hajlandó kezelni, nem kerestem.

Viszont nekünk a saját eszközeinkkel kell megoldanunk a feladatot. Nézzük mi kell hozzá1:

  • Saját domain név, ez valószínűleg adott, ha nem, akkor választani kell egyet. A példákban a termoember.hu-t fogom hasznáni, jelenleg (még) nincs regisztrálva.
  • Két, egymástól független hálózatban lévő DNS szerver. Ez általában problémás, ám a legtöbb regisztrátor ad másodlagos2 DNS-t a nála regisztrált zónákhoz. Így már csak egy, fix IP címmel rendelkező szervert kell valahonnét leakasztani.
  • Olyan levelezőszerver, aki hajlandó elfogadni a postmaster@termoember.hu címre érkező leveleket.

A DNS szerver beállítása

A telepítés

Először is kell egy DNS szerver, amit a fix IP címmel rendelkező gépre fel kell telepíteni. Maga a telepítés általában rém egyszerű, az adott operációs rendszer csomagkezelőjével fel kell telepíteni a megfelelő csomagot. Én Debiánt használok, ezért az aptitude install bind9 parancs ezt meg is oldja. Ez a lépés általában nem ütközik nehézségbe.

A zóna beállítása

A következő lépés a zóna beállítása. Ehhez létre kell hozni egy zónafájlt (az IP címek teljesen légbőlkapottak):

Hogy pontosan mi micsoda, azt a wikipédia és a google elmagyarázza :) Ezt a zónafájlt el kell menteni, én általában a zóna nevét szoktam felhasználni ehhez, ezért a fájl neve termoember.hu.zone lesz, és Debián esetén a /var/cache/bind könyvtárba kell tenni. Ha ez megvan, akkor már csak meg kell neki mondani, hogy ott találja. Ezt a /etc/bind/named.conf.local fájlban célszerű megtenni, a következők hozzáadásával:

Pár dolog, ami nem lesz meg a google-ben: a hureg és a my-slaves az két darab ACL, tartalmazza a slave és a recheck DNS szerverek címeit, az allow-update sor pedig engedélyezi a megfelelő kulccsal rendelkezők számára a zóna módosítását. A hureg acl-t ide teszem, de a my-slaves az mindenkinek más és más. Ezeket szintén a /etc/bind/named.conf.local fájlba kell elhelyezni.

A /etc/init.d/bind9 reload parancs kiadása után kb. ilyesmit kell látni a /var/log/daemon.log fájlban:

Legyen dinamikus!

Így most már van egy többé-kevésbé használható zóna, most már csak a módosításokat kell engedélyezni a számára. Erre az nsupdate parancsot fogjuk használni, ami parancs a dnsutils csomag része. Akár a szerveren, de akár egy másik gépen is futtathatjuk. Én egy másik gépet választok, de tulajdonképpen nincs észvesztő különbség. A telepítés maga szintén nem egy borzalmasan összetett dolog: aptitude install dnsutils. Így még természetesen nem tudjuk módosítani a zónát, hiszen akkor bárki képes lenne erre, ami azért kissé merész dolog lenne. Ezért le kell gyártani a megfelelő kulcsot (a szerveren elvileg megvan hozzá a parancs) a dnssec-keygen -a HMAC-MD5 -b 256 -n USER remote-key paranccsal. Ez két fájlt csinál, ebből a private az érdekes:

Ebből kell főzni egy key bejegyzést a bind számára (ez annak az allow-update sornak a párja, ami fentebb szerepel a konfigban):

Lassacskán alakul a dolog. Most a kliens gépen, ami kb. bármelyik lehet, létre kell hozni egy tyler.txt fájlt:

Persze nem szükséges fájlt csinálni, most csak a szemléltetés miatt csinálom így. Ha a fájl megvan, akkor már nagyon-nagyon közel vagyunk a dolgok végéhez. A named.conf.local-ból ki kell másolni a key remote-key { ... } részletet, és a távoli gépen betenni pl. egy server-key fájlba. Ha ez megvan, akkor máris lehet matatni a zónát:

Ha minden pompás, akkor a szerveren valami ilyesmit fogunk látni a logban:

Az életben természetesen az add/delete fordítva van, azaz először kitöröljük a régi bejegyzést, majd hozzáadjuk az újat, nekem a tesztelgetések miatt így kényelmesebb volt.

Gyakorlatilag ezzel készen is vagyunk, ettől kezdve a következő dolgokra kell figyelni:

  1. Nagyon vigyázni kell a kulcsokra, mert akinek megvan a kulcs, az tudja módosítani a zónát.
  2. Az IP cím azonnal megváltozik, és a slave szerverek is átveszik a változásokat, ezért ésszel kell futtatni a scriptet, lehetőleg csak olyankor, amikor az IP cím megváltozik.
  3. Az, hogy a cím megváltozik csak egy dolog, van neki egy TTL-je, ami a fenti példában 3600. Ezt lejjebb lehet (kell) venni, az igényeknek megfelelően. Otthoni szerver esetén nem valószínű, hogy egy 600-as érték (vagy akár 60-as) gondot okozna, de túl alacsonyra állítani nagyon-nagyon ellenjavallt. Részemről a 600 alá nem szívesen mennék.
  4. A tyler.txt-t természetesen sokféleképp elő lehet állítani, csupán a szintaktikára kell odafigyelni.
  5. Az nsupdate egyébként rém sokat tud, érdemes ismerkedni vele.
  6. Nagyon vigyázni kell a kulcsokra, mert akinek megvan a kulcs, az tudja módosítani a zónát!

Másodlagos DNS létrehozása

A zóna bejegyzéséhez szükség lesz egy másodlagos DNS-re, ami beállítása már elég sok mindentől függ, de általában nem nagy puki. Ha minden megvan, és a regcheck is lefut, akkor a zóna bejegyezhető.

Láb, jegyzet
1. A jelenlegi, magyarországi szabályozás alapján, a .hu TLD-hez.
2. Az elsődleges (primary) és másodlagos (secondary) szervereknek laza a kapcsolata a master-slave szerverekkel, csupán arról van szó, hogy a másodlagos szerver egy – vagy több – elsődleges szervertől kapja a zónainformációt; az elsődleges szerver is lehet slave (sőt, többnyire az).

You may also like...

Hide Highlights Read Highlighted Text
«
Nagyon vigyázni kell a kulcsokra, mert akinek megvan a kulcs, az tudja módosítani a zónát!