Як запускати DNS з прихованим primary і публічними secondaries

Сервер, на якому ви редагуєте свої зони DNS, не мусить відповідати інтернету, і не повинен. Прихований primary тримає авторитетну копію і приймає зміни від ваших людей і вашої автоматизації. Набір публічних secondaries, які є єдиними серверами, перерахованими у ваших записах NS, відповідає на кожен запит. Primary можна оновлювати, перезавантажувати, а атакувати його не може ніхто, бо ніхто ззовні не знає, де він. Ця стаття показує, як побудувати це з PowerDNS, два способи передавати дані від primary до secondaries і перевірки, які доводять, що primary справді прихований.

Форма дизайну

• Один primary у приватній мережі, без публічної адреси, ніколи не названий у записах NS чи SOA. На ньому працюють API і вебінтерфейс, якими користується ваша команда.
• Два або більше публічних secondaries на різних майданчиках, в ідеалі в різних мережах і в різних провайдерів чи платформ, щоб жодна одиночна відмова не вибила їх усіх.
• Приватний шлях від primary до кожного secondary, лише для реплікації.
• Secondaries продовжують відповідати, якщо primary зникає. Вони тримають повну копію, тож мертвий primary означає «деякий час без змін», а не «домен недоступний».

Є два способи живити secondaries. Обидва працюють; вони пасують різним командам.

Варіант перший: передачі зон з NOTIFY і TSIG

Це стандартний DNS, і він працює з будь-яким поєднанням серверів DNS. Primary надсилає NOTIFY, коли зона змінюється; secondary перевіряє серійний номер SOA і витягує зону через AXFR або IXFR.

На primary, у pdns.conf:

primary=yes
allow-axfr-ips=192.0.2.21/32,198.51.100.31/32
also-notify=192.0.2.21,198.51.100.31
only-notify=

Ці адреси є приватними адресами secondaries. Залишити only-notify порожнім і перелічити цілі в also-notify означає, що NOTIFY іде лише на ваші secondaries, ніколи на те, що випадково опинилося в записах NS.

Потім підпишіть передачі. Список дозволених IP сам по собі довіряє мережі; ключ TSIG доводить, що запит іде від вашого secondary.

# on the primary
pdnsutil generate-tsig-key xfr hmac-sha256
pdnsutil activate-tsig-key example.com xfr primary
pdnsutil list-tsig-keys      # copy the secret

# on each secondary (pdns.conf contains: secondary=yes)
pdnsutil import-tsig-key xfr hmac-sha256 '<secret>'
pdnsutil create-secondary-zone example.com 203.0.113.10
pdnsutil activate-tsig-key example.com xfr secondary

Де 203.0.113.10 є приватною адресою primary. Щоб не створювати кожну зону вручну на кожному secondary, PowerDNS може створювати їх автоматично, коли primary надсилає NOTIFY для нової зони. Налаштуйте primary як autoprimary на кожному secondary:

pdnsutil add-autoprimary 203.0.113.10 ns1.example.net

і встановіть autosecondary=yes на secondaries.

Варіант другий: native-зони і реплікація бази даних

PowerDNS також може повністю обійтися без передач DNS. Позначте зони як NATIVE, тримайте їх у backend MySQL, MariaDB або PostgreSQL і дайте базі даних реплікувати дані primary на репліку лише для читання на кожному secondary.

pdnsutil set-kind example.com native

На кожному secondary PowerDNS читає зі своєї локальної бази-репліки, налаштованої лише для читання. Реплікація іде лише приватною мережею.

Чому варто це обрати:

• Кожна зміна приходить як рядок, щойно база даних її доставить. Немає серійного номера, який можна забути збільшити, і немає NOTIFY, який можна загубити.
• AXFR можна вимкнути всюди, тож узагалі немає інтерфейсу передач, який треба захищати.
• Нові зони з’являються на secondaries автоматично, бо вони теж є рядками.
• Ключі DNSSEC реплікуються разом із записами, і кожен secondary підписує відповіді сам.

Чому ні: кожен secondary має працювати на тому самому backend, і тепер ви експлуатуєте реплікацію бази даних, яка потребує власного моніторингу відставання і зламаних потоків. Якщо серед ваших secondaries є DNS іншого вендора, передачі є єдиним варіантом.

Ми будуємо свої з native-зонами і реплікацією бази даних, бо це повністю прибирає поверхню передач і робить базу даних єдиним, очевидним джерелом істини.

DNSSEC з прихованим primary

Обидва варіанти підтримують підписування:

• З передачами підписуйте на primary. Secondaries отримують підписану зону і віддають її як presigned дані; PowerDNS автоматично позначає зону PRESIGNED, коли передає підписані записи.
• З реплікацією бази даних ключі живуть у базі даних, тож кожен secondary підписує наживо тими самими ключами і відповідає ідентично.

У будь-якому разі перевірте валідацію ззовні резолвером з валідацією:

dig +dnssec example.com SOA @1.1.1.1
delv example.com SOA

delv має повідомити «fully validated».

Називайте правильні сервери

Сенс прихованого primary втрачається, якщо його ім’я витікає в записи, які читає світ.

• Записи NS перелічують лише публічні secondaries.
• Поле MNAME у SOA називає публічний secondary, а не primary. У PowerDNS default-soa-content встановлює його для нових зон; виправте наявні через pdnsutil edit-zone.
• Glue у реєстрі вказує лише на публічні адреси secondaries.

Деякі інструменти типово записують у SOA MNAME власне ім’я сервера. Перевірте це на кожній зоні, а не лише на першій.

Замкніть кожну роль

• Поставте DNS-обізнаний front end на кшталт dnsdist перед кожним публічним secondary, щоб відхиляти типи запитів для ампліфікації, обмежувати швидкість і відкидати запити до зон, які ви не обслуговуєте.
• На secondaries відхиляйте NOTIFY звідусіль, крім primary, і відхиляйте запити AXFR з інтернету.

Перевірте це ззовні

# NS and SOA name only public secondaries
dig +short NS example.com
dig +short SOA example.com

# Every secondary has the same serial
for ns in $(dig +short NS example.com); do
  printf '%s ' "$ns"; dig +short SOA example.com @"$ns" | awk '{print $3}'
done

# Transfers are refused from the internet
dig AXFR example.com @ns1.example.net

# The primary does not answer from outside (expect a timeout)
dig example.com SOA @<primary-address> +time=2 +tries=1

Порівняння серійних номерів виконуйте безперервно, а не один раз. Secondary, який перестав отримувати оновлення, продовжує впевнено відповідати старими даними; єдиний симптом це серійний номер, що відстає. Ставте на це тривогу, і ставте тривогу, якщо ім’я або адреса primary колись з’явиться у записі NS чи SOA.

Коротко

Primary є місцем, де ви редагуєте, secondaries є місцем, де питає світ, і зустрічаються вони лише в приватній мережі. Обирайте передачі, якщо змішуєте вендорів DNS, реплікацію бази даних, якщо не хочете жодної поверхні передач. Називайте лише secondaries, підписуйте зону і стежте за серійними номерами.

Ми будуємо і запускаємо кластери PowerDNS отак для клієнтів, які хочуть володіти своїм DNS. Якщо ви плануєте такий, ми радо допоможемо.

cta: Поговоріть з інженером

Related

• /what-we-do/platforms/dns/
• /what-we-do/network/dns/