Lassan egy éve a World IPv6 Day-nek. Akkor egy napra a világ top weboldalai és internetszolgáltatója, beleértve a Google-t, Facebook-ot, Yahoo!-t és még több, mint 1000 más résztvevőt is összefogtak és együtt egy napra elérhetővé tették szolgáltatásaikat IPv6-on. Hogy miért is kellett ez? 1995-ben elkészült az RFC-je, 1996-ban implementálta a Linux, pár évvel később a kommerciális vállalatok is megtették. 2011-ben az IANA kiosztotta az utolsó /8-as blokkokat is az IPv4-es címtartományból, így már ideje volt valamit tenni az IPv6 elterjedése érdekében.
A közelgő World IPv6 Launch-on a résztvevők permanensen elérhetővé teszik szolgáltatásaikat IPv6-on is. Számos lépést megtettünk már, hogy a Schönherz is csatlakozhasson ehhez az eseményhez, ennek egyik fontos eleme a DNS szolgáltatásunk IPv6-ra történő felkészítése.
Hogy mi is az a DNS? Nagyon röviden: az emberek nehezen tudják megjegyezni az IP címeket, ezért szükség van egy általunk könnyen kezelhető címzés kialakítására. Erre találták ki a DNS szolgáltatást, ami többek között a számítógépek nevét és IP-címét rendeli egymáshoz. Ha ez nem lenne, a Gmail oldalát a gmail.com helyett csak IP-címekkel tudnánk elérni (például 74.125.232.214). Amikor tudjuk egy számítógép nevét a teljes domain nevével együtt, azt FQDN-nek (Fully Qualified Domain Name) nevezzük. Forward lookup alatt az FQDN-hez tartozó IP-cím feloldását, reverse lookup alatt pedig az IP-címhez tartozó név megkeresését értjük. A háttérben különböző rekordok kapcsolják egymáshoz az összetartozó adatokat. A legismertebbek ezek közül az A, AAAA, CNAME, NS, MX, TXT rekordok. A továbbiakban mind egy kicsit részletesebb bemutatásra kerül.
Először is lássunk egy példát:
| sch.bme.hu | IN | NS | nic.bme.hu | | sch.bme.hu. | IN | NS | gwen.bme.hu. | | sch.bme.hu. | IN | NS | unistar.bke.hu. | | satyr.sch.bme.hu. | IN | A | 152.66.208.100 | | satyr.sch.bme.hu. | IN | AAAA | 2001:738:2001:2078:0:208💯0 | | 100.208.66.152.in-addr.arpa. | IN | PTR | satyr.sch.bme.hu. | | upload.sch.bme.hu. | IN | CNAME | satyr.sch.bme.hu. | | home.sch.bme.hu. | IN | CNAME | satyr.sch.bme.hu. | | centaur.sch.bme.hu. | IN | CNAME | satyr.sch.bme.hu. | | satyr.sch.bme.hu. | IN | TXT | “KSZK – Belso gepek” | | sch.bme.hu. | IN | MX | 10 balu.sch.bme.hu. | | 0.0.0.0.0.0.1.0.8.0.2.0.0.0.0.0.8 .7.0.2.1.0.0.2.8.3.7.0.1.0.0.2.ip6.arpa. | IN | PTR | satyr.sch.bme.hu. |
A fenti példában a satyr.sch.bme.hu két címmel rendelkezik, egy IPv4-essel és egy IPv6-ossal, az utóbbi PTR rekordja csak a jobb olvashatóség végett van két sorba törve.
Az NS rekordok domain-eket kapcsolnak össze FQDN-nevekkel, így a domain név ismeretében egyértelműen meghatározható melyik számítógép az adott domain névszervere. Itt különböző előírásokat is be kell tartani, például minden NS rekordhoz tartoznia kell egy A vagy AAAA rekordnak is, illetve minden domain-nek kell, hogy legyen másodlagos névszervere, ami nem ugyanazon a hálózaton van elhelyezve, mint az elsődleges.
A forward lookup során egy FQDN-hez tartozó IP-címet keresünk. A DNS szerverek erre A, vagy AAAA rekordokat használnak, amik FQDN-ekhez rendelik a hozzájuk tartozó IP-címeket.
Reverse lookup során egy IP-címhez keressük meg a hozzá tartozó FQDN-t. Erre szolgálnak a PTR rekordok.
A CNAME egy alias a hosztnévre (kanonikus név), a segítségével több néven is elérhetjük ugyanazt a számítógépet. Az upload, home, centaur név mind a satyr-ra hivatkozik, ezért kellenek ezek a rekordok.
Amikor a böngésző címsorába beírjuk az upload.sch.bme.hu-t, az először megpróbálja feloldani ezt a nevet. A mi esetünkben egy visszakap egy CNAME rekordot, amiben a satyr.sch.bme.hu található, és a satyr-hoz tartozó A vagy AAAA rekordot.
A TXT rekordokban szöveges információkat helyezhetünk el, például melyik körhöz tartozik az adott gép regisztrációja, milyen hardveren fut.
Az MX rekordok egy domain-hez a hozzá tartozó levelező kiszolgáló FQDN-ét rendelik. Ez azért hasznos, mert egy levél küldésekor az e-mail cím kukac utáni részébe beírhatunk egy domain-t, és nem kell tudnunk a levelezőszerver IP-címét. A fenti példában az sch.bme.hu levelezőszervere a balu, és ennek a prioritása 10. Ha több azonos prioritású szerverünk is van, akkor a DNS azok közül round-robin módszerrel választja ki a visszaadott rekordot.
A jelenleg üzemelő szervereink egy ma már réginek mondható (de annál biztonságosabb) alkalmazást futtatnak, ami kiszolgálja a DNS kéréseket. Ezzel csak az a gond, hogy nem tudják szolgáltatni az IPv6-os névfeloldáshoz nélkülözhetetlen AAAA rekordokat és az ip6.arpa domain-t. Ugyan van rá patch, de úgy döntöttünk, hogy egy új DNS szerverrel próbáljuk megoldani a helyzetet, így esett a választás a PowerDNS-re. A nevéből is látszik, hogy főleg a teljesítményre koncentrál, de amilyen gyors, olyan biztonságos és rugalmas is. Számos backend-et támogat, pl. MySQL-t, PostgreSQL-t, LDAP-ot, BIND style zónafájlokat. Habár a Schönherzben lévő számítógépek adatai egy adatbázisban vannak, mégsem az ebből történő közvetlen kiszolgálást választottuk, mert nem a PowerDNS sémája szerint vannak tárolva az adatok. Egy külön adatbázist erre a célra fenntartani túl nagy overhead-et jelentene, ezért választottuk a BIND style zónafájlokat. Ezek átlátható szöveges állományok, könnyen lehet őket szerkeszteni, és ami a legfontosabb: „egyszerű” generálni (a fenti példák is ilyen formátumban vannak). Az egyszerű azért nem teljesen igaz, mert nem csak A, AAAA és PTR rekordok generálódnak, hanem CNAME, TXT és MX rekordok is. Közben figyelembe kellett venni a Ház háromfejű vérebét is, a Kerberost és az ehhez szükséges rekordokat is előállítani. A Kerberos egy autentikációs protokoll, ami lehetővé teszi a számítógépek és felhasználók biztonságos azonosítását egy nem biztonságos hálózaton. Így már bonyolódik a helyzet nem beszélve arról, hogy vannak statikus rekordok is, és nem csak az sch.bme.hu domain-t szolgáltatjuk.
A megoldásunk első iterációjában egy Perl szkript félóránként frissítette a rekordokat egy adatbázisból, közben a PowerDNS 5 percenként ellenőrizte ezeket. Így legkésőbb 35 perccel egy új számítógép regisztrációja után az megjelenik a DNS szerveren.
Ez a megoldás jól működött, mégis követte még egy fejlesztési iteráció. A kód komplexitása megnőtt, a használat közbeni finomítások miatt már nehéz volt átlátni az egész folyamatot. Könnyebb volt újraírni a programot, mint a jelenlegit megfoltozni, így az eredeti megoldással egyenértékű, annál sokkal jobban strukturált alkalmazás született Python nyelven.
A program működése vázlatosan:
- Csatlakozás az adatbázishoz, a szükséges adatok lekérése majd a kapcsolat bontása
- Zónafájlok megnyitása (a statikus részek megmaradnak, csak egy sorszám frissül)
- Iterálás az adatokon, közben a megfelelő rekordok előállítása
- A generált rekordok visszaírása a zónafájlokba, a fájlok lezárása
A tesztelés során találtunk egy bug-ot is, amit a fejlesztők még a bejelentéskor kijavítottak. Ez az új DNS szerver elérhető a 152.66.208.133-as és a 2001:738:2001:2078:0:208:133:0-ás IPv6-os címen, így bárki beállíthatja magának statikusan, amennyiben ki szeretné próbálni.
A végleges migrálással még várunk, hogy jobban megismerjük, miként viselkedik a kollégiumi hálózatban, de a World IPv6 Launch-ra már élesíteni fogjuk.