DNS-zónatranszfer

A DNS-zónatranszfer vagy DNS-zónaátvitel, amit időnként a leggyakrabban használt opkód mnemonikjával, az AXFR-rel jelölnek, az internetes névfeloldás protokolljában, a DNS-ben használt tranzakció.

A zónatranszfer az adminisztrátorok egyik eszköze a DNS-adatbázis névkiszolgálók közötti replikálására. Két fajtája van, a teljes (opkód: AXFR) és az inkrementális (IXFR). Egy időben szinte az egyedüli lehetőség volt a DNS-adatbázis replikációjára, a modern DNS-szerver-alkalmazáscsomagok által nyújtott egyéb mechanizmusok miatt népszerűsége csökkenőben van.

Működése

A zónatranszfer egy TCP-kapcsolat fölött (leggyakrabban az 53-as porton keresztül) létrejövő kliens-szerver tranzakció. A két részt vevő fél közül az egyik a kliens (a „szolga”, aki az adatbázis egy részének transzferét igényeli), a másik a szerver (a „mester”, aki az adatokat szolgáltatja az adatbázisából). A szakirodalomban a „szolga” szerepel másodlagos szerver, a „mester” pedig elsődleges szerver néven is. Az adatbázisból a replikálódó rész egy ún. „zóna”.

A zónatranszfer preambulummal kezdődik, amit a tényleges adatátvitel követ. A preambulum a zóna csúcsához (zone apex) tartozó SOA (Start of Authority) erőforrásrekordra való keresésből áll. A SOA mezői, különösen a zóna sorszáma vagy sorozatszáma (serial number) határozza meg, szükséges-e egyáltalán adatátvitel. A kliens összehasonlítja a SOA erőforrásrekord sorozatszámát a számára rendelkezésre álló utolsó másolat sorozatszámával. Ha a kért rekord sorozatszáma nagyobb, az azt jelenti, hogy a zónában lévő adatok valamilyen módon megváltoztak, és a kliens folytatja a zóna tényleges átvitelével. Ha a sorozatszámok megegyeznek, a zónában lévő adatoknak is azonosaknak kell lenniük, és a kliens folytathatja a munkát a saját példányával.

A tényleges adatátvitel úgy kezdődik, hogy a kliens TCP kapcsolaton keresztül kérést (opkód 0) intéz a szerver felé, egy speciális QTYPE-ot (query type, lekéréstípus), az AXFR-t (252) használva. A szerver válaszüzenetek sorozatával válaszol, melyek a zónában található összes név összes erőforrásrekordját tartalmazzák. A legelső válasz a zónacsúcs SOA erőforrásrekordjából áll, a többi adat sorrendje nem kötött. Az adatküldés befejeződését a szerver a zónacsúcs SOA erőforrásrekordjának ismételt elküldésével jelzi.

Egyes kliensek a preambulum SOA-lekérését a rendszer normál DNS-lekérdezési mechanizmusán keresztül végzik. Ezek a kliensek nem nyitnak TCP-kapcsolatot a szerver felé, míg meg nem győződtek róla, hogy tényleges adatátvitelt kell végezniük. Más kliensek épp ellenkezőleg, már a preambulum elvégzése előtt megnyitják a TCP-kapcsolatot, és ugyanezen a kapcsolaton keresztül végzik a tényleges adatátvitelt is.

Az előzőekben a teljes zónaátvitelt írtuk le. Az inkrementális (növekményes) zónaátvitel néhány dologban különbözik, ezek:

• A kliens az IXFR (251) QTYPE-ot használja az AXFR helyett.
• A kliens elküldi a szerver felé az általa ismert zónacsúcs SOA erőforrásrekordját az IXFR üzenetben, ezzel tudatva a szerverrel, a zóna melyik verzióját tekinti érvényesnek.
• A szerver válaszolhat az AXFR-nél megszokott módon a zóna teljes adatmennyiségével, vagy dönthet az inkrementális adatküldés mellett. Ez utóbbi a zónaadatok a kliensnél és a szervernél lévő verziók közötti változásának sorozatszám szerinti rendben elküldött listájából áll. A változások két listában mennek át, az egyik a törlendő, a másik a beszúrandó erőforrásrekordokat tartalmazza (egy rekord módosítása a törléséből, majd újra beillesztéséből áll össze). A zóna DNS-kiszolgálójának tárolnia kell a növekményes zónaváltozások előzményeit ahhoz, hogy az IXFR-lekérdezés sikeres legyen. A növekményes letöltési eljárás lényegesen kisebb hálózati forgalmat igényel és az így végzett zónaletöltések sokkal gyorsabbak.

A zónatranszfert teljes mértékben a kliens kezdeményezi. Bár a szerverek küldhetnek NOTIFY üzenetet a klienseknek a zónaadatok változásakor, a zónatranszfer időzítése teljesen a kliensen múlik. A kliensek a kezdeti, üres adatbázissal történő zónatranszfer után szabályos időközönként szoktak zónaátvitelt végezni, a zónacsúcs SOA erőforrásrekordjának „refresh”, „retry” és „expire” mezői alapján.

Korlátai

Bár szabvány írja le – a teljes zónaátvitel az RFC 1024-ben leírt lehetséges adatbázis-replikációs mechanizmusok egyike (az inkrementális transzfert az RFC 1995 írja le) –, a zónatranszfer ezek közül a mechanizmusok között a leginkább korlátozott. A zónaátvitel során az erőforrások kezelése a „vezetéken megjelenő” formájukban történik, mivel a DNS protokoll szerint történik az átvitelük. Azonban a vezetéken megjelenő erőforrásrekord-séma nem feltétlenül egyezik meg a DNS-szerver back-end adatbázissémájával.

Működési problémák

Sorszámváltozások

A zónatranszfer preambulum-része a sorszámot, és kizárólag a sorszámot veszi figyelembe annak eldöntésénél, hogy a zóna adatai megváltoztak-e, és így szükség van-e tényleges adatátvitelre. Egyes DNS-szerverszoftvereknél a SOA erőforrásrekord sorszámát az adminisztrátor kézzel tartja karban. Az adatbázis minden szerkesztésénél két változtatást kell végrehajtani, az egyik a rekordváltoztatás, a másik a zóna sorszámának megnövelése. Ez munkaigényes folyamat, és a rendszergazda könnyen megfeledkezhet a sorszám megváltoztatásáról, vagy előfordulhat, hogy tévedésből csökkenti vagy túl nagy értékkel növeli meg azt.

Egyes DNS-szerverszoftverekben úgy oldották meg ezt a problémát, hogy a lemezen lévő adatbázisfájl utolsó módosítási időbélyegéből automatikusan képezik a zóna sorozatszámát. Így működik például a djbdns. Az operációs rendszer biztosítja, hogy az időbélyeg frissüljön, amikor az adminisztrátor elmenti az adatbázisfájl változásait, tehát effektíve automatikusan frissül a sorozatszám, megkönnyítve a rendszergazda dolgát.

Továbbá, az adatbázis-replikáció azon paradigmája, amin a sorozatszám-ellenőrzés (és valójában az egész zónaátvitel) alapul, feltételezi egyetlen központi DNS-kiszolgáló létezését, ami az adatbázis mesterváltozatát tárolja, míg a többi DNS-kiszolgálón csak másolatok futnak, egyszerűen nem állja meg a helyét a modern DNS-kiszolgáló szervercsomagok esetében. Az ilyen kifinomult adatbázis-back-endekkel (pl. SQL szerverek, Active Directory) rendelkező, modern DNS-szervercsomagok megengedik, hogy a rendszergazdák az adatbázis több példányán is frissítéseket hajtsanak végre (multi-master replikációt használva), és az adatbázis-back-end a saját replikációs mechanizmusával oldja meg a többi szerver felé a replikációt. Ez a paradigma egyszerűen nem illeszthető össze az egyetlen, központi, monoton növekvő, a változást rögzítő szám koncepciójával, így nagymértékben inkompatibilis a DNS-zónatranszferrel. A szofisztikált adatbázis-back-enddel rendelkező modern DNS-szervercsomagok gyakran egy „shim” szériaszámot gyártanak, szimulálva azt, hogy egyetlen központi helyen történnek a frissítések, de ez a megoldás távol van a tökéletestől.

Szerencsére, a fenti okokból és más okok miatt, a komolyabb adatbázis-hátterű DNS-kiszolgálók ritkán támaszkodnak a zónatranszferre mint replikációs megoldásra, ehelyett azokat a sokkal fejlettebb adatbázis-replikációs mechanizmusokat használják, amik a back-end révén amúgy is rendelkezésre állnak.

Sorszám-összehasonlítások

A sorozatszámok összehasonlításakor az RFC 1982-ben meghatározott „sorszám-aritmetikát” kellene használni. Ezt azonban az RFC 1034-ben nem írták le egyértelműen, így a preambulumban elvégzendő sorozatszám-ellenőrzést nem minden kliens végzi egyformán. Egyes kliensek csak azt ellenőrzik, hogy a szerveren lévő sorszám eltér a kliensétől, vagy nem nulla értékű. Mások azt ellenőrzik, hogy a szerveren lévő sorszám a kliensétől adott távolságon belülre esik. Az is előfordul, hogy az előbb leírt ellenőrzés elvégzése után még azt is megnézi a kliens, hogy a szerveren tárolt sorszám nem nulla-e.

Több erőforrásrekord

Eredetileg a tényleges adatátvitel során doménenként minden típushoz tartozó erőforrásrekordot külön-külön válaszüzenetben küldött el a szerver a kliensnek. Ez azonban nem valami hatékony, így néhány DNS-szerverszoftverben optimalizálták az átvitelt, a DNS protokollban lévő választömörítési mechanizmust felhasználva:

• további szakaszfeldolgozás („additional section processing”) elvégzése, hogy az NS, SRV vagy MX erőforrásrekordokkal együtt a „glue” erőforrásrekordokat (ragadványrekordok) is elküldje ugyanabban az üzenetben;
• az azonos doménben lévő valamennyi erőforrásrekord együttes elküldése egyetlen üzenetben (ha belefér).

Egyes kliensek kizárólag az eredeti válaszformátumot tudják értelmezni, és a fenti optimalizálások megakadályoznák, hogy át tudják vinni a zónát. Ezért több DNS-szervercsomag konfigurálható úgy, hogy az eredeti „single answer format” szerint küldje el a rekordokat az erre rászoruló klienseknek.

Adatszivárgás

A DNS-zóna adatai üzembiztonság szempontjából érzékenyek lehetnek.

2008-ban egy észak-dakotai bíróság úgy határozott, hogy a külső fél számára információt nyújtó, engedély nélkül történő zónaátvitel Észak-Dakota állam törvényeibe ütközik.

Kapcsolódó szócikkek

• DNS-rekordtípusok listája
• DNS-zónafájl

További információk

• How the AXFR protocol works. Internet publication, D. J. Bernstein. (Hozzáférés: 2005. február 15.)
• Understanding zones and zone transfer. Microsoft Windows Server 2003 product documentation. (Hozzáférés: 2011. november 27.)
• How DNS Support for Active Directory Works. Microsoft Windows Server 2003 product documentation. (Hozzáférés: 2011. november 27.)
• DNS zone replication in Active Directory. Microsoft Windows Server 2003 product documentation. (Hozzáférés: 2011. november 27.)

Kapcsolódó RFC-k

• RFC 1034 Domain Names - Concepts and Facilities. (definiálja az AXFR-t)
• RFC 1995 Incremental Zone Transfer in DNS
• RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
• draft-ietf-dnsext-axfr-clarify DNS Zone Transfer Protocol (AXFR) internet draft