Jak działają transfery stref AXFR
Czym jest AXFR?
AXFR (pełny transfer strefy) to mechanizm protokołu DNS, który replikuje całą strefę z serwera podstawowego na serwer wtórny. Kiedy serwer wtórny potrzebuje kopii strefy, wysyła do serwera podstawowego żądanie AXFR, a ten odpowiada wszystkimi rekordami strefy w jednym strumieniu TCP.
AXFR opisuje RFC 5936 i działa po TCP na porcie 53 — nie po UDP, bo pełna strefa zwykle nie mieści się w jednym datagramie UDP. Transfer obejmuje każdy rekord strefy: SOA, NS, A, AAAA, MX, CNAME, TXT i pozostałe. Krótko mówiąc, AXFR to sposób, w jaki wtórny serwer DNS pobiera autorytatywną kopię Twoich danych DNS i utrzymuje ją zsynchronizowaną.
Pełne i przyrostowe transfery stref DNS
Istnieją dwa rodzaje transferu strefy:
AXFR (pełny transfer): za każdym razem przesyła całą strefę. Prosty i niezawodny, ale przy dużych strefach zużywa więcej pasma.
IXFR (transfer przyrostowy, RFC 1995): przesyła tylko te rekordy, które zmieniły się od ostatniego numeru seryjnego serwera wtórnego. Znacznie wydajniejszy przy dużych strefach z częstymi, niewielkimi zmianami.
Większość oprogramowania DNS obsługuje oba rodzaje. Serwer wtórny zazwyczaj najpierw próbuje IXFR i przechodzi na AXFR, gdy serwer podstawowy nie obsługuje transferów przyrostowych, gdy żądany numer seryjny jest zbyt stary, aby wyliczyć różnicę, albo gdy dziennik IXFR serwera podstawowego został obcięty. AXFR jest więc niezawodną podstawą, która zawsze działa, a IXFR to nałożona na nią optymalizacja.
Jak działa transfer strefy DNS
Transfer strefy przebiega według tych kroków:
1. Serwer wtórny sprawdza rekord SOA na serwerze podstawowym — albo po upływie czasu odświeżania, albo gdy odbierze komunikat NOTIFY. 2. Jeśli numer seryjny SOA na serwerze podstawowym jest wyższy niż w lokalnej kopii serwera wtórnego, potrzebny jest transfer. 3. Serwer wtórny wysyła do serwera podstawowego żądanie AXFR (lub IXFR) po TCP na porcie 53. 4. Serwer podstawowy sprawdza, czy serwer wtórny ma prawo do transferu (na podstawie ACL po adresie IP lub TSIG), a jeśli tak, wysyła dane strefy. 5. Serwer wtórny zastępuje (AXFR) lub aktualizuje (IXFR) swoją lokalną kopię i zaczyna odpowiadać z nowymi danymi.
Parametry refresh, retry i expire z rekordu SOA decydują o tym, jak często serwer wtórny sprawdza aktualizacje i jak długo obsługuje strefę, gdy serwer podstawowy jest nieosiągalny.
Interwały odświeżania i ponawiania strefy DNS
Rekord SOA zawiera cztery parametry czasowe, które sterują zachowaniem transferu strefy:
Refresh: jak często serwer wtórny sprawdza aktualizacje na serwerze podstawowym (np. 3600 = co godzinę).
Retry: jak często serwer wtórny ponawia próbę, gdy serwer podstawowy jest nieosiągalny (np. 900 = co 15 minut).
Expire: jak długo serwer wtórny obsługuje strefę, gdy nie może połączyć się z serwerem podstawowym (np. 604800 = 7 dni). Po upływie tego czasu serwer wtórny przestaje odpowiadać na zapytania o strefę — dlatego długi expire chroni Cię podczas długotrwałej awarii serwera podstawowego.
Minimum TTL: czas negatywnego buforowania — jak długo resolwery przechowują w cache odpowiedź NXDOMAIN — przyjmowany jako mniejsza z dwóch wartości: tego pola i własnego TTL rekordu SOA, zgodnie z RFC 2308.
W strefach, które często się zmieniają, ustaw niższy refresh — ale gdy skonfigurujesz NOTIFY, refresh ma znacznie mniejsze znaczenie, bo zmiany rozchodzą się niemal natychmiast. W strefach stabilnych wyższe wartości ograniczają zbędny ruch.
Synchronizacja strefy DNS w czasie rzeczywistym przez NOTIFY
Zamiast czekać na upływ czasu odświeżania, serwer podstawowy od razu po zmianie strefy wysyła do swoich serwerów wtórnych komunikat NOTIFY (RFC 1996). NOTIFY mówi serwerowi wtórnemu „sprawdź teraz swój numer seryjny”, co uruchamia sprawdzenie SOA i — w razie potrzeby — transfer.
NOTIFY skraca opóźnienie między zmianą na serwerze podstawowym a jej pojawieniem się na serwerach wtórnych z minut (interwał odświeżania) do sekund.
Większość oprogramowania DNS wysyła NOTIFY automatycznie do każdego serwera wymienionego w rekordach NS strefy. Jeśli serwer wtórny nie figuruje w zbiorze rekordów NS — co jest częste, gdy korzystasz z ukrytego serwera wtórnego u dostawcy — dodaj go jako jawny cel also-notify, aby również otrzymywał wypychane aktualizacje.
Testowanie transferów stref DNS za pomocą dig
Możesz ręcznie zażądać AXFR za pomocą dig, aby potwierdzić, że transfer działa — lub sprawdzić, czy Twoja strefa nie jest niebezpiecznie wystawiona. Poproś konkretny serwer o pełną strefę:
dig AXFR example.com @ns1.example.comJeśli serwer zezwala na transfer, dig wypisze wszystkie rekordy strefy. Jeśli dostęp jest poprawnie ograniczony, zobaczysz zamiast tego:
; Transfer failed.lub połączenie, które nie zwraca żadnych rekordów. Taka odmowa to pożądany wynik dla zapytania publicznego — strefę powinny móc pobierać wyłącznie Twoje autoryzowane serwery wtórne.
Po stronie serwera wtórnego potwierdź, że po transferze numery seryjne się zgadzają:
dig SOA example.com @primary-ip +short
dig SOA example.com @secondary-ip +shortOba powinny zwrócić ten sam numer seryjny SOA. Jeśli serwer wtórny pokazuje niższy numer, transfer się nie zakończył — sprawdź NOTIFY, ACL oraz port TCP 53.
Bezpieczeństwo transferów stref DNS
AXFR ujawnia całą Twoją strefę — każdą nazwę hosta, serwer pocztowy i rekord TXT. Otwarty transfer to klasyczny błąd umożliwiający rozpoznanie infrastruktury: atakujący, który pobierze Twoją strefę, jednym żądaniem poznaje wewnętrzne nazewnictwo, hosty testowe i układ infrastruktury. Ogranicz, kto może wykonać transfer:
ACL po adresie IP: zezwalaj na AXFR tylko z adresów IP znanych serwerów wtórnych. To najczęstsza i najprostsza kontrola.
TSIG (sygnatury transakcji, RFC 8945): uwierzytelnianie kryptograficzne z użyciem współdzielonego sekretu. Silniejsze niż ACL po adresie IP, bo nie da się go obejść przez podszywanie się pod adres IP, i działa nawet wtedy, gdy adres IP serwera wtórnego się zmieni.
Reguły zapory: udostępniaj port TCP 53 wyłącznie autoryzowanym serwerom wtórnym.
Nigdy nie używaj allow-transfer { any; } (ani jego odpowiednika w PowerDNS). Przetestuj własne domeny powyższym poleceniem dig AXFR — jeśli zapytanie publiczne zwraca rekordy, Twoja strefa jest otwarta i należy ją natychmiast zabezpieczyć.
Zabezpieczanie transferów stref za pomocą TSIG
TSIG dodaje do żądań transferu podpis oparty na współdzielonym sekrecie, dzięki czemu serwer podstawowy może uwierzytelnić serwer wtórny niezależnie od jego adresu IP. Wygeneruj klucz, a następnie wskaż go na obu serwerach.
Wygeneruj klucz (narzędzia BIND):
tsig-keygen -a hmac-sha256 transfer-keyPolecenie wypisze blok klucza. Na serwerze podstawowym BIND zdefiniuj klucz i wymagaj go przy transferach:
key "transfer-key" {
algorithm hmac-sha256;
secret "BASE64_SECRET_HERE";
};
zone "example.com" {
type primary;
file "/etc/bind/zones/example.com.zone";
allow-transfer { key "transfer-key"; };
};Na serwerze wtórnym skonfiguruj tę samą nazwę klucza, algorytm i sekret, a serwer przedstawi je przy żądaniu transferu. Po obu stronach używaj tego samego materiału klucza — i nigdy nie umieszczaj sekretu w systemie kontroli wersji.
Przykłady konfiguracji transferu strefy
BIND (serwer podstawowy):
zone "example.com" {
type primary;
file "/etc/bind/zones/example.com.zone";
allow-transfer { 192.0.2.1; };
also-notify { 192.0.2.1; };
};PowerDNS (serwer podstawowy):
allow-axfr-ips=192.0.2.1/32
also-notify=192.0.2.1
disable-axfr=noZastąp 192.0.2.1 rzeczywistym adresem IP swojego wtórnego serwera DNS.
Rozwiązywanie problemów z transferami stref DNS
Transfer odrzucony: sprawdź ustawienia allow-transfer / ACL na serwerze podstawowym i upewnij się, że adres IP serwera wtórnego (lub klucz TSIG) się zgadza. Przetestuj poleceniem dig AXFR z sieci serwera wtórnego.
Przekroczenie limitu czasu połączenia: AXFR używa portu TCP 53, a nie UDP. Zapora, która otwiera tylko UDP 53 dla zwykłych zapytań, pozwoli działać rozwiązywaniu nazw, ale po cichu zepsuje transfery. Otwórz TCP 53 między serwerem podstawowym a wtórnym.
Numer seryjny się nie zwiększa: serwer podstawowy musi podnosić numer seryjny SOA przy każdej zmianie. W formacie YYYYMMDDNN pamiętaj, aby zwiększać NN przy kilku zmianach w ciągu tego samego dnia, inaczej serwer wtórny nie zauważy zmiany.
Serwer wtórny pokazuje nieaktualne dane: upewnij się, że NOTIFY jest skonfigurowany. Bez niego serwer wtórny aktualizuje się tylko co interwał refresh z rekordu SOA.
Transfer dużej strefy zawodzi: bardzo duże strefy (miliony rekordów) mogą w trakcie transferu napotkać limity czasu TCP. Zwiększ ustawienia transferu/limitów czasu po obu stronach i wybieraj IXFR, aby przesyłać tylko różnice.
Nie chcesz utrzymywać i naprawiać własnego serwera wtórnego? SecondDNS zapewnia zarządzany wtórny DNS z automatyczną synchronizacją AXFR — zacznij za darmo.
Powiązane przewodniki
Aby wykorzystać transfery stref z usługą wtórnego DNS lub panelem hostingowym, zobacz:
- Jak skonfigurować wtórny serwer DNS - Redundancja DNS: dlaczego ma znaczenie i jak ją osiągnąć - Personalizowane serwery nazw: konfiguracja, rekordy glue i pułapki - Jak dodać wtórny DNS do cPanel/WHM - Jak dodać wtórny DNS do Plesk - Jak dodać wtórny DNS do DirectAdmin - Jak dodać wtórny DNS do CyberPanel