DNS-zóna átvitel , az AXFR egyfajta DNS - tranzakció . Ez a DNS - adatbázisok szerverek közötti replikálásának egyik mechanizmusa . Kétféle zónaátvitel létezik: teljes (AXFR RFC 1035 ) és növekményes (IXFR RFC 1995 ). Nagyon elterjedt volt, de a modern szervereken a DNS-t más replikációs mechanizmusok helyettesítik.
A zónaátvitel a TCP protokollon felül működik, és kliens-szerver tranzakció. Egy slave szerver vesz részt rajta, vagy angolul. slave , amely az adatbázisból és a főkiszolgálóból (más néven elsődleges zónaszervernek) az adatok egy részének átvitelét kéri, vagy angolul. mester , amely ezeket az adatokat szolgáltatja. Egyes forrásokban másodlagos, illetve elsődleges szervereknek nevezik őket. Az átvitt adatok része a DNS-zóna.
Ez a tranzakció egy preambulumból és magából az adatátvitelből áll. A preambulum során a SOA (authoritative source) rekordot a zóna elején ( angol zóna csúcsa ) - a zóna névterének legfelső csomópontjában - megkeresi. A SOA rekord mezői, különösen a sorozatszám határozzák meg, hogy szükség van-e egyáltalán zónaátvitelre. Az ügyfél összehasonlítja a kapott SOA rekord sorozatszámát a már birtokában lévővel. Ha az új belépési szám magasabb, akkor a zóna tartalma valamelyest megváltozott, és a kliens tényleges zóna áthelyezést kér. Ha a sorozatszámok megegyeznek, akkor a zóna tartalma változatlannak minősül, és az ügyfél továbbra is használhatja az adatok meglévő másolatát.
A tényleges adatátvitel kezdetén a kliens egy speciális típusú AXFR (QTYPE AXFR = 252) kérést (Opcode) küld a TCP kapcsolaton keresztül. A válaszként a szerver egymás után üzeneteket küld a zóna összes erőforrásrekordjával. Az első üzenet a zóna kezdetének SOA rekordját tartalmazza. A többi üzenet nincs rendezve. Az átvitel végének jele a SOA rekord újraküldése.
Egyes ügyfelek SOA-kereséseket végeznek a szabványos névfeloldási mechanizmuson keresztül. Addig nem hoznak létre TCP-kapcsolatot a szerverrel, amíg meg nem állapítják, hogy a tényleges átvitel szükséges. Mivel azonban a TCP normál DNS-tranzakciókhoz és zónaátvitelhez is használható, a többi kliens ugyanazon a kapcsolaton keresztül oldja fel a SOA rekordot a preambulumban, amelyet a tényleges átvitelhez használhat. Az ilyen kliensek TCP-kapcsolatot létesítenek a kiszolgálóról, még mielőtt a preambulum elkezdődne.
A teljes átvitel alapelveit fentebb vázoltuk. A növekményes zónaátvitel a következőképpen különbözik:
Csak a kliens kezdeményez zónaátvitelt. A szerver NOTIFY üzenetet küldhet az általa ismert ügyfeleknek, ha változás történt a zónában, de az átvitel ütemezése teljes mértékben az ügyféltől függ. A zónaátvitelt az ügyfél akkor indíthatja el, ha az adatbázisai üresek, majd a zóna frissítési, újrapróbálkozási és lejárati mezői alapján meghatározott ütemezés szerint elindíthatja a SOA rekordot.
Bár a teljes átvitel szabványos, és az egyik lehetséges replikációs mechanizmusként írja le az RFC 1034 -ben (növekményes átvitel az RFC 1995 -ben ), a zónaátvitel az adatbázisok replikálásának legkevésbé működő módja. A rekordok átvitele „nem intelligens”, azaz ugyanazt a protokollt használja, mint a normál DNS-névfeloldás. Nem veszi figyelembe a DNS-kiszolgálók háttérrendszere által használt adatbázis-sémát.
A zóna átviteli előtag csak a sorozatszámra támaszkodik annak meghatározására, hogy a zóna adatok megváltoztak-e, és szükség van-e tényleges átvitelre. Egyes DNS-kiszolgálókon a SOA sorozatszámokat a rendszergazdáknak kézzel kell szerkeszteniük. Minden adatbázis-módosítás két szerkesztést igényel: magát a rekordot és a zóna sorozatszámát. A folyamat pontosságot igényel: előfordulhat, hogy az adminisztrátor elfelejti megváltoztatni a sorozatszámot, vagy hibásan módosítja (csökkenti). Az RFC 1912 (a SOA rekordok 2.2. szakasza) YYYYMMDDnn (ÉÉÉÉ=év, MM=hónap, NN=nap, nn=napváltoztatási verzió) formátumú érték használatát javasolja számként. Ez a formátum lehetővé teszi, hogy egy számot 4294-ig használjon, és naponta 100 módosítást hajtson végre (nn 00-tól 99-ig), így Ön szabályozhatja az utolsó módosítás dátumát.
Egyes kiszolgálók úgy oldják meg ezt a problémát, hogy automatikusan kiszámítják a sorozatszámot lemezen utolsó módosítási dátuma alapján Így különösen a djbdns . Az operációs rendszer nyomon követi a fájl módosítási dátumának frissítését, lényegében automatizálva a számok kiszámítását, és minden második szerkesztési kötelezettség alól mentesíti a rendszergazdát.
A modern szerverek összetett háttérrendszerekkel, mint például az SQL és az Active Directory lehetővé teszik a rendszergazdák számára, hogy egyszerre több webhelyet szerkeszthessenek ( több főkiszolgálós replikációval rendelkező rendszerek ), ahol maga az alapul szolgáló adatbázis kezeli a replikációt más kiszolgálókra, de ez csak akkor működik, ha az összes DNS zónák egyetlen vezérlés alatt állnak. Egy ilyen modell nem felel meg egyetlen központosított, monoton növekvő változásrekordnak, ezért általában nem kompatibilis a zónaátvitellel. A modern DNS-kiszolgálók összetett háttérrendszerekkel az adatbázisokon gyakran hoznak létre egy „képzeletbeli” sorozatszámot, úgy tesznek, mintha központi frissítési forrásuk lenne, de ez legalább tökéletlen.
Ezen és más okok miatt az összetett adatbázis-háttérrendszerrel rendelkező DNS-kiszolgálók ritkán használnak zónaátvitelt a replikációhoz, így a feladat sokkal hatékonyabb belső adatbázis-mechanizmusokra bízza.
A sorozatszám-összehasonlítás magában foglalja a sorozatszám-aritmetika használatát (például a 2000-es év problémájának elkerülése érdekében ) az RFC 1982 szerint . Ezt azonban az RFC 1034 nem fogalmazta meg egyértelműen , és ennek eredményeként az ügyfelek eltérően hasonlítják össze a preambulum számait. Vannak, akik csak arra figyelnek, hogy a kapott szám eltér-e a meglévőtől, vagy nem nulla. Mások ellenőrzik, hogy a kapott szám egy adott intervallumon belül van-e a meglévőhöz képest. Mások is ellenőrzik a nullát.
Kezdetben a tényleges adatátvitel során minden egyes domain névhez és típushoz tartozó bejegyzés külön üzenetben került át a szerverről a kliensre. Ez nem volt hatékony, és egyes DNS-kiszolgálók optimalizálták a folyamatot, hogy csökkentsék a sávszélességet a DNS-protokoll tömörítési mechanizmusai révén, mint például:
Néhány ügyfél csak az eredeti válaszformátumot várta, és nem tudta elfogadni az így optimalizált adatokat. Ezt szem előtt tartva az egyes DNS-szervereket úgy konfigurálták, hogy "egy formátumú válaszokat" küldjenek az ilyen ügyfeleknek.
A DNS-zónában található információk működésbiztonsági szempontból bizalmasnak tekinthetők. Például az erőforrásrekordok tartalmazhatnak kiszolgálói szerepkör-információkat vagy SSH-kulcs ujjlenyomatait ( RFC 4255 ).
2008- ban az Egyesült Államok észak-dakotai bírósága kimondta, hogy egy magánterület külső személy által kezdeményezett jogosulatlan átruházása sérti az állam törvényeit.