Klucze TSIG na Twoim podstawowym serwerze DNS: BIND, PowerDNS, NSD i Knot

Czego potrzebujesz

Klucz TSIG podpisuje każdy transfer strefy między Twoim serwerem podstawowym a naszymi serwerami wtórnymi. Serwer podstawowy uwierzytelnia wtedy nasze serwery kluczem, a nie ich adresami IP.

Z panelu SecondDNS potrzebujesz trzech rzeczy:

1. Klucza. Utwórz go w Ustawienia › DNS. Okno pokazuje nazwę klucza, algorytm (hmac-sha256 lub hmac-sha512) i sekret. Sekret jest pokazywany tylko raz: skopiuj go przed zamknięciem okna. Jeśli go zgubisz, wygeneruj klucz ponownie. 2. Adresów naszych serwerów dla NOTIFY. Są na stronie Dodaj strefę i w oknie klucza. Przykłady używają 192.0.2.10 i 2001:db8::10; zastąp je swoimi. 3. Nazwy klucza, na przykład `user_ab12cd34-primary`. To nazwa Twojego konta i wybrana etykieta.

W każdym przykładzie zastąp `SECRET_FROM_DASHBOARD` swoim sekretem, a `example.com` swoją strefą. Użyj algorytmu, z którym utworzono klucz.

Jeśli wtórny DNS jest dla Ciebie nowy, zacznij od przewodnika Jak skonfigurować wtórny serwer DNS, a potem wróć tutaj, aby podpisać transfery.

Jak działa TSIG

TSIG (Transaction Signature, RFC 8945, który zastąpił RFC 2845) dodaje do komunikatu DNS rekord z podpisem. Obie strony mają ten sam sekret. Nadawca oblicza HMAC z komunikatu, nazwy klucza, algorytmu i czasu podpisu; odbiorca oblicza ten sam HMAC swoją kopią sekretu i porównuje.

Przy transferze strefy dzieje się to w obu kierunkach. Nasz serwer wtórny podpisuje swoje żądanie AXFR lub IXFR; Twój serwer podstawowy sprawdza podpis i, jeśli klucz jest dozwolony dla strefy, wysyła strefę z własnym podpisem, który z kolei sprawdza nasza strona. Transfer, który nie przejdzie którejkolwiek kontroli, jest odrzucany.

W praktyce liczą się trzy właściwości:

– Sekret nigdy nie jest przesyłany. Przesyłany jest tylko podpis. Kto przechwyci ruch, zobaczy dane strefy, ale nie utworzy ważnego żądania. – Czas jest częścią podpisu. Każdy podpis zawiera czas podpisu i dopuszczalną różnicę zegarów (zwykle 300 sekund). Żądanie poza tym oknem jest odrzucane z BADTIME, dlatego oba serwery potrzebują dokładnego zegara. – TSIG uwierzytelnia, ale nie szyfruje. Strefa nadal przechodzi przez sieć otwartym tekstem. Jeśli wrażliwa jest sama treść strefy, TSIG tu nie pomoże: decyduje tylko o tym, kto może ją pobrać.

Jak działają same AXFR i IXFR oraz jak uruchamia je NOTIFY, opisuje przewodnik Zrozumienie transferów stref AXFR.

TSIG czy lista dozwolonych IP

Bez klucza serwer podstawowy decyduje według adresu źródłowego: adresy IP naszych serwerów są w `allow-transfer`, `allow-axfr-ips`, `provide-xfr` lub ACL, a każdy inny adres jest odrzucany. To działa i pozostaje rozsądnym ustawieniem domyślnym, ale wiąże Twoją konfigurację z naszymi adresami.

Klucz usuwa to powiązanie. Serwer podstawowy ufa temu, kto przedstawi klucz, więc zmiana naszych adresów, dodatkowe źródło transferów po naszej stronie czy przeniesienie Twojej strefy do innej naszej lokalizacji nie wymaga zmian na serwerze podstawowym. Klucz rozdziela też klientów korzystających ze wspólnego serwera podstawowego: każde konto SecondDNS ma własne klucze, a klucz jednego konta nie pobierze stref innego.

Można też połączyć oba sposoby. Zostaw nasze adresy w ACL i wymagaj klucza. W NSD i Knot wpisz nasze adresy zamiast `0.0.0.0/0` razem z kluczem. W BIND lista dopasowań spełnia się przy dowolnym elemencie, więc adresy i klucz obok siebie w `allow-transfer` oznaczają adres lub klucz; aby wymagać obu, użyj formy zagnieżdżonej:

allow-transfer { !{ !{ 192.0.2.10; 2001:db8::10; }; any; }; key "user_ab12cd34-primary"; };

Wtedy transfer wymaga i właściwego źródła, i właściwego klucza.

Wybór algorytmu

Klucze SecondDNS używają hmac-sha256 lub hmac-sha512. Oba są obsługiwane przez wszystkie aktualne wersje BIND, PowerDNS, NSD i Knot DNS.

Wybierz hmac-sha256, chyba że masz powód, by wybrać inny: to typowy wybór w dokumentacji i przykładach, a jego 32-bajtowy sekret jest na tyle krótki, że wkleja się go bez łamania wierszy. hmac-sha512 ma 64-bajtowy sekret; wybierz go, gdy wymaga tego Twoja polityka. Starsze algorytmy, takie jak hmac-md5 i hmac-sha1, nie są oferowane.

Algorytm jest ustalany przy tworzeniu klucza. Aby go zmienić, utwórz nowy klucz z innym algorytmem, wybierz go dla swoich stref i usuń stary.

Długość sekretu zależy od algorytmu: 32 bajty dla hmac-sha256 i 64 bajty dla hmac-sha512, czyli 44 i 88 znaków w base64. Kopiuj cały sekret, łącznie ze znakami `=` na końcu: bez nich serwer podstawowy odrzuci klucz albo obliczy inny podpis, a transfer zakończy się błędem BADSIG.

BIND

Dodaj klucz i zezwól na transfery nim podpisane. To te same bloki, które pokazuje panel:

key "user_ab12cd34-primary" {
    algorithm hmac-sha256;
    secret "SECRET_FROM_DASHBOARD";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { key "user_ab12cd34-primary"; };
    also-notify { 192.0.2.10; 2001:db8::10; };
};

Gdy klucz jest w `allow-transfer`, nasze adresy IP nie są tam potrzebne. Zostaw `also-notify`: komunikaty NOTIFY nie są podpisywane i przyjmujemy je z adresu Twojego serwera podstawowego.

Sprawdź konfigurację i zastosuj ją:

named-checkconf && rndc reconfig

Dlaczego od NOTIFY zależy, jak szybko zmiany do nas docierają: synchronizacja stref przez NOTIFY.

PowerDNS

Zaimportuj klucz, zezwól mu na transfer strefy i wysyłaj NOTIFY do naszych serwerów:

# PowerDNS 4.x
pdnsutil import-tsig-key user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil activate-tsig-key example.com user_ab12cd34-primary primary
pdnsutil set-meta example.com ALSO-NOTIFY 192.0.2.10 2001:db8::10

# PowerDNS 5.x
pdnsutil tsigkey import user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil tsigkey activate example.com user_ab12cd34-primary primary
pdnsutil metadata set example.com ALSO-NOTIFY 192.0.2.10 2001:db8::10

Strefa musi być typu `primary` (lub `native` z własną konfiguracją NOTIFY). `activate-tsig-key … primary` (`tsigkey activate` w 5.x) dodaje klucz do metadanych strefy `TSIG-ALLOW-AXFR`. PowerDNS daje dostęp do strefy żądaniu podpisanemu kluczem z `TSIG-ALLOW-AXFR`, nawet jeśli adresu nie ma w `allow-axfr-ips`.

NSD

Zdefiniuj klucz w `nsd.conf` i zezwól na transfery tylko z nim:

key:
    name: "user_ab12cd34-primary"
    algorithm: hmac-sha256
    secret: "SECRET_FROM_DASHBOARD"

zone:
    name: "example.com"
    zonefile: "example.com.zone"
    provide-xfr: 0.0.0.0/0 user_ab12cd34-primary
    provide-xfr: ::0/0 user_ab12cd34-primary
    notify: 192.0.2.10 NOKEY
    notify: 2001:db8::10 NOKEY

`provide-xfr` z `0.0.0.0/0` i `::0/0` oznacza: z dowolnego adresu, ale tylko z tym kluczem. Aby sprawdzać i adres, i klucz, wpisz zamiast tego nasze adresy. NOTIFY idzie do naszych adresów bez podpisu (`NOKEY`).

Sprawdź i zastosuj:

nsd-checkconf /etc/nsd/nsd.conf && nsd-control reconfig

Knot DNS

Zdefiniuj klucz, ACL zezwalające z nim na transfery wychodzące i nasze serwery jako odbiorców NOTIFY:

key:
  - id: user_ab12cd34-primary
    algorithm: hmac-sha256
    secret: SECRET_FROM_DASHBOARD

remote:
  - id: seconddns
    address: [192.0.2.10, 2001:db8::10]

acl:
  - id: seconddns_transfer
    key: user_ab12cd34-primary
    action: transfer

zone:
  - domain: example.com
    acl: seconddns_transfer
    notify: seconddns

ACL tylko z `key` przepuszcza żądania z dowolnego adresu podpisane tym kluczem. Dodaj do ACL `address`, aby wymagać obu warunków.

Sprawdź i zastosuj:

knotc conf-check && knotc reload

Sprawdź klucz przed dodaniem strefy

Poproś serwer podstawowy o strefę z kluczem z dowolnej maszyny, z której jest osiągalny na porcie TCP 53:

dig @PRIMARY_IP example.com AXFR -y hmac-sha256:user_ab12cd34-primary:SECRET_FROM_DASHBOARD

Pełna lista rekordów strefy oznacza, że klucz i uprawnienie są poprawne. `BADKEY` oznacza, że serwer podstawowy nie zna klucza o tej nazwie; `BADSIG` — że różni się sekret lub algorytm. `Transfer failed` z REFUSED bez błędu TSIG oznacza, że klucz jest ważny, ale niedozwolony dla tej strefy.

Jak potwierdzić, że transfer był podpisany

Po dodaniu strefy z kluczem serwer podstawowy zapisuje w logu każdy transfer razem z kluczem, którym go podpisano. W BIND podpisany transfer wygląda tak:

client @0x… 192.0.2.10#43001/key user_ab12cd34-primary (example.com): transfer of 'example.com/IN': AXFR started: TSIG user_ab12cd34-primary (serial 2026101101)

Nazwa klucza po `TSIG` to klucz, którego użył nasz serwer. Transfer zapisany bez nazwy klucza został dopuszczony według adresu, a nie klucza: sprawdź, czy dla strefy w panelu naprawdę wybrano klucz, i usuń nasze adresy z ACL, jeśli klucz ma być wymagany.

W PowerDNS, NSD i Knot DNS szukaj w logu nazwy strefy z czasu transferu. Po naszej stronie panel pokazuje serial strefy i liczbę rekordów po pierwszym udanym transferze.

Wybierz klucz w panelu

Przy dodawaniu domeny wybierz klucz w polu Klucz TSIG. Twój klucz domyślny, jeśli go ustawiono, jest wybrany; przy opcji Brak strefa jest przesyłana bez podpisu. Dla istniejącej strefy otwórz okno edycji i zmień klucz tam.

Nasze serwery podpisują wtedy tym kluczem swoje żądania transferu dla strefy. Klucz trafia na nasze serwery tylko wtedy, gdy używa go strefa.

Ponowne wygenerowanie klucza od razu zastępuje sekret. Strefy z tym kluczem nie są synchronizowane, dopóki serwer podstawowy nie otrzyma nowego sekretu, więc zaktualizuj go zaraz potem.

Rotacja klucza

Wygeneruj klucz ponownie, gdy sekret mógł zostać ujawniony, gdy przestała z Tobą pracować osoba z dostępem do serwera podstawowego albo regularnie, jeśli wymaga tego Twoja polityka bezpieczeństwa.

Aby przerwa była jak najkrótsza, postępuj tak:

1. Otwórz konfigurację serwera podstawowego, aby zmiana była gotowa do zastosowania. 2. W Ustawienia › DNS wybierz dla klucza Wygeneruj ponownie. Okno pokaże, ile stref go używa. Skopiuj nowy sekret z następnego okna. 3. Zastąp sekret na serwerze podstawowym i od razu przeładuj konfigurację. 4. Sprawdź poleceniem `dig -y` powyżej z nowym sekretem.

Między krokami 2 i 3 nasze serwery podpisują już nowym sekretem, więc transfery tych stref nie przechodzą, dopóki serwer podstawowy go nie dostanie. Strefy nadal odpowiadają z naszej ostatniej kopii; jedynie zmiany do nich nie docierają. Jeśli nie chcesz żadnej przerwy, utwórz drugi klucz, dodaj go na serwerze podstawowym obok pierwszego, wybierz go dla stref w panelu i usuń stary klucz, gdy nic go już nie używa.

Rozwiązywanie problemów

BADKEY: serwer podstawowy nie zna klucza o tej nazwie. Porównaj nazwę w konfiguracji z nazwą w panelu, łącznie z prefiksem konta.

BADSIG: różni się sekret lub algorytm. Skopiuj sekret ponownie albo wygeneruj klucz ponownie i zaktualizuj serwer podstawowy.

BADTIME: podpisy TSIG zawierają znacznik czasu i są odrzucane, gdy zegary różnią się o więcej niż kilka minut. Upewnij się, że serwer podstawowy synchronizuje czas przez NTP.

Zmiany docierają z opóźnieniem: NOTIFY nie dociera do naszych serwerów. Porównaj `also-notify`, `ALSO-NOTIFY` lub `notify` z naszymi adresami i sprawdź, czy porty UDP i TCP 53 do nich są otwarte.

Transfer odrzucony, choć klucz jest poprawny: klucz nie jest dozwolony dla tej strefy. Sprawdź `allow-transfer`, `TSIG-ALLOW-AXFR`, `provide-xfr` lub ACL na samej strefie, nie tylko globalnie.

Najczęstsze pytania

Czy można używać jednego klucza dla wielu stref? Tak. Wybierz ten sam klucz dla każdej strefy w panelu i zezwól na niego dla każdej strefy na serwerze podstawowym. Liczbę kluczy na konto określa Twój plan.

Czy mogę użyć własnego wygenerowanego klucza? Nie. SecondDNS generuje klucz i pokazuje sekret raz, więc sekret nigdy nie trafia do nas z zewnątrz i jest przechowywany tylko w postaci zaszyfrowanej.

Czy TSIG zmienia coś dla IPv6? Nie. Klucz nie zależy od rodziny adresów. Zezwól na klucz, a jeśli ograniczasz także według adresu, wpisz nasze adresy IPv6 obok IPv4.

Czy NOTIFY jest podpisywany? Nie. Serwer podstawowy wysyła NOTIFY bez podpisu, a my przyjmujemy go z adresu Twojego serwera podstawowego. NOTIFY tylko prosi nas o sprawdzenie seriala; transfer, który następuje, jest podpisany.

Czy transfery przyrostowe (IXFR) też są podpisywane? Tak. Klucz dotyczy żądań AXFR i IXFR dla strefy.

Co się stanie, jeśli usunę klucz na serwerze podstawowym, ale zostawię go wybranego w panelu? Transfery zaczną kończyć się błędem BADKEY. Strefa będzie odpowiadać z naszej ostatniej kopii, dopóki nie wygaśnie zgodnie z wartością expire w SOA (co oznaczają liczniki SOA), więc w porę popraw konfigurację lub wybierz dla strefy Brak.

Czy mogę usunąć klucz, którego nadal używają strefy? Nie. Panel pokazuje, które strefy go używają; najpierw wybierz dla nich inny klucz lub Brak.

Czy trzeba otwierać porty inne niż 53? Nie. Transfery używają portu TCP 53, a NOTIFY portu UDP 53. TSIG nie dodaje portów: podpis jest przesyłany w tym samym komunikacie DNS.

Czy widać, jakich kluczy używają moje strefy? Tak. W Ustawienia › DNS przy każdym kluczu widać, ile stref go używa, a karta strefy pokazuje nazwę jej klucza obok adresu serwera podstawowego.

Powiązane przewodniki

– Zrozumienie transferów stref AXFR – Jak skonfigurować wtórny serwer DNS – Wtórny serwer DNS: czym jest i jak działa