Ændring af serienummerRediger
Den indledende del af zoneoverførslen er afhængig af serienummeret, og kun serienummeret, for at afgøre, om en zones data er ændret, og dermed om den egentlige dataoverførsel er nødvendig. For nogle DNS-serverpakker vedligeholdes serienumrene for SOA-ressourceposter manuelt af administratorer. Hver ændring i databasen indebærer to ændringer, en i den post, der ændres, og en i zonens serienummer. Denne proces kræver nøjagtighed: administratoren kan glemme at ændre serienummeret eller ændre det forkert (reducere det). I RFC 1912 (afsnit 2.2 SOA-poster) anbefales det at bruge værdien YYYYYYMMDDnn som nummer (YYYYY=år, MM=måned, DD=dag, nn=revisionsnummer). Dette vil ikke overløbe før år 4294.
Nogle DNS-serverpakker har overvundet dette problem ved automatisk at konstruere serienummeret ud fra det sidste ændringstidsstempel i databasefilen på disken. Dette er f.eks. tilfældet for djbdns. Operativsystemet sørger for, at det sidste ændringstidsstempel opdateres, når en administrator redigerer databasefilen, hvorved serienummeret opdateres automatisk, og administratorer slipper for at skulle foretage to redigeringer (to forskellige steder) for hver enkelt ændring.
Dertil kommer, at det paradigme for databasereplikering, som kontrollen af serienummeret (og faktisk selve zoneoverførslen) er designet til, og som indebærer, at en enkelt central DNS-server har den primære version af databasen, mens alle andre DNS-servere blot har kopier, ganske enkelt ikke passer til det paradigme, som mange moderne DNS-serverpakker har. Moderne DNS-serverpakker med sofistikerede database-backends som f.eks. SQL-servere og Active Directory giver administratorer mulighed for at foretage opdateringer af databasen flere steder (sådanne systemer anvender multi-master-replikation), hvor database-backend’ens egen replikationsmekanisme håndterer replikationen til alle andre servere. Dette paradigme passer simpelthen ikke til et enkelt, centralt, monotont stigende antal til at registrere ændringer, og er derfor i vid udstrækning uforeneligt med zoneoverførsel. Moderne DNS-serverpakker med sofistikerede database-backends vil ofte oprette et “shim”-serienummer, som simulerer eksistensen af et enkelt centralt sted, hvor opdateringer foretages, men dette er i bedste fald ufuldstændigt.
Godt nok bruger DNS-servere, der anvender sådanne sofistikerede database-backends generelt sjældent zoneoverførsel som deres databasereplikeringsmekanisme i første omgang, og anvender normalt i stedet de langt overlegne distribuerede databasereplikeringsmekanismer, som backendene selv leverer.
Serienummer-sammenligningerRediger
Serienummer-sammenligninger er beregnet til at anvende Serial Number Arithmetic som defineret i RFC 1982. Dette blev imidlertid ikke klart specificeret i RFC 1034, hvilket resulterer i, at ikke alle klienter udfører serienummerkontrollen i præamblen på samme måde. Nogle klienter kontrollerer blot, at det serienummer, der leveres af serveren, er forskelligt fra det, som klienten kender, eller at det er ikke nul. Andre klienter kontrollerer, at det serienummer, der leveres af serveren, ligger inden for et bestemt interval af det serienummer, som klienten allerede kender. Endnu andre klienter foretager stadig sidstnævnte kontrol og kontrollerer desuden, at det serienummer, som serveren har leveret, ikke er nul.
Flere ressourceposterRediger
I den egentlige dataoverførsel blev hvert sæt ressourceposter for et enkelt domænenavn og en enkelt type oprindeligt overført i en separat svarmeddelelse fra serveren til klienten. Dette er imidlertid ineffektivt, og nogle DNS-serverprogrammer har implementeret optimeringer, der har til formål at gøre det muligt for svarkomprimeringsmekanismen i DNS-protokollen at reducere de samlede båndbreddekrav for dataoverførsler, f.eks:
- udførelse af “additional section processing” for at inkludere eventuelle “glue”-ressourcepostsæt i det samme svar som et NS, SRV eller MX ressourcepostsæt
- samle alle ressourcepostsæt vedrørende et enkelt domænenavn sammen og sende dem, hvis de passer, i et enkelt svar
En del klienter blev skrevet til kun at forvente det oprindelige svarformat og ville ikke kunne gennemføre dataoverførsel, hvis sådanne optimeringer blev anvendt. Flere DNS-serverpakker har derfor en konfigurationsindstilling, der gør det muligt for administratorer at angive brugen af svar i “enkelt svarformat” for de klienter, der kræver det.
Eksponering af dataRediger
Den data, der er indeholdt i en DNS-zone, kan være følsomme ud fra et operationelt sikkerhedsaspekt. Det skyldes, at oplysninger som f.eks. serverværtsnavne kan blive offentligt kendt, hvilket kan bruges til at finde oplysninger om en organisation og endda give en større angrebsflade. I juni 2017 aktiverede den registrator, der er ansvarlig for russiske top-level-domæner, ved et uheld DNS-zoneoverførsler via AXFR, hvilket førte til, at 5,6 millioner poster ved et uheld blev eksponeret.
I 2008 fastslog en domstol i North Dakota, USA, at det udgør en overtrædelse af North Dakota-loven at udføre en zoneoverførsel som en uautoriseret outsider for at opnå oplysninger, der ikke var offentligt tilgængelige.