Změny sériového číslaUpravit
Předchozí část přenosu zóny se spoléhá na sériové číslo a pouze na sériové číslo, aby bylo možné určit, zda se data zóny změnila, a zda je tedy nutné provést vlastní přenos dat. U některých balíčků serverů DNS udržují sériová čísla záznamů o prostředcích SOA správci ručně. Každá úprava v databázi zahrnuje provedení dvou změn, jedné ve měněném záznamu a druhé v sériovém čísle zóny. Tento proces vyžaduje přesnost: správce může zapomenout sériové číslo změnit nebo ho změnit nesprávně (snížit). RFC 1912 (oddíl 2.2 Záznamy SOA) doporučuje používat jako číslo hodnotu RRRRMMDDnn (RRRR = rok, MM = měsíc, DD = den, nn = číslo revize). Tím se nepřekročí rok 4294.
Některé balíky serverů DNS tento problém překonaly automatickou konstrukcí pořadového čísla z časového razítka poslední modifikace databázového souboru na disku. To je například případ balíku djbdns. Operační systém zajišťuje, že časové razítko poslední změny je aktualizováno vždy, když správce upravuje databázový soubor, čímž se sériové číslo skutečně automaticky aktualizuje, a správci tak nemusí provádět dvě úpravy (na dvou různých místech) pro každou jednotlivou změnu.
Kromě toho paradigma replikace databáze, pro které je kontrola sériového čísla (a vlastně i samotný přenos zóny) navržena a které zahrnuje jeden centrální server DNS s primární verzí databáze a všechny ostatní servery DNS pouze s kopiemi, jednoduše neodpovídá paradigmatu mnoha moderních balíčků serverů DNS. Moderní balíčky serverů DNS se sofistikovanými databázovými koncovkami, jako jsou servery SQL a Active Directory, umožňují správcům provádět aktualizace databáze na více místech (takové systémy používají replikaci na více serverů), přičemž replikaci na všechny ostatní servery zajišťuje vlastní replikační mechanismus databázové koncovky. Toto paradigma jednoduše neodpovídá paradigmatu jediného centrálního, monotónně rostoucího čísla pro záznam změn, a proto je do značné míry neslučitelné s přenosem zón. Moderní balíky serverů DNS s propracovaným databázovým zázemím často vytvoří „shim“ pořadové číslo, které simuluje existenci jediného centrálního místa, kde se aktualizace provádějí, ale to je přinejlepším nedokonalé.
Naštěstí z tohoto důvodu a z několika důvodů uvedených později servery DNS, které používají takové sofistikované databázové back endy, obecně zřídkakdy používají přenos zóny jako mechanismus replikace databáze na prvním místě a obvykle místo toho používají mnohem lepší mechanismy distribuované replikace databáze, které poskytují samotné back endy.
Porovnávání sériových číselUpravit
Při porovnávání sériových čísel se má používat aritmetika sériových čísel definovaná v RFC 1982. To však nebylo v RFC 1034 jasně specifikováno, což má za následek, že ne všichni klienti provádějí kontrolu sériového čísla, v preambuli, stejným způsobem. Někteří klienti kontrolují pouze to, zda se sériové číslo poskytnuté serverem liší od čísla známého klientovi nebo zda není nulové. Jiní klienti kontrolují, zda je sériové číslo dodané serverem v daném rozsahu sériového čísla, které již klient zná. Jiní klienti ještě provádějí druhou kontrolu a navíc kontrolují, zda sériové číslo dodané serverem není nulové.
Více záznamů o prostředcíchUpravit
Původně se při skutečném přenosu dat každá sada záznamů o prostředcích pro jedno doménové jméno a typ přenášela v samostatné zprávě odpovědi ze serveru klientovi. To je však neefektivní a některé softwary serverů DNS implementovaly optimalizace zaměřené na to, aby mechanismus komprese odpovědí v protokolu DNS snížil celkové požadavky na šířku pásma při přenosu dat, jako např:
- provádění „dodatečného zpracování sekcí“ pro zahrnutí všech „lepených“ sad záznamů o prostředcích do stejné odpovědi jako sada záznamů o prostředcích NS, SRV nebo MX
- shromáždění všech sad záznamů o prostředcích týkajících se jednoho doménového jména dohromady a jejich odeslání, pokud se vejdou, v jediné odpovědi
Někteří klienti byli napsáni tak, aby očekávali pouze původní formát odpovědi a v případě použití takových optimalizací by přenos dat neprovedli. Některé balíčky serverů DNS proto obsahují konfigurační nastavení umožňující správcům určit použití odpovědí ve formátu „jediné odpovědi“ pro ty klienty, kteří to vyžadují.
Vystavení datUpravit
Data obsažená v zóně DNS mohou být citlivá z hlediska bezpečnosti provozu. Je to proto, že informace, jako jsou názvy hostitelů serverů, se mohou stát veřejně známými, což může být využito ke zjištění informací o organizaci a dokonce poskytnout větší plochu pro útoky. V červnu 2017 registrátor odpovědný za ruské domény nejvyšší úrovně omylem umožnil přenosy zón DNS prostřednictvím AXFR, což vedlo k náhodnému odhalení 5,6 milionu záznamů.
V roce 2008 soud v Severní Dakotě v USA rozhodl, že provedení přenosu zóny jako neoprávněná osoba zvenčí za účelem získání informací, které nejsou veřejně přístupné, představuje porušení zákona Severní Dakoty.