Що таке DNSSEC і навіщо він домену
DNSSEC додає цифрові підписи до даних DNS. Резолвер, який перевіряє підписи, може виявити підміну відповіді чи неузгодженість у ланцюжку довіри. DNSSEC захищає цілісність і походження записів, але не шифрує DNS-запити й не робить сайт автоматично безпечним.
Як працює ланцюжок довіри?
Оператор зони підписує записи закритим ключем і публікує записи DNSKEY та RRSIG. Батьківська зона містить DS-запис, який пов’язує її з ключем дочірньої зони. Резолвер проходить ланцюжок від довіреного кореня до відповіді. За правильного ланцюжка він приймає підписану відповідь; у разі порушення може повернути помилку замість непідтверджених даних. Загальні принципи описано в RFC 4033.
Підписують і доказ відсутності запису, щоб зловмисник не міг просто підмінити відповідь «імені немає». Користувач зазвичай не бачить підписів: результат залежить від того, чи перевіряє їх обраний резолвер. Сама позначка DNSSEC у кабінеті домену не доводить, що батьківський DS, ключі та підписи узгоджені на всіх авторитетних серверах.
Що DNSSEC захищає, а чого ні?
DNSSEC ускладнює непомітну підміну DNS-даних за працюючої перевірки. Він не шифрує ім’я запиту й не приховує адресу сайту від резолвера; для приватності транспорту існують окремі механізми, наприклад DoH та DoT. DNSSEC також не замінює TLS-сертифікат, перевірку вмісту сайту, захист акаунта реєстратора чи надійне адміністрування зони.
Якщо власник сайту сам опублікував помилковий запис, підпис підтвердить саме цей помилковий запис. Тому підтримуйте правильні A, AAAA, MX та інші дані незалежно від підписання. Для діагностики використовуйте перевірку DNS і порівнюйте відповіді звичайного та перевіряючого резолвера. Не вимикайте перевірку для всіх користувачів, щоб приховати одну несправну зону.
Чому підписаний домен може перестати відкриватися?
Поширена причина — стара DS-запис у реєстратора після зміни DNS-провайдера чи ключів. Можливі прострочені підписи, неузгодженість авторитетних серверів і помилки під час ротації ключа. Перевірте делегування, поточні DNSKEY та DS, строки дії RRSIG і відповіді кожного авторитетного сервера. Запишіть точний код помилки й час перевірки.
Перед перенесенням зони узгодьте порядок зміни DS із новим оператором і перевірте опубліковані ключі. Після виправлення врахуйте TTL попередніх відповідей і негативних результатів. Якщо домен важливий для пошти чи API, підготуйте вікно змін та відкат. Надійна автоматизація підписів і нагляд за строками ключів важливіші за формальне ввімкнення функції.
Звичайний резолвер без валідації іноді повертає адресу навіть за помилки підпису, тоді як перевіряючий показує збій. Це корисна ознака для діагностики, але не спосіб обійти несправність. Виправляйте ключі й підписи в авторитетній зоні та DS у батьківській; далі перевіряйте результат на незалежних резолверах із валідацією.