Přenos zóny DNS , AXFR je typ transakce DNS . Je to jeden z mechanismů pro replikaci databází DNS mezi servery. Existují dva typy zónového přenosu: plný (AXFR RFC 1035 ) a přírůstkový (IXFR RFC 1995 ). Byl velmi rozšířený, ale na moderních serverech je DNS nahrazováno jinými replikačními mechanismy.
Zónový přenos funguje nad protokolem TCP a jedná se o transakci klient-server . Účastní se ho slave server neboli anglicky. slave , požadující přenos části dat z databáze, a master server (nazývaný také server primární zóny), nebo anglicky. master , který poskytuje tato data. V některých zdrojích se nazývají sekundární a primární servery. Součástí přenášených dat je DNS zóna.
Tato transakce se skládá z preambule a samotného přenosu dat. Během preambule je záznam SOA (autoritativní zdroj) vyhledán na začátku zóny ( anglicky zone apex ) - horní uzel jmenného prostoru této zóny. Pole v tomto záznamu SOA, konkrétně sériové číslo, určují, zda je přenos zóny vůbec potřeba. Klient porovná sériové číslo přijatého záznamu SOA s tím, které již má. Pokud je nové číslo položky vyšší, pak se obsah zóny do určité míry změnil a klient požaduje skutečný přenos zóny. Pokud jsou sériová čísla stejná, bude obsah zóny považován za nezměněný a klient může nadále používat existující kopii dat.
Na začátku vlastního přenosu dat klient odešle přes TCP spojení požadavek (opcode 0) speciálního typu AXFR (QTYPE AXFR = 252). Server v odpovědi postupně odesílá zprávy se všemi záznamy prostředků zóny. První zpráva obsahuje SOA záznam začátku zóny. Zbývající zprávy nejsou seřazeny. Signál konce přenosu je opětovné odeslání záznamu SOA.
Někteří klienti provádějí vyhledávání SOA prostřednictvím standardního mechanismu rozlišení názvů. Nevytvoří TCP spojení se serverem, dokud nezjistí, že skutečný přenos je nezbytný. Protože však TCP lze použít jak pro běžné transakce DNS, tak pro zónové přenosy, ostatní klienti vyřeší záznam SOA v preambuli přes stejné připojení, které by mohli použít pro skutečný přenos. Takoví klienti navazují TCP spojení ze serveru ještě před zahájením preambule.
Principy úplného převodu jsou uvedeny výše. Přírůstkový přenos zóny se liší takto:
Přenos zóny zahájí pouze klient. Server MŮŽE odeslat zprávu NOTIFY klientům, které zná, když došlo ke změně v zóně, ale plánování přenosu je zcela na klientovi. Přenos zóny může spustit klient, pokud jsou jeho databáze prázdné, a poté podle plánu určeného na základě polí obnovení, opakování a vypršení platnosti v záznamu SOA spuštění zóny.
Přestože je úplný přenos standardizován a popsán jako jeden z možných replikačních mechanismů v RFC 1034 (přírůstkový přenos v RFC 1995 ), zónový přenos je nejméně funkční způsob replikace databází. Přenos záznamů je „neinteligentní“, tj. používá stejný protokol jako běžný překlad DNS jmen. Nebere v úvahu základní schéma databáze používané back -endem samotných serverů DNS.
Preambule zónového přenosu spoléhá pouze na sériové číslo k určení, zda se data zóny změnila a zda je nutný skutečný přenos. Na některých serverech DNS musí sériová čísla SOA upravit ručně správci. Každá změna databáze vyžaduje dvě úpravy: samotný záznam a sériové číslo zóny. Proces vyžaduje přesnost: správce může zapomenout změnit sériové číslo nebo jej změnit nesprávně (snížit). RFC 1912 (oddíl 2.2 záznamy SOA) doporučuje jako číslo použít hodnotu ve tvaru RRRRMMDDnn (RRRR=rok, MM=měsíc, DD=den, nn=verze změny dne). Tento formát vám umožňuje používat číslo až do roku 4294 a provádět 100 změn za den (nn od 00 do 99), což vám dává kontrolu nad datem poslední změny.
změny souboru na disku Tedy zejména djbdns . Operační systém sleduje aktualizaci data změny souboru, v podstatě automatizuje výpočet čísla a zbavuje administrátora nutnosti každé druhé úpravy.
Moderní servery se složitými back-endy, jako je SQL a Active Directory , umožňují správcům upravovat více webů současně (systémy s replikací více hlavních serverů), kde replikace na jiné servery zpracovává samotná podkladová databáze, to však může fungovat pouze tehdy, když všechny DNS zóny jsou pod jedinou kontrolou. Takový model neodpovídá jedinému centralizovanému monotónně rostoucímu záznamu změn, a proto není obecně kompatibilní se zónovým převodem. Moderní DNS servery se složitými back-endy v databázích často vytvářejí „imaginární“ sériové číslo, které předstírají, že mají centralizovaný zdroj aktualizací, ale to je přinejmenším nedokonalé.
Z těchto a dalších důvodů DNS servery se složitými databázovými back-endy jen zřídka používají zónové přenosy pro replikaci, takže úkol přenechávají mnohem efektivnější interní databázové mechanismy.
Porovnání sériových čísel zahrnuje použití aritmetiky sériových čísel (např. aby se předešlo problému s rokem 2000 ) podle RFC 1982 . To však nebylo jasně uvedeno v RFC 1034 a v důsledku toho klienti porovnávají čísla preambule odlišně. Někteří se pouze ujišťují, že přijaté číslo je jiné než stávající nebo nenulové. Ostatní kontrolují, zda je přijaté číslo v daném intervalu od stávajícího. Ostatní také dělají kontrolu na nulu.
Zpočátku, při skutečném přenosu dat, byla každá položka pro každý název domény a typ přenesena ze serveru na klienta v samostatné zprávě. To bylo neefektivní a některé servery DNS optimalizovaly proces, aby snížily režii šířky pásma prostřednictvím kompresních mechanismů v protokolu DNS, jako například:
Někteří klienti očekávali pouze původní formát odpovědi a takto optimalizovaná data nemohli přijmout. S ohledem na tuto skutečnost byly jednotlivé servery DNS nakonfigurovány tak, aby těmto klientům odesílaly „odpovědi v jediném formátu“.
Informace obsažené v zóně DNS lze z hlediska provozní bezpečnosti považovat za důvěrné. Záznamy prostředků mohou například obsahovat informace o roli serveru nebo otisky klíčů SSH ( RFC 4255 ).
V roce 2008 soud v Severní Dakotě v USA rozhodl, že neoprávněný převod soukromé oblasti iniciovaný osobou zvenčí byl porušením státního práva.