Zmiany numeru seryjnegoEdit
Część preambuły transferu strefy polega na numerze seryjnym, i tylko na numerze seryjnym, w celu określenia, czy dane strefy uległy zmianie, a zatem czy wymagany jest rzeczywisty transfer danych. W przypadku niektórych pakietów serwerów DNS, numery seryjne rekordów zasobów SOA są utrzymywane przez administratorów ręcznie. Każda edycja w bazie danych wymaga dokonania dwóch zmian, jednej w zmienianym rekordzie, a drugiej w numerze seryjnym strefy. Proces ten wymaga dokładności: administrator może zapomnieć o zmianie numeru seryjnego lub zmienić go niepoprawnie (zmniejszyć go). RFC 1912 (sekcja 2.2 Rekordy SOA) zaleca użycie wartości YYYYMMDDnn jako numeru (YYYY=rok, MM=miesiąc, DD=dzień, nn=numer rewizji). Nie przepełni się to do roku 4294.
Niektóre pakiety serwerów DNS przezwyciężyły ten problem przez automatyczne konstruowanie numeru seryjnego ze znacznika czasu ostatniej modyfikacji pliku bazy danych na dysku. Tak jest w przypadku djbdns, na przykład. System operacyjny zapewnia, że znacznik czasu ostatniej modyfikacji jest uaktualniany za każdym razem, gdy administrator edytuje plik bazy danych, efektywnie automatycznie uaktualniając numer seryjny, a tym samym uwalniając administratorów od potrzeby dokonywania dwóch edycji (w dwóch różnych miejscach) dla każdej pojedynczej zmiany.
Ponadto, paradygmat replikacji bazy danych, dla którego zaprojektowano sprawdzanie numeru seryjnego (i w istocie samo przesyłanie stref), który obejmuje pojedynczy centralny serwer DNS przechowujący podstawową wersję bazy danych, a wszystkie inne serwery DNS jedynie przechowują kopie, po prostu nie pasuje do wielu nowoczesnych pakietów serwerów DNS. Nowoczesne pakiety serwerów DNS wyposażone w zaawansowane zaplecze bazodanowe, takie jak serwery SQL czy Active Directory, pozwalają administratorom na dokonywanie aktualizacji bazy danych w wielu miejscach (systemy takie wykorzystują replikację typu multi-master), przy czym własny mechanizm replikacji zaplecza bazodanowego obsługuje replikację do wszystkich pozostałych serwerów. Ten paradygmat po prostu nie pasuje do pojedynczego, centralnego, monotonicznie rosnącego numeru do rejestrowania zmian, a zatem jest w dużym stopniu niekompatybilny z transferem stref. Nowoczesne pakiety serwerów DNS z wyrafinowaną bazą danych często będą tworzyć „podkładkę” numeru seryjnego, symulując istnienie jednego centralnego miejsca, w którym dokonywane są aktualizacje, ale jest to w najlepszym przypadku niedoskonałe.
Na szczęście, z tego i kilku innych powodów przedstawionych później, serwery DNS, które używają tak wyrafinowanych back-endów baz danych w ogóle rzadko używają transferu strefy jako mechanizmu replikacji bazy danych i zazwyczaj zamiast tego stosują znacznie lepsze mechanizmy rozproszonej replikacji bazy danych, które zapewniają same back-endy.
Porównania numerów seryjnychEdit
Porównania numerów seryjnych mają na celu użycie Serial Number Arithmetic, jak zdefiniowano w RFC 1982. Jednakże, nie zostało to jasno określone w RFC 1034, co powoduje, że nie wszyscy klienci wykonują sprawdzanie numeru seryjnego w preambule w ten sam sposób. Niektórzy klienci sprawdzają jedynie, czy numer seryjny dostarczony przez serwer jest inny niż ten znany klientowi lub niezerowy. Other clients check that the serial number supplied by the server is within a given range of the serial number already known by the client. Jeszcze inni klienci nadal wykonują to ostatnie sprawdzenie i dodatkowo sprawdzają, czy numer seryjny dostarczony przez serwer nie jest zerowy.
Wiele rekordów zasobówEdit
Oryginalnie, w rzeczywistym transferze danych każdy zestaw rekordów zasobów dla pojedynczej nazwy domeny i typu był przekazywany w oddzielnej wiadomości odpowiedzi od serwera do klienta. Jednak jest to nieefektywne, a niektóre oprogramowanie serwerów DNS zaimplementowało optymalizacje, ukierunkowane na umożliwienie mechanizmowi kompresji odpowiedzi w protokole DNS zmniejszenie całkowitych wymagań przepustowości transferu danych, takich jak:
- performing „additional section processing” to include any „glue” resource record sets in the same response as an NS, SRV, or MX resource record set
- collecting all of the resource record sets relating to a single domain name together and sending them, if they fit, in a single response
Some clients were written to expect only the original response format, and would fail to perform data transfer if such optimizations were employed. Kilka pakietów serwerów DNS ma więc ustawienia konfiguracyjne pozwalające administratorom określić użycie odpowiedzi w formacie „pojedynczej odpowiedzi” dla tych klientów, którzy tego wymagają.
Narażanie danychEdit
Dane zawarte w strefie DNS mogą być wrażliwe z punktu widzenia bezpieczeństwa operacyjnego. Wynika to z faktu, że informacje takie jak nazwy hostów serwerów mogą stać się wiedzą publiczną, co może zostać wykorzystane do odkrywania informacji o organizacji, a nawet stanowić większą powierzchnię ataku. W czerwcu 2017 r. rejestrator odpowiedzialny za rosyjskie domeny najwyższego poziomu przypadkowo umożliwił transfery stref DNS za pośrednictwem AXFR, co doprowadziło do przypadkowego ujawnienia 5,6 mln rekordów.
W 2008 r. sąd w Północnej Dakocie w USA orzekł, że wykonanie transferu strefy jako nieupoważniona osoba z zewnątrz w celu uzyskania informacji, które nie były publicznie dostępne, stanowi naruszenie prawa Północnej Dakoty.
.