Ändring av serienummerRedigera
Preambeldelen av zonöverföringen förlitar sig på serienumret, och endast serienumret, för att avgöra om en zons data har ändrats och därmed om den faktiska dataöverföringen är nödvändig. För vissa DNS-serverpaket upprätthålls serienumren för SOA-resursposter manuellt av administratörer. Varje ändring i databasen innebär två ändringar, en i den post som ska ändras och en i zonens serienummer. Processen kräver noggrannhet: administratören kan glömma att ändra serienumret eller ändra det felaktigt (minska det). I RFC 1912 (avsnitt 2.2 SOA-poster) rekommenderas att man använder värdet YYYYYMMDDnn som nummer (YYYYY=år, MM=månad, DD=dag, nn=revisionsnummer). Detta kommer inte att överlöpa förrän år 4294.
Vissa DNS-serverpaket har övervunnit detta problem genom att automatiskt konstruera serienumret från den senaste modifieringstidsstämpeln för databasfilen på disken. Detta är till exempel fallet för djbdns. Operativsystemet ser till att tidsstämpeln för den senaste ändringen uppdateras varje gång en administratör redigerar databasfilen, vilket i praktiken innebär att serienumret uppdateras automatiskt och att administratörerna därmed slipper göra två redigeringar (på två olika ställen) för varje enskild ändring.
Det paradigm för replikering av databaser som kontrollen av serienumret (och även zonöverföringen i sig själv) är utformad för, vilket innebär att en enda central DNS-server innehar den primära versionen av databasen och alla andra DNS-servrar endast innehar kopior, stämmer helt enkelt inte överens med det paradigm som används i många moderna DNS-serverpaket. Moderna DNS-serverpaket med sofistikerade databaser som SQL-servrar och Active Directory gör det möjligt för administratörer att göra uppdateringar av databasen på flera ställen (sådana system använder sig av replikering med flera huvudmän), där databasens egen replikeringsmekanism sköter replikeringen till alla andra servrar. Detta paradigm stämmer helt enkelt inte överens med ett enda centralt, monotont ökande nummer för att registrera ändringar, och är därför i stor utsträckning oförenligt med zonöverföring. Moderna DNS-serverpaket med sofistikerade databaser skapar ofta ett ”shim”-serienummer som simulerar förekomsten av en enda central plats där uppdateringar görs, men detta är i bästa fall ofullständigt.
Tyvärr, av detta och flera skäl som beskrivs senare, använder DNS-servrar som använder sådana sofistikerade databas-bakändar i allmänhet sällan zonöverföring som mekanism för replikering av databaser i första hand, och använder i stället vanligtvis de mycket överlägsna distribuerade mekanismerna för replikering av databaser som bakändarna själva tillhandahåller.
Jämförelser av serienummerRedigera
För jämförelser av serienummer är det tänkt att man ska använda aritmetik med serienummer enligt definitionen i RFC 1982. Detta specificerades dock inte tydligt i RFC 1034, vilket leder till att alla klienter inte utför serienummerkontrollen, i ingressen, på samma sätt. Vissa klienter kontrollerar endast att det serienummer som tillhandahålls av servern skiljer sig från det som klienten känner till, eller att det inte är noll. Andra klienter kontrollerar att det serienummer som tillhandahålls av servern ligger inom ett visst intervall av det serienummer som klienten redan känner till. Ytterligare andra klienter utför fortfarande den sistnämnda kontrollen och kontrollerar dessutom att det serienummer som tillhandahålls av servern inte är noll.
Flera resursposterRedigera
I den faktiska dataöverföringen överfördes ursprungligen varje uppsättning resursposter för ett enskilt domännamn och en enskild typ i ett separat svarsmeddelande från servern till klienten. Detta är dock ineffektivt, och vissa DNS-serverprogram har genomfört optimeringar som syftar till att låta svarskomprimeringsmekanismen i DNS-protokollet minska de totala bandbreddskraven för dataöverföringar, t.ex:
- genomföra ”additional section processing” för att inkludera alla ”glue”-resurspostuppsättningar i samma svar som en NS, SRV eller MX-resurspostuppsättning
- samla alla resurspostuppsättningar som rör ett enskilt domännamn tillsammans och skicka dem, om de passar, i ett enda svar
Vissa klienter har skrivits så att de förväntar sig endast det ursprungliga svarsformatet, och de skulle misslyckas med att utföra dataöverföring om sådana optimeringar användes. Flera DNS-serverpaket har därför en konfigurationsinställning som gör det möjligt för administratörer att ange användningen av svar i ”enkelt svarsformat” för de klienter som kräver det.
Exponering av dataRedigera
Data som finns i en DNS-zon kan vara känsliga ur en driftssäkerhetsaspekt. Detta beror på att information som värdnamn på servrar kan bli allmänt känd, vilket kan användas för att ta reda på information om en organisation och till och med ge en större angreppsyta. I juni 2017 aktiverade den registrator som ansvarar för ryska toppdomäner oavsiktligt DNS-zonöverföringar via AXFR, vilket ledde till att 5,6 miljoner poster oavsiktligt exponerades.
I 2008 beslutade en domstol i North Dakota, USA, att det är en överträdelse av lagen i North Dakota att utföra en zonöverföring som en obehörig utomstående för att erhålla information som inte var allmänt tillgänglig.