SorszámváltozásSzerkesztés
A zónaátvitel preambulum része a sorozatszámra, és csakis a sorozatszámra támaszkodik annak meghatározásához, hogy a zóna adatai megváltoztak-e, és így szükség van-e a tényleges adatátvitelre. Egyes DNS-kiszolgálócsomagok esetében a SOA erőforrásrekordok sorozatszámait a rendszergazdák kézzel tartják karban. Az adatbázis minden szerkesztése két módosítást jelent, az egyiket a módosítandó rekordon, a másikat pedig a zóna sorszámán. A folyamat pontosságot igényel: előfordulhat, hogy a rendszergazda elfelejti megváltoztatni a sorozatszámot, vagy helytelenül változtatja meg (csökkenti azt). Az RFC 1912 (2.2. szakasz SOA rekordok) a YYYYMMDDnn értéket ajánlja számként (YYYY=év, MM=hónap, DD=nap, nn=revíziós szám). Ez nem fog túlcsordulni a 4294. évig.
Egyes DNS-kiszolgálócsomagok úgy küszöbölik ki ezt a problémát, hogy a sorszámot automatikusan a lemezen lévő adatbázisfájl utolsó módosítási időbélyegéből konstruálják. Ez a helyzet például a djbdns esetében. Az operációs rendszer biztosítja, hogy az utolsó módosítási időbélyegző frissüljön, amikor a rendszergazda szerkeszti az adatbázisfájlt, így a sorozatszám automatikusan frissül, és így a rendszergazdáknak nem kell minden egyes módosításhoz két szerkesztést végezniük (két különböző helyen).
Az adatbázis-replikáció paradigmája, amelyre a sorozatszám-ellenőrzést (és magát a zónaátvitelt) tervezték, amely szerint egyetlen központi DNS-kiszolgáló tartja az adatbázis elsődleges verzióját, és az összes többi DNS-kiszolgáló csak másolatokat tart, egyszerűen nem felel meg sok modern DNS-kiszolgálócsomagnak. A modern DNS-kiszolgálócsomagok kifinomult adatbázis-alapú háttérrendszerekkel, például SQL-kiszolgálókkal és Active Directoryval lehetővé teszik a rendszergazdák számára, hogy több helyen frissítsék az adatbázist (az ilyen rendszerek multi-master replikációt alkalmaznak), és az adatbázis-alapú háttérrendszer saját replikációs mechanizmusa kezeli a replikációt az összes többi kiszolgálóra. Ez a paradigma egyszerűen nem felel meg annak, hogy egyetlen, központi, monoton növekvő szám rögzítse a változásokat, és így nagymértékben összeegyeztethetetlen a zónatranszferrel. A modern DNS-kiszolgáló csomagok kifinomult adatbázis-háttérrel gyakran létrehoznak egy “shim” sorszámot, ami szimulálja az egyetlen központi hely létezését, ahol a frissítések történnek, de ez a legjobb esetben is tökéletlen.
Szerencsére emiatt és több, később ismertetett okból kifolyólag az ilyen kifinomult adatbázis-backendet használó DNS-kiszolgálók általában ritkán használják a zónatranszfert adatbázis-replikációs mechanizmusként, és ehelyett általában a sokkal jobb elosztott adatbázis-replikációs mechanizmusokat használják, amelyeket maguk a backendek biztosítanak.
Sorszám-összehasonlításokSzerkesztés
A sorszám-összehasonlítások az RFC 1982-ben meghatározott sorszám-aritmetikát hivatottak használni. Ez azonban az RFC 1034-ben nem volt egyértelműen meghatározva, ami azt eredményezi, hogy nem minden kliens hajtja végre ugyanúgy a sorozatszám-ellenőrzést a preambulumban. Néhány ügyfél csak azt ellenőrzi, hogy a kiszolgáló által megadott sorozatszám eltér-e az ügyfél által ismert számtól, vagy nem nulla. Más kliensek azt ellenőrzik, hogy a kiszolgáló által megadott sorozatszám az ügyfél által már ismert sorozatszám egy adott tartományán belül van. Megint más ügyfelek még mindig az utóbbi ellenőrzést hajtják végre, és emellett azt is ellenőrzik, hogy a kiszolgáló által megadott sorozatszám nem nulla.
Több erőforrásrekordSzerkesztés
Eredetileg a tényleges adatátvitel során az egyes tartománynevekhez és típusokhoz tartozó erőforrásrekordok mindegyikét külön válaszüzenetben továbbították a kiszolgálótól az ügyfélnek. Ez azonban nem hatékony, és egyes DNS-kiszolgálószoftverek olyan optimalizációkat vezettek be, amelyek célja, hogy a DNS-protokoll választömörítési mechanizmusa csökkentse az adatátvitel teljes sávszélesség-igényét, például:
- “kiegészítő szakaszfeldolgozás” végrehajtása, hogy az NS, SRV vagy MX erőforrásrekord-készletekkel azonos válaszba foglaljon minden “ragasztó” erőforrásrekord-készletet
- az egyetlen tartománynévre vonatkozó összes erőforrásrekord-készlet összegyűjtése és elküldése egyetlen válaszban, ha azok megfelelnek
Néhány kliens úgy lett megírva, hogy csak az eredeti válaszformátumot várja el, és ilyen optimalizációk alkalmazása esetén nem tudta volna végrehajtani az adatátvitelt. Ezért több DNS-kiszolgálócsomag rendelkezik olyan konfigurációs beállítással, amely lehetővé teszi a rendszergazdák számára, hogy megadják az “egyetlen válaszformátumú” válaszok használatát azon ügyfelek számára, amelyek ezt igénylik.
Adatok feltárásaSzerkesztés
A DNS-zónában található adatok működési biztonsági szempontból érzékenyek lehetnek. Ennek oka, hogy az olyan információk, mint például a szerver hosztnév, közkinccsé válhatnak, ami felhasználható egy szervezetre vonatkozó információk felderítésére, és akár nagyobb támadási felületet is biztosíthat. 2017 júniusában az orosz felső szintű domainekért felelős regisztrátor véletlenül engedélyezte a DNS-zónaátvitelt az AXFR-en keresztül, ami 5,6 millió rekord véletlen felfedéséhez vezetett.
2008-ban egy bíróság az egyesült államokbeli Észak-Dakotában úgy döntött, hogy a zónaátvitel jogosulatlan kívülállóként történő végrehajtása a nyilvánosan nem hozzáférhető információk megszerzése érdekében az észak-dakotai törvények megsértésének minősül.