Hidden primary і dnsdist: посилення захисту authoritative DNS

Authoritative DNS є підсилювачем для атакувальників і частою мішенню шквалів запитів. Два архітектурні рішення роблять більшу частину роботи з його стійкості: тримайте primary прихованим і ставте DNS-свідомий балансувальник перед кожним публічним сервером. Ось як, з правилами, які ми вважаємо мінімумом.

Сховайте primary

Сервер, де редагуються зони, живуть ключі й лежить майстер-копія даних, ніколи не повинен відповідати інтернету. Натомість він реплікується на публічні secondaries внутрішньою мережею, і лише secondaries з’являються в записах NS.

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

Чи то реплікація є класичними AXFR і NOTIFY, чи реплікацією бази даних під PowerDNS, властивість, яку треба захистити, та сама: адреса primary ніколи не повинна з’являтися в публічному записі NS або SOA. Перевірте:

dig +short NS example.com
dig +short SOA example.com      # the MNAME field should not be your hidden primary

Чому звичайного балансувальника не досить

Балансувальник TCP або UDP може розподіляти запити, але не може їх читати. Майже кожен корисний захист DNS залежить від розуміння запиту: його типу, зони, про яку він питає, чи це UPDATE, скільки помилок генерує джерело. dnsdist з проєкту PowerDNS стоїть перед nameserver, тримає публічний порт і ухвалює ці рішення до того, як запит дійде до backend. Сам authoritative сервер тоді слухає лише на localhost.

Правила dnsdist, які ми вважаємо мінімумом

-- backend listens on localhost only
newServer({address="127.0.0.1:5300", name="auth"})
setLocal("0.0.0.0:53")
addLocal("[::]:53")

trusted = newNMG(); trusted:addMask("10.0.0.0/8")   -- your internal replication network
ourZones = newSuffixMatchNode(); ourZones:add("example.com.")

-- ANY queries are an amplification tool; refuse them
addAction(QTypeRule(DNSQType.ANY), RCodeAction(DNSRCode.REFUSED))

-- no dynamic updates or notifies from the internet
addAction(AndRule({OpcodeRule(DNSOpcode.Update), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))
addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))

-- only answer for zones we actually serve
addAction(NotRule(SuffixMatchNodeRule(ourZones)), RCodeAction(DNSRCode.REFUSED))

-- cap queries per source address
addAction(MaxQPSIPRule(50), DropAction())

-- automatic temporary blocks for sources generating floods of failures
local dbr = dynBlockRulesGroup()
dbr:setRCodeRate(DNSRCode.NXDOMAIN, 50, 10, "NXDOMAIN flood", 60)
dbr:setRCodeRate(DNSRCode.REFUSED, 50, 10, "REFUSED flood", 60)
function maintenance() dbr:apply() end

Що дає кожне правило:

• Відмова в ANY прибирає класичний запит для підсилення.
• Відмова в UPDATE і NOTIFY ззовні закриває шляхи, якими вміст зон або реплікацію можна було б вплинути з інтернету.
• Відмова в зонах, які ви не обслуговуєте, до того як їх побачить backend, тримає випадкове сміття і reflection probes цілком поза nameserver.
• Встановлюйте обмеження швидкості на джерело від вашого реального трафіку, достатньо щедрі для великих resolvers.
• Динамічні блокування за частотою помилок ловлять атаки випадковими піддоменами, які генерують шквали відповідей NXDOMAIN з багатьох джерел, не блокуючи resolver за одну погану хвилину.
• Додайте response rate limiting на backend або в dnsdist, щоб навіть легітимні на вигляд відповіді не можна було перетворити на шквал у бік підробленої адреси.

DNSSEC без тасування ключів

Якщо ваші secondaries підписують зони самі, кожному з них потрібні ключі, а розповсюдження ключів є саме тим місцем, де розгортання DNSSEC ламаються. Коли ключі живуть у тій самій базі даних, яка реплікується на secondaries, кожен сервер підписує однаково за побудовою. Коли ви переносите підписаний домен між провайдерами, робіть це по порядку: приберіть старий запис DS у реєстрі, дочекайтеся закінчення кешів, підпишіть на нових серверах, потім опублікуйте новий DS. Валідація ніколи не ламається.

Зворотний DNS є частиною роботи

Ставтеся до зворотного DNS як до правила: кожна адреса, призначена інтерфейсу, сервісу або хосту, отримує PTR у тій самій зміні, і кожна зворотна зона делегується всім вашим nameservers. Перевіряйте обидва напрямки і батьківське делегування:

dig +short -x 192.0.2.25
dig +short host.example.com A
dig +short NS 2.0.192.in-addr.arpa

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

Стежте за відповідями, а не лише за серверами

Nameserver, який працює, але віддає застарілу зону, гірший за той, що лежить, бо нічого не сигналізує. Моніторте те, що має значення: порівнюйте serial SOA кожної зони на кожному сервері, порівнюйте кількість записів, стежте за відставанням реплікації і сповіщайте, якщо hidden primary коли-небудь з’явиться в публічних даних. Перевірка з кількох зовнішніх точок, що кожен публічний сервер відповідає авторитетно, замикає коло.

Ваш чекліст

• Чи прихований ваш primary і чи відсутній він у NS та SOA?
• Чи стоять публічні сервери за DNS-свідомим фронтом, який відмовляє в ANY, зовнішніх UPDATE і NOTIFY та невідомих зонах?
• Чи є обмеження на джерело і динамічні блокування для шквалів помилок?
• Чи всі сервери підписують однаково і чи записана ваша процедура ротації DS?
• Чи кожна призначена адреса має відповідний PTR?
• Чи сповіщаєте ви про розбіжність serial між серверами?

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

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

Related

Пов’язане: Authoritative DNS і зворотний DNS як інфраструктура · Authoritative і рекурсивний DNS на PowerDNS · IPv6, нативний і dual-stack