Modificări ale numărului de serieEdit
Partea de preambul a transferului de zonă se bazează pe numărul de serie, și numai pe numărul de serie, pentru a determina dacă datele unei zone au fost modificate și, prin urmare, dacă este necesar transferul efectiv de date. Pentru unele pachete de servere DNS, numerele de serie ale înregistrărilor de resurse SOA sunt menținute manual de către administratori. Fiecare modificare a bazei de date implică efectuarea a două modificări, una la înregistrarea care se modifică și cealaltă la numărul de serie al zonei. Acest proces necesită acuratețe: administratorul poate uita să modifice numărul de serie sau îl poate modifica incorect (îl reduce). RFC 1912 (secțiunea 2.2 înregistrări SOA) recomandă utilizarea valorii YYYYMMDDnn ca număr (YYYY=an, MM=lună, DD=zi, nn=număr de revizuire). Acest lucru nu va depăși până în anul 4294.
Câteva pachete de servere DNS au depășit această problemă prin construirea automată a numărului de serie din ultima dată de modificare a fișierului de bază de date de pe disc. Acesta este cazul pentru djbdns, de exemplu. Sistemul de operare se asigură că ultimul timestamp de modificare este actualizat ori de câte ori un administrator editează fișierul bazei de date, actualizând efectiv în mod automat numărul de serie și eliberându-i astfel pe administratori de necesitatea de a face două editări (în două locuri diferite) pentru fiecare modificare.
În plus, paradigma de replicare a bazei de date pentru care este concepută verificarea numărului de serie (și, într-adevăr, transferul de zonă în sine), care implică un singur server DNS central care deține versiunea primară a bazei de date, toate celelalte servere DNS deținând doar copii, pur și simplu nu se potrivește cu cea a multor pachete de servere DNS moderne. Pachetele moderne de servere DNS cu baze de date sofisticate, cum ar fi serverele SQL și Active Directory, permit administratorilor să facă actualizări ale bazei de date în mai multe locuri (astfel de sisteme utilizează replicarea multi-master), mecanismul de replicare al bazei de date se ocupă de replicarea către toate celelalte servere. Această paradigmă pur și simplu nu se potrivește cu cea a unui număr unic, central, cu creștere monotonă, pentru a înregistra modificările și, prin urmare, este incompatibilă în mare măsură cu transferul de zone. Pachetele moderne de servere DNS cu back-end-uri sofisticate de baze de date vor crea adesea un număr de serie „shim”, simulând existența unui singur loc central în care se fac actualizările, dar acest lucru este, în cel mai bun caz, imperfect.
Din păcate, din acest motiv și din mai multe motive prezentate mai târziu, serverele DNS care folosesc în general astfel de back-end-uri de baze de date sofisticate folosesc rareori transferul de zonă ca mecanism de replicare a bazei de date, în primul rând, și de obicei folosesc în schimb mecanismele de replicare distribuită a bazei de date, net superioare, pe care le oferă chiar back-end-urile.
Compararea numerelor de serieEdit
Compararea numerelor de serie este destinată să folosească aritmetica numerelor de serie, așa cum este definită în RFC 1982. Cu toate acestea, acest lucru nu a fost specificat în mod clar în RFC 1034, ceea ce face ca nu toți clienții să efectueze verificarea numărului de serie, în preambul, în același mod. Unii clienți verifică doar dacă numărul de serie furnizat de server este diferit de cel cunoscut de client sau dacă este diferit de zero. Alți clienți verifică dacă numărul de serie furnizat de server se încadrează într-un anumit interval față de numărul de serie deja cunoscut de client. Cu toate acestea, alți clienți efectuează în continuare această ultimă verificare și verifică, în plus, dacă numărul de serie furnizat de server este diferit de zero.
Înregistrări de resurse multipleEdit
Original, în transferul efectiv de date, fiecare set de înregistrări de resurse pentru un singur nume de domeniu și tip era transferat într-un mesaj de răspuns separat de la server către client. Cu toate acestea, acest lucru este ineficient, iar unele programe de server DNS au implementat optimizări, orientate spre a permite mecanismului de comprimare a răspunsului din protocolul DNS să reducă cerințele totale de lățime de bandă ale transferurilor de date, cum ar fi:
- efectuarea unei „procesări suplimentare a secțiunii” pentru a include orice set de înregistrări de resurse „glue” în același răspuns ca un set de înregistrări de resurse NS, SRV sau MX
- colectarea tuturor seturilor de înregistrări de resurse referitoare la un singur nume de domeniu împreună și trimiterea lor, dacă se potrivesc, într-un singur răspuns
Cei mai mulți clienți au fost concepuți să se aștepte doar la formatul de răspuns original și nu ar reuși să efectueze transferul de date dacă ar fi utilizate astfel de optimizări. Prin urmare, mai multe pachete de servere DNS au o setare de configurare care permite administratorilor să specifice utilizarea răspunsurilor în „format de răspuns unic” pentru acei clienți care o cer.
Expunerea datelorEdit
Datele conținute într-o zonă DNS pot fi sensibile din punct de vedere al securității operaționale. Acest lucru se datorează faptului că informații precum numele de gazdă ale serverelor pot deveni de notorietate publică, ceea ce poate fi folosit pentru a descoperi informații despre o organizație și chiar pentru a oferi o suprafață de atac mai mare. În iunie 2017, registratorul responsabil pentru domeniile de nivel superior din Rusia a activat din greșeală transferurile de zone DNS prin AXFR, ceea ce a dus la expunerea accidentală a 5,6 milioane de înregistrări.
În 2008, o instanță din Dakota de Nord, SUA, a decis că efectuarea unui transfer de zonă în calitate de persoană neautorizată din exterior pentru a obține informații care nu erau accesibile publicului constituie o încălcare a legii din Dakota de Nord.
.