Hogyan lehet?
Kétféle módon is lehetséges: részlegesen vagy teljesen. Részlegesen, azaz a webdns.sulinet.hu cím alatti grafikus felületű űrlapon, ahol alapszintű műveleteket hajthatunk végre a forward és a reverse zónánk rekordjaival (felvétel, törlés, változtatás, alias-ok (cname) létrehozása). Ehhez azonban a forms.sulinet.hu oldalon egy kérelmet kell benyújtanunk, a "Domain adminisztráció igénylése" pontnál. Ezután kap(hat)unk egy új felhasználónevet és jelszót, amellyel a webes felületen képesek leszünk a fenti műveletek elvégzésére. Ez az energiatakarékosabb megoldás, azonban a zóna feletti szabadságunk nem teljesen korlátlan.
A másik eset az, amikor publikus DNS szervert hozunk létre a saját szerverünkön, kikérjük a zózánkat és magunk gondoskodunk ennek feltöltéséről, ellenőrzéséről és karbantartásáról. Így teljesen szabad kezet kapunk a zóna tartalmát illetően, azaz mi fogjuk "megmondani" hogy melyik szerver milyen néven látszódjon a neten, melyik IP cím mit takar, melyik alias (pl. www, ftp, stb.) melyik géphez van rendelve és így tovább. Ebben az esetben tehát a mi kiszolgálónk lesz a sulinetes zónánk elsődleges (primary) DNS szervere, míg a másodlagos (secondary) DNS szerver funkciót a Közháló erre kijelölt névszervere fogja biztosítani. További előny még az is, hogyha tervezünk önálló, legfelsőbb szintű DNS zónát (pl. tjszki.hu), akkor azt is tárolhatjuk ezen a szerveren és ekkor csak a secondary DNS szerver funkcióért kell fizetnünk annak az ISP-nek, akivel szerződésben állunk.
Viszont a publikus, internetre "kitett" DNS szerver üzemeltetése (nem mellesleg a _biztonságos_ üzemeltetése) komoly felelősséggel jár, és valóban csak a megfelelő ismeretek birtokában szabad hozzákezdenünk ehhez a váltáshoz. A szabályok szerint (és önmagunk érdekében is), először fel kell építenünk a zónát, amelynek tökeletesen kell működnie (amelyet ellenőriznek is), és majd csak ezután kérhetjük ki és valósíthatjuk meg az átvételt.
Tervezés ezerrel
Ezeken a "hasábokon" volt már szó a windows-os DNS szerverekről (lásd a lap alján), mert az Active Directory-ra épülő tartomány egy privát használatra (azaz csak kifejezetten a belső hálózatra) telepített DNS szerver nélkül nem működik megfelelően. Ezért gyakorlatilag a telepítés és még egy-két üzemeltetési feladat tökéletesen megegyezik a mi jelenlegi esetünkkel. Azonban vannak lényeges különbségek már a tervezés során is, és ha másért nem, azért biztosan fontos komolyan vennünk ezeket, hogy sose feledjük el, hogy igazi, kintről állandóan látható, klasszikus DNS szerverünk lesz, ami egyúttal az internet egyik sarokköve (azért a "sarokkő" szóban van egy kis költői túlzás :D). Mindenestere az biztos, hogy nem lesz kit okolnunk magunkon kívül, ha a rossz DNS konfigurció miatt nem leszünk elérhetőek, nem jönnek be a levelek, nem működnek az egyéb szolgáltatásaink.
Tehát tervezzünk először papiron vadul, és induljunk ki abból, hogy van egy Windows 2000/2003 alapú tartományunk, amelyben már van egy darab (egyelőre csak belső használatra szánt) DNS szerverünk és természetesen van egy tűzfalunk (ISA). Nézzük tehát - első körben a szerverek számától függően - milyen variációk jöhetnek elő, ha szeretnénk publikus DNS szervert is.
1. Belső és külső DNS, mindkettő az ISA-n (mert összesen egy szerverünk van)
Ez a variáció problémás, több okból is. Először is, ha csak ez az egy szerverünk van, akkor valószínűleg ezen fut az AD, az Exchange, az ISA, az IIS, ez a file/printszerver, esetleg SPS, SQL és még soroljam? Biztosan tovább akarjuk ezt terhelni? Bár tegyük hozzá azért, hogy a DNS szerver funkció nem okoz komoly háttértár, processzor vagy memória igényt, de azért lehetséges, hogy mégiscsak problémás lesz ez a plusz terhelés.
A másik ok: tegyük fel, hogy már létezik az AD, kötött névvel (amit nem lehet megváltoztatni illetve a Windows Server 2003-nál mégis, bár ott is vannak azért ez ügyben megkötések) és a tartomány neve is ugyanaz mint a külső, az intézményünkhöz a Sulinet/Közháló által rendelt DNS zóna neve (pl. tjszki.sulinet.hu mindkettő). Ez utóbbit szintén meg lehet változtatni, de ezt sem annyira egyszerűen, ráadásul néha nem is célszerű, mert passzol a név vagy mondjuk jól bejáratott már.
Mindenesetre ha összesen egy szerverünk van és a fentiek miatt azonosnak kell lennie a belső és a külső DNS zóna névnek akkor szinte teljesen meg vagyunk "lőve", hiszen ebben az esetben a privát, a belső hálózatból származó IP címek mellett (és gondoljunk pl. az SRV rekordok tömegére is) a publikus IP címeket is be kellene jegyeznünk ugyanabba a zónába, ami az íratlan szabályokkal teljesen ellentétes elképzelés. Mindemellett nem is biztonságos, hiszen bizonyos esetekben (pl. zóna transzfer) így a belső neveket, címeket, így akár a hálózati struktúrát is láthatóvá tennénk kívülre.
De továbbmenve ezen az ötletfonalon, ebben a szituációban az aliasokkal is gond lenne, hiszen ha a publikus IP-t állítjuk be pl. a "www" aliasra, akkor kintről egyszerűen megtalálják a webszerverünket, de bentről nehézkesebben és feleslegesen túlterhelve az ISA-t. Ennek oka az, hogy a belülről jövő kérés esetén teljesen értelmetlen módon a szerver külső lábára kellene irányítani forgalmat a "www" bejegyzés tartalma miatt, amely aztán az ISA-ban lévő webszerver publikálás szabály miatt a belső IP-re küldi a kérést. Az ISA 2000 MMC faszerkezetének Network Rules részében hozhatunk létre egy kivételező szabályt, amely miatt nem "proxyzna" a mi webszerverünk neve esetén, sőt ez megoldható pl. az ftp-vel is, de a levelezőszerverrel mindenképp gondunk lesz. Ha pedig egy belső IP címet állítunk be aliasként, akkor meg - könnyen követhető okokból - kívülről lesz elérhetetlen...
Folytatjuk...
(és lesz megoldás is :D)
Gál Tamás
gtamas@tjszki.hu
