SerienummerwijzigingenEdit
Het preambule-gedeelte van de zoneoverdracht vertrouwt op het serienummer, en alleen het serienummer, om te bepalen of de gegevens van een zone zijn gewijzigd, en dus of de eigenlijke gegevensoverdracht is vereist. Voor sommige DNS-serverpakketten worden de serienummers van SOA-resourcederecords door beheerders met de hand bijgehouden. Elke wijziging in de database houdt in dat er twee wijzigingen moeten worden aangebracht, een in de record die wordt gewijzigd en de andere in het serienummer van de zone. Dit proces vereist nauwkeurigheid: de beheerder kan vergeten het serienummer te wijzigen of het op onjuiste wijze wijzigen (verkleinen). RFC 1912 (sectie 2.2 SOA records) beveelt aan om de waarde YYYYMMDDnn als nummer te gebruiken (YYYY=jaar, MM=maand, DD=dag, nn=revisienummer). Dit zal niet overlopen tot het jaar 4294.
Sommige DNS server pakketten hebben dit probleem ondervangen door automatisch het serienummer te construeren uit de laatste modificatie timestamp van het database bestand op schijf. Dit is bijvoorbeeld het geval voor djbdns. Het besturingssysteem zorgt ervoor dat de laatste wijzigingstijdstempel wordt bijgewerkt telkens wanneer een beheerder het databasebestand bewerkt, waardoor het serienummer automatisch wordt bijgewerkt en beheerders niet voor elke wijziging twee bewerkingen hoeven uit te voeren (op twee verschillende plaatsen).
Daarnaast komt het paradigma van databasereplicatie waarvoor de serienummercontrole (en ook de zoneoverdracht zelf) is ontworpen, waarbij één centrale DNS-server de primaire versie van de database bewaart en alle andere DNS-servers slechts kopieën bewaren, gewoon niet overeen met dat van veel moderne DNS-serverpakketten. Moderne DNS-serverpakketten met geavanceerde database back-ends zoals SQL-servers en Active Directory staan beheerders toe om updates van de database op meerdere plaatsen uit te voeren (dergelijke systemen maken gebruik van multi-master replicatie), waarbij het eigen replicatiemechanisme van de database back-end de replicatie naar alle andere servers afhandelt. Dit paradigma komt eenvoudigweg niet overeen met dat van een enkel, centraal, monotoon toenemend aantal om wijzigingen vast te leggen, en is dus grotendeels onverenigbaar met zoneoverdracht. Moderne DNS-serverpakketten met geavanceerde database back-ends zullen vaak een “shim” serienummer creëren, waarmee het bestaan van één centrale plaats waar updates worden gemaakt, wordt gesimuleerd, maar dit is op zijn best onvolmaakt.
Gelukkig genoeg gebruiken DNS-servers die zulke geavanceerde database back-ends gebruiken in het algemeen zelden zone transfer als hun database replicatie mechanisme, en gebruiken in plaats daarvan meestal de enorm superieure gedistribueerde database replicatie mechanismen die de back-ends zelf bieden.
Serienummer vergelijkingenEdit
Serienummer vergelijkingen zijn bedoeld om Serial Number Arithmetic te gebruiken zoals gedefinieerd in RFC 1982. Dit werd echter niet duidelijk gespecificeerd in RFC 1034, met als gevolg dat niet alle clients de serienummercontrole, in de preamble, op dezelfde manier uitvoeren. Sommige cliënten controleren alleen of het serienummer dat door de server wordt aangeleverd verschillend is van het serienummer dat bekend is bij de cliënt, of niet nul is. Andere cliënten controleren of het door de server geleverde serienummer binnen een bepaald bereik ligt van het serienummer dat reeds bekend is bij de cliënt. Weer andere clienten voeren deze laatste controle uit en controleren bovendien of het door de server verstrekte serienummer niet nul is.
Meervoudige resource recordsEdit
Originally, in the actual data transfer each set of resource records for a single domain name and type was transferred in a separate response message from the server to the client. Dit is echter inefficiënt, en sommige DNS-serversoftware heeft optimalisaties geïmplementeerd, gericht op het toestaan van het responscompressiemechanisme in het DNS-protocol om de totale bandbreedtevereisten van gegevensoverdrachten te verminderen, zoals:
- het uitvoeren van “extra sectieverwerking” om alle “glue” resource record sets in hetzelfde antwoord op te nemen als een NS, SRV, of MX resource record set
- het verzamelen van alle resource record sets met betrekking tot een enkele domeinnaam samen en het verzenden daarvan, als ze passen, in een enkel antwoord
Sommige clients werden geschreven om alleen het originele responsformaat te verwachten, en zouden de gegevensoverdracht niet uitvoeren als dergelijke optimalisaties werden toegepast. Verscheidene DNS-serverpakketten hebben daarom een configuratie-instelling waarmee beheerders het gebruik van antwoorden in “enkel antwoordformaat” kunnen specificeren voor die clients die dit vereisen.
Blootstelling van gegevensEdit
De gegevens in een DNS-zone kunnen gevoelig zijn vanuit een operationeel beveiligingsaspect. Dit komt omdat informatie zoals serverhostnamen openbaar bekend kan worden, wat kan worden gebruikt om informatie over een organisatie te ontdekken en zelfs een groter aanvalsoppervlak kan bieden. In juni 2017 heeft de registrar die verantwoordelijk is voor Russische topleveldomeinen per ongeluk DNS-zoneoverdrachten via AXFR ingeschakeld, waardoor 5,6 miljoen records per ongeluk bloot kwamen te liggen.
In 2008 oordeelde een rechtbank in North Dakota (VS) dat het uitvoeren van een zoneoverdracht als onbevoegde buitenstaander om informatie te verkrijgen die niet openbaar toegankelijk was, een overtreding van de wet van North Dakota vormt.