SecondDNS
Посібники

TSIG-ключі на первинному DNS-сервері: BIND, PowerDNS, NSD і Knot

Що потрібно

TSIG-ключ підписує кожен трансфер зони між вашим первинним сервером і нашими вторинними. Первинний перевіряє наші сервери за ключем, а не за їхніми IP-адресами.

З панелі SecondDNS потрібні три речі:

1. Ключ. Створіть його в Налаштування › DNS. Вікно показує ім'я ключа, алгоритм (hmac-sha256 або hmac-sha512) і секрет. Секрет показується один раз: скопіюйте його, перш ніж закрити вікно. Якщо загубите, перегенеруйте ключ. 2. Адреси наших серверів для NOTIFY. Вони є на сторінці Додати зону і у вікні ключа. У прикладах нижче це 192.0.2.10 і 2001:db8::10; замініть їх своїми. 3. Ім'я ключа, наприклад `user_ab12cd34-primary`. Це ім'я вашого акаунта плюс обрана вами мітка.

У кожному прикладі замініть `SECRET_FROM_DASHBOARD` своїм секретом, а `example.com` — своєю зоною. Вказуйте той алгоритм, з яким створено ключ.

Якщо вторинний DNS для вас новий, почніть із посібника Як налаштувати вторинний DNS-сервер, а потім поверніться сюди, щоб підписати трансфери.

Як працює TSIG

TSIG (Transaction Signature, RFC 8945, що замінив RFC 2845) додає до DNS-повідомлення запис із підписом. Обидві сторони мають однаковий секрет. Відправник обчислює HMAC від повідомлення, імені ключа, алгоритму й часу підпису; отримувач обчислює той самий HMAC своєю копією секрету й порівнює результати.

Під час трансферу зони це відбувається в обидва боки. Наш вторинний підписує свій запит AXFR чи IXFR; ваш первинний перевіряє підпис і, якщо ключ дозволено для зони, надсилає зону зі своїм підписом, який, своєю чергою, перевіряє наша сторона. Якщо трансфер не проходить хоча б одну перевірку, його відкидають.

На практиці важливі три властивості:

– Секрет ніколи не передається. Передається лише підпис. Той, хто перехопить трафік, побачить дані зони, але не зможе сформувати дійсний запит. – Час входить у підпис. Кожен підпис містить час підпису і допустиму різницю годинників (зазвичай 300 секунд). Запит поза цим вікном відхиляється з BADTIME, тому обом серверам потрібен точний годинник. – TSIG автентифікує, але не шифрує. Зона й далі йде мережею відкритим текстом. Якщо конфіденційним є сам вміст зони, TSIG тут не допоможе: він лише визначає, хто може її забрати.

Як влаштовані самі AXFR та IXFR і як їх запускає NOTIFY, описано в посібнику Трансфери зон AXFR.

TSIG чи дозвіл за IP

Без ключа первинний вирішує за адресою джерела: IP-адреси наших серверів прописано в `allow-transfer`, `allow-axfr-ips`, `provide-xfr` чи ACL, а всі інші адреси відхиляються. Це працює і лишається розумним варіантом за замовчуванням, але прив'язує вашу конфігурацію до наших адрес.

Ключ цю прив'язку знімає. Первинний довіряє тому, хто має ключ, тож зміна наших адрес, додаткове джерело трансферів з нашого боку чи перенесення вашої зони в іншу нашу локацію не вимагатимуть змін на первинному. Крім того, ключ розділяє клієнтів, що мають спільний первинний: у кожного акаунта SecondDNS свої ключі, і ключ одного акаунта не забере зони іншого.

Обидва способи можна поєднати. Залиште наші адреси в ACL і вимагайте ключ. У NSD та Knot вкажіть наші адреси замість `0.0.0.0/0` разом із ключем. У BIND список збігів спрацьовує на будь-який елемент, тож адреси й ключ поруч в `allow-transfer` означають адреса або ключ; щоб вимагати обидва, використайте вкладену форму:

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

Тоді для трансферу потрібні і правильне джерело, і правильний ключ.

Вибір алгоритму

Ключі SecondDNS використовують hmac-sha256 або hmac-sha512. Обидва підтримують усі актуальні версії BIND, PowerDNS, NSD і Knot DNS.

Обирайте hmac-sha256, якщо немає особливих причин обрати інший: це звичний вибір у документації та прикладах, а його 32-байтовий секрет досить короткий, щоб вставити його без переносів. hmac-sha512 має 64-байтовий секрет; обирайте його, коли цього вимагає ваша політика. Старі алгоритми на кшталт hmac-md5 і hmac-sha1 не пропонуються.

Алгоритм фіксується під час створення ключа. Щоб змінити його, створіть новий ключ з іншим алгоритмом, виберіть його для своїх зон і видаліть старий.

Довжина секрету залежить від алгоритму: 32 байти для hmac-sha256 і 64 байти для hmac-sha512, у base64 це 44 і 88 символів відповідно. Копіюйте секрет повністю, разом із символами `=` наприкінці: без них первинний або відкине ключ, або порахує інший підпис, і трансфер завершиться з BADSIG.

BIND

Додайте ключ і дозвольте підписані ним трансфери. Це ті самі блоки, що показує панель:

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; };
};

Коли ключ стоїть в `allow-transfer`, наші IP-адреси там не потрібні. `also-notify` залиште: повідомлення NOTIFY не підписуються, і ми приймаємо їх з адреси вашого первинного.

Перевірте конфігурацію й застосуйте її:

named-checkconf && rndc reconfig

Чому від NOTIFY залежить, як швидко зміни доходять до нас: синхронізація зон через NOTIFY.

PowerDNS

Імпортуйте ключ, дозвольте йому трансфер зони й надсилайте NOTIFY на наші сервери:

# 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

Зона має бути типу `primary` (або `native` з власним налаштуванням NOTIFY). `activate-tsig-key … primary` (`tsigkey activate` у 5.x) додає ключ до метаданих зони `TSIG-ALLOW-AXFR`. PowerDNS допускає до зони запит, підписаний ключем із `TSIG-ALLOW-AXFR`, навіть якщо адреси немає в `allow-axfr-ips`.

NSD

Опишіть ключ у `nsd.conf` і дозвольте трансфери лише з ним:

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` з `0.0.0.0/0` і `::0/0` означає: з будь-якої адреси, але лише з цим ключем. Щоб перевірялися і адреса, і ключ, вкажіть замість цього наші адреси. NOTIFY іде на наші адреси без підпису (`NOKEY`).

Перевірте й застосуйте:

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

Knot DNS

Опишіть ключ, ACL, що дозволяє з ним вихідні трансфери, і наші сервери як отримувачів 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 лише з `key` пропускає запити з будь-якої адреси, підписані цим ключем. Додайте до ACL `address`, щоб вимагати і те, і інше.

Перевірте й застосуйте:

knotc conf-check && knotc reload

Перевірте ключ до додавання зони

Запросіть зону з первинного з ключем з будь-якої машини, з якої він доступний через TCP-порт 53:

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

Повний перелік записів означає, що ключ і дозвіл правильні. `BADKEY` означає, що первинний не знає ключа з таким ім'ям; `BADSIG` — що відрізняється секрет або алгоритм. `Transfer failed` з REFUSED без помилки TSIG означає, що ключ дійсний, але не дозволений для цієї зони.

Як переконатися, що трансфер підписано

Коли зону додано з ключем, первинний записує в журнал кожен трансфер разом із ключем, яким його підписано. У BIND підписаний трансфер виглядає так:

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)

Ім'я після `TSIG` — це ключ, яким скористався наш сервер. Трансфер у журналі без імені ключа означає, що його дозволено за адресою, а не за ключем: перевірте, що для зони в панелі справді вибрано ключ, і приберіть наші адреси з ACL, якщо хочете, щоб ключ був обов'язковим.

У PowerDNS, NSD і Knot DNS шукайте в журналі назву зони за час трансферу. З нашого боку панель показує серіал зони й кількість записів після першого успішного трансферу.

Виберіть ключ у панелі

Під час додавання домену виберіть ключ у полі TSIG-ключ. Ваш типовий ключ, якщо його задано, вибрано заздалегідь; з варіантом Немає зона передається без підпису. Для наявної зони відкрийте вікно редагування й змініть ключ там.

Після цього наші сервери підписують свої запити трансферу для зони цим ключем. Ключ потрапляє на наші сервери лише тоді, коли його використовує зона.

Перегенерація ключа одразу замінює секрет. Зони з цим ключем не синхронізуються, доки первинний не отримає новий секрет, тому оновіть первинний одразу після перегенерації.

Ротація ключа

Ключ варто перегенерувати, якщо секрет міг потрапити до сторонніх, якщо з вами більше не працює людина, яка мала доступ до первинного сервера, або регулярно, якщо цього вимагає ваша політика безпеки.

Щоб перерва була якомога коротшою, дійте так:

1. Відкрийте конфігурацію первинного, щоб зміна була готова до застосування. 2. У Налаштування › DNS натисніть для ключа Перегенерувати. Вікно покаже, скільки зон його використовують. Скопіюйте новий секрет із вікна, що відкриється далі. 3. Замініть секрет на первинному й одразу перезавантажте конфігурацію. 4. Перевірте командою `dig -y` вище з новим секретом.

Між кроками 2 і 3 наші сервери вже підписують новим секретом, тож трансфери цих зон не проходять, доки первинний його не отримає. Зони й далі відповідають з нашої останньої копії, просто оновлення до них не доходять. Якщо перерва неприпустима взагалі, створіть другий ключ, додайте його на первинний поруч із першим, виберіть його для зон у панелі й видаліть старий ключ, коли його вже ніщо не використовує.

Усунення несправностей

BADKEY: первинний не знає ключа з таким ім'ям. Порівняйте ім'я у своїй конфігурації з ім'ям у панелі, разом із префіксом акаунта.

BADSIG: відрізняється секрет або алгоритм. Скопіюйте секрет ще раз або перегенеруйте ключ і оновіть первинний.

BADTIME: TSIG-підпис містить позначку часу і відхиляється, якщо годинники розходяться більш ніж на кілька хвилин. Переконайтеся, що на первинному працює синхронізація часу (NTP).

Зміни доходять із запізненням: NOTIFY не доходить до наших серверів. Звірте `also-notify`, `ALSO-NOTIFY` чи `notify` з нашими адресами і перевірте, що UDP і TCP-порт 53 до них відкриті.

Трансфер відхилено, хоча ключ правильний: ключ не дозволено для цієї зони. Перевірте `allow-transfer`, `TSIG-ALLOW-AXFR`, `provide-xfr` або ACL саме на зоні, а не лише глобально.

Поширені запитання

Чи можна використовувати один ключ для багатьох зон? Так. Виберіть той самий ключ для кожної зони в панелі й дозвольте його для кожної зони на первинному. Скільки ключів може мати акаунт, визначає ваш план.

Чи можна використати власний згенерований ключ? Ні. SecondDNS генерує ключ сам і показує секрет один раз, тож секрет ніколи не надходить до нас ззовні й зберігається лише в зашифрованому вигляді.

Чи змінює TSIG щось для IPv6? Ні. Ключ не залежить від сімейства адрес. Дозвольте ключ, а якщо обмежуєте й за адресою, вкажіть наші IPv6-адреси разом з IPv4.

Чи підписується NOTIFY? Ні. Первинний надсилає NOTIFY без підпису, і ми приймаємо його з адреси вашого первинного. NOTIFY лише просить нас перевірити серіал; трансфер, що йде за ним, підписаний.

Чи підписуються інкрементні трансфери (IXFR)? Так. Ключ діє і для запитів AXFR, і для IXFR цієї зони.

Що буде, якщо видалити ключ на первинному, але лишити його вибраним у панелі? Трансфери почнуть завершуватися помилкою BADKEY. Зона відповідатиме з нашої останньої копії, доки не спливе термін за значенням expire в SOA (що означають таймери SOA), тож вчасно виправте конфігурацію або виберіть для зони значення Немає.

Чи можна видалити ключ, який ще використовують зони? Ні. Панель показує, які зони його використовують; спершу виберіть для них інший ключ або значення Немає.

Чи потрібно відкривати якісь порти, крім 53? Ні. Трансфер іде TCP-портом 53, NOTIFY — UDP-портом 53. TSIG не додає нових портів: підпис передається в тому самому DNS-повідомленні.

Чи видно, які ключі використовують мої зони? Так. У Налаштування › DNS біля кожного ключа видно, скільки зон його використовують, а в картці зони біля адреси первинного показано ім'я її ключа.

Пов'язані посібники

– Трансфери зон AXFR – Як налаштувати вторинний DNS-сервер – Вторинний DNS-сервер: що це і як працює