Transfer de zonă DNS , AXFR este un tip de tranzacție DNS . Este unul dintre mecanismele de replicare a bazelor de date DNS între servere. Există două tipuri de transfer de zonă: complet (AXFR RFC 1035 ) și incremental (IXFR RFC 1995 ). Era foarte răspândit, dar în serverele moderne DNS este înlocuit de alte mecanisme de replicare.
Un transfer de zonă funcționează pe lângă protocolul TCP și este o tranzacție client-server . Este frecventat de un server slave, sau engleză. slave , solicitând transferul unei părți a datelor din baza de date și serverul master (numit și server de zonă primară), sau engleză. master care furnizează aceste date. În unele surse ele sunt numite servere secundare și, respectiv, primare. Partea datelor transferate este zona DNS.
Această tranzacție constă dintr-un preambul și transferul de date în sine. În timpul preambulului, înregistrarea SOA (sursa autorizată) este căutată la începutul zonei ( în engleză zone apex ) - nodul superior al spațiului de nume al acestei zone. Câmpurile din această înregistrare SOA, în special numărul de serie, determină dacă este necesar un transfer de zonă. Clientul compară numărul de serie al înregistrării SOA primite cu cel pe care îl are deja. Dacă noul număr de intrare este mai mare, atunci conținutul zonei s-a schimbat într-o oarecare măsură, iar clientul solicită un transfer efectiv de zonă. Dacă numerele de serie sunt aceleași, atunci conținutul zonei este considerat neschimbat, iar clientul poate continua să utilizeze copia existentă a datelor.
La începutul transferului efectiv de date, clientul trimite o cerere (opcode 0) de tip special AXFR (QTYPE AXFR = 252) prin conexiunea TCP. Serverul ca răspuns trimite secvenţial mesaje cu toate înregistrările de resurse ale zonei. Primul mesaj conține înregistrarea SOA a începutului zonei. Restul mesajelor nu sunt sortate. Semnalul de sfârșit de transmisie este o retrimitere a înregistrării SOA.
Unii clienți efectuează căutări SOA prin mecanismul standard de rezoluție a numelor. Ei nu stabilesc o conexiune TCP la server până când nu stabilesc că transferul real este necesar. Cu toate acestea, deoarece TCP poate fi utilizat atât pentru tranzacții DNS obișnuite, cât și pentru transferuri de zonă, alți clienți vor rezolva înregistrarea SOA în preambul prin aceeași conexiune pe care ar putea -o folosi pentru transferul real. Astfel de clienți stabilesc o conexiune TCP de la server chiar înainte de a începe preambulul.
Principiile transferului complet sunt prezentate mai sus. Transferul de zonă incremental diferă după cum urmează:
Doar clientul inițiază un transfer de zonă. Un server POATE trimite un mesaj NOTIFY clienților cunoscuți atunci când a existat o schimbare în zonă, dar programarea transmisiei depinde în întregime de client. Un transfer de zonă poate fi declanșat de un client dacă bazele de date ale acestuia sunt goale și apoi pe o programare determinată pe baza câmpurilor de reîmprospătare, reîncercare și expirare din înregistrarea SOA de pornire a zonei.
Deși transferul complet este standardizat și descris ca unul dintre posibilele mecanisme de replicare în RFC 1034 (transfer incremental în RFC 1995 ), transferul de zonă este cel mai puțin funcțional mod de a replica bazele de date. Transferul înregistrărilor este „neinteligent”, adică utilizează același protocol ca rezoluția normală a numelor DNS. Nu ține cont de schema bazei de date de bază utilizată de back-end -ul serverelor DNS în sine.
Preambulul de transfer de zonă se bazează numai pe numărul de serie pentru a determina dacă datele de zonă s-au schimbat și dacă este necesar un transfer real. În unele servere DNS, numerele de serie SOA trebuie editate manual de către administratori. Fiecare modificare a bazei de date necesită două editări: înregistrarea în sine și numărul de serie al zonei. Procesul necesită acuratețe: administratorul poate uita să schimbe numărul de serie sau să-l schimbe incorect (redu-l). RFC 1912 (Secțiunea 2.2 Înregistrări SOA) recomandă utilizarea unei valori de forma AAAAMMDDnn (AAAA=an, LL=lună, ZZ=zi, nn= versiunea de modificare a zilei) ca număr. Acest format vă permite să utilizați un număr până la anul 4294 și să efectuați 100 de modificări pe zi (nn de la 00 la 99), oferindu-vă control asupra datei ultimei modificări.
Unele servere rezolvă această problemă calculând automat numărul de serie pe baza ultimei date modificate a fișierului de pe disc Deci, în special, djbdns . Sistemul de operare ține evidența actualizării datei modificării fișierului, automatizează în esență calculul numărului și eliberează administratorul de nevoia pentru fiecare a doua editare.
Serverele moderne cu back-end complexe, cum ar fi SQL și Active Directory, permit administratorilor să editeze mai multe site-uri în același timp (sisteme cu replicare multi-master ) în care baza de date de bază se ocupă însăși de replicarea către alte servere, totuși aceasta poate funcționa numai atunci când toate DNS -urile zonele sunt sub control unic. Un astfel de model nu corespunde unei singure înregistrări centralizate monoton a modificărilor și, prin urmare, nu este în general compatibil cu un transfer de zonă. Serverele DNS moderne cu back-end complexe pe baze de date creează adesea un număr de serie „imaginar”, pretinzând că au o sursă centralizată de actualizări, dar aceasta este cel puțin imperfectă.
Din aceste motive și din alte motive, serverele DNS cu back-end-uri complexe de baze de date folosesc rareori transferuri de zonă pentru replicare, lăsând sarcina unor mecanisme interne de baze de date mult mai eficiente.
Compararea numărului de serie implică utilizarea aritmeticii numerelor de serie (de exemplu, pentru a evita problema anului 2000 ) conform RFC 1982 . Cu toate acestea, acest lucru nu a fost precizat clar în RFC 1034 și, ca rezultat, clienții compară diferit numerele de preambul. Unii se asigură doar că numărul primit este diferit de cel existent sau nu este zero. Alții verifică dacă numărul primit se află într-un interval dat față de cel existent. Alții fac și o verificare pentru zero.
Inițial, la transferul efectiv al datelor, fiecare intrare pentru fiecare nume și tip de domeniu a fost transferată de la server la client într-un mesaj separat. Acest lucru a fost ineficient, iar unele servere DNS au optimizat procesul pentru a reduce supraîncărcarea lățimii de bandă prin mecanisme de compresie în protocolul DNS, cum ar fi:
Unii clienți se așteptau doar la formatul original de răspuns și nu puteau accepta date optimizate în acest fel. Având în vedere acest lucru, serverele DNS individuale au fost configurate pentru a trimite „răspunsuri în format unic” unor astfel de clienți.
Informațiile conținute într-o zonă DNS pot fi considerate confidențiale din punct de vedere al securității operaționale. De exemplu, înregistrările de resurse pot conține informații despre rolul serverului sau amprentele cheilor SSH ( RFC 4255 ).
În 2008, o instanță din Dakota de Nord, SUA, a decis că un transfer neautorizat al unei zone private inițiat de un străin a fost o încălcare a legii statului.