Defaults.Exposed › Виправлення › DNSSEC
Як виправити DNSSEC
DNSSEC — це цифрова печатка на адресній книзі вашого домену. Вона дозволяє інтернету довести, що відповідь на питання «де живе цей домен?» справді прийшла від вас і не була підроблена по дорозі. Без неї відповідь може бути підроблена — і ваші відвідувачі тихо відправлені кудись іще.
Висновок для вашого бізнесу: Без DNSSEC зловмисник, що може отруїти DNS-відповідь, може спрямувати ваших клієнтів на ідеальну копію вашого сайту, поки їхній браузер все одно показує ваше справжнє доменне ім'я. Логіни, номери карток і персональні дані збираються, і ви дізнаєтеся лише зі скарг і chargeback-ів. Половинчасте незавершене налаштування DNSSEC ще гірше: воно може зробити ваш сайт недоступним для зростаючої частини відвідувачів без помилки, яку ви б коли-небудь помітили.
Що це може вам коштувати
- Відвідувачі, що вводять ваш справжній домен, тихо перенаправляються на двійника, що захоплює їхній пароль і карткові дані — і оскільки адресний рядок весь час показує ваш домен, ніхто нічого не підозрює, поки не надходять звіти про шахрайство.
- Ваша пошта тихо перенаправляється: зловмисник підробляє відповідь для ваших поштових серверів, читає або перехоплює повідомлення та скидає паролі на облікові записи, що надсилають вам код — все це без торкання вашої поштової скриньки.
- Наполовину налаштоване DNSSEC (публічна печатка існує, але відповідний ключ відсутній) робить ваш сайт і пошту випадково непрацюючими для клієнтів у великих ISP та корпоративних мережах — переривчасті звіти 'ваш сайт не відкривається', які ви не можете відтворити.
- IT-відділ потенційного клієнта виконує передконтрактну перевірку, бачить відсутній DNSSEC і ставить вам відмітку 'слабкий щодо основ' — ставлячи угоду під ризик через безкоштовне налаштування.
- Державні та великі B2B-покупці все більше очікують DNSSEC як базового стандарту (він згаданий у регуляціях, як-от NIS2); його відсутність тихо дискваліфікує вас від тендерів ще до початку розмови.
Чому це важливо. DNS — це адресна книга інтернету, і за замовчуванням її відповіді подорожують непідписаними — будь-хто, хто може вставити підроблену відповідь, може відправити ваших клієнтів і вашу пошту куди завгодно, поки ваш справжній домен все одно відображається в браузері. DNSSEC ставить захищену від підробки печатку на ці відповіді, щоб їх можна було перевірити як справді ваші. Виправлення безкоштовне у більшості провайдерів; єдина реальна вартість — робити це неправильно, саме тому ми уважно проходимо обидві половини.
DNSSEC простими словами
Кожен раз, коли хтось відвідує ваш сайт або надсилає вам лист, їхній комп’ютер спочатку задає інтернету просте питання: «де насправді живе цей домен?» Відповідь — набір адрес для вашого сайту та поштових серверів — повертається з DNS, адресної книги інтернету.
Ось незручна частина: за замовчуванням ці відповіді подорожують непідписаними. Немає нічого прикріпленого, щоб довести, що відповідь є справжньою. Якщо хтось може вставити підроблену відповідь в цю розмову — а є добре відомі, перевірені способи зробити саме це — комп’ютер вашого відвідувача з радістю прийме її. З цього моменту відвідувач може спілкуватися з сервером зловмисника, поки їхній браузер все одно показує ваше доменне ім’я в адресному рядку.
DNSSEC — це виправлення. Воно додає захищену від підробки цифрову печатку до ваших DNS-відповідей. Коли DNSSEC увімкнений, інтернет може математично перевірити, що відповідь справді прийшла від вас і не була змінена по дорозі. Підроблена відповідь провалює перевірку і відкидається. Це різниця між адресною книгою, в якій може писати будь-хто, і тою, де кожен запис підписаний і засвідчений.
Ця сторінка охоплює дві частини, які наша перевірка розглядає разом: чи опублікована печатка (DS-запис) і чи насправді існує відповідний ключ за нею (DNSKEY-запис). Ви незабаром побачите, чому обидва мають значення — бо мати один без іншого є власним видом проблеми.
Що це може коштувати вам
- Невидиме перенаправлення. Зловмисник отруює DNS-відповідь для вашого домену. Клієнти вводять вашу справжню веб-адресу, бачать ваш справжній домен в рядку і потрапляють на бездоганну копію вашої сторінки входу або каси, розміщеної зловмисником. Кожен пароль і номер картки, що вводять ваші клієнти, передається прямо злочинцю. Ви чуєте про це лише коли надходять chargeback-и і дзвінки «мене зламали через ваш сайт» — і слід веде до вашого бренду, а не зловмисника.
- Тихе перехоплення пошти. DNS вказує не лише на ваш сайт; він вказує на ваші поштові сервери. Підробте цю відповідь і вхідна пошта може бути перенаправлена через зловмисника спочатку. Вони читають чутливі повідомлення, збирають одноразові коди, що сервіси надсилають для «підтвердження, що це ви», і скидають паролі на облікові записи, прив’язані до вашого домену — все це без коли-небудь авторизації в вашу поштову скриньку.
- Збій, який ви не можете відтворити. Цей виникає від наполовину завершеного налаштування DNSSEC. Публічна печатка (DS) знаходиться у вашому реєстраторі, але відповідний ключ (DNSKEY) відсутній або неправильний. Відвідувачі в ISP та корпоративних мережах, що перевіряють DNSSEC — а їх більшає щороку — просто не можуть вирішити ваш домен взагалі. Ваш сайт і пошта чудово працюють для вас і вашої техніки, але частина реальних клієнтів отримує «цей сайт не вдається досягти» без помилки, яку ви можете побачити. Це одна з найважчих для діагностики проблем, саме тому що вона невидима зсередини.
- Втрачена угода. Служба безпеки або закупівель потенційного клієнта проводить рутинне передконтрактне сканування вашого домену. Відсутній DNSSEC з’являється як червона відмітка на «основах безпеки DNS». Для безкоштовного, добре зрозумілого засобу управління, його відсутність читається як недбалість — і це може тихо коштувати вам контракту, про який ви ніколи не знали, що він під загрозою.
- Тендер, для якого ви навіть не кваліфікуєтесь. Регуляції та чеклисти покупців все більше називають DNSSEC очікуваною базовою гігієною (він посилається в рамках DNS-безпекових положень NIS2). Більші B2B та державні покупці можуть відфільтрувати вас ще до початку розмови з продажу, просто тому що прапорець не поставлений.
Що це насправді є
DNSSEC працює як ланцюжок довіри, і він має дві рухомі частини, що повинні узгоджуватися одна з одною. Це суть того, чому наша перевірка дивиться на дві речі.
DNSKEY — ваш ключ. Ваш DNS-провайдер тримає криптографічний ключ і використовує його для підписання ваших DNS-записів. Публічна половина цього ключа публікується як запис DNSKEY. Уявіть це як печатку-штамп, що тримається на вашому кінці.
DS-запис — відбиток, що ручається за ключ. Короткий відбиток цього ключа, що називається записом DS (Delegation Signer), публікується на один рівень вище — у реєстрі вашого домену, через ваш реєстратор. Саме це дозволяє решті інтернету довіряти вашому ключу: кожен рівень ручається за нижче, аж до кореня інтернету. DS — це печатка, офіційно зареєстрована, щоб всі інші могли її розпізнати.
Щоб DNSSEC справді захищав вас, обидва мають бути присутніми і відповідати одне одному:
- DS присутній + DNSKEY присутній і відповідає → добре. Ланцюжок довіри завершений. Підроблені відповіді відхиляються; законні перевіряються. Це стан «прохідний».
- Немає DS (і немає DNSKEY) → DNSSEC просто не увімкнений. У вас немає захисту, але нічого не зламано. Це найпоширеніший стан «ще не зроблено». (У нашому оцінюванні саме тут перевірка DS враховує проти вас; перевірка комбінованого ключа вважає чистий, повністю «вимкнений» стан інформаційним, а не жорстким збоєм, бо нічого активно не ламається.)
- DS присутній, але DNSKEY відсутній або не відповідає → зламано, і гірше, ніж вимкнено. Інтернет бачить опубліковану печатку, що вказує на ключ, якого немає. Перевіряючі вирішувачі роблять висновок, що ваш домен був підроблений, і відмовляються вирішувати його — спричиняючи переривчасті збої, описані вище. Це найтерміновіший стан для виправлення, і наша перевірка позначає його як серйозний.
- DNSKEY присутній, але немає DS у реєстраторі → увімкнено, але не активовано. Ваші записи підписані, але оскільки відбиток так і не був зареєстрований на один рівень вище, решта інтернету не має способу їм довіряти. Ви робите роботу без захисту. Виправлення — додати DS-запис у вашого реєстратора.
Як виглядає «добре» в одному рядку: DS-запис у вашого реєстратора, чий відбиток відповідає живому DNSKEY у вашого DNS-провайдера, обидва підтверджені швидким пошуком.
Як це виправити (безкоштовно, ~10-30 хвилин)
Передайте цей розділ тому, хто керує вашим доменом або сайтом. Саме виправлення безкоштовне у більшості провайдерів — єдина вартість — робити це уважно, щоб дві половини залишалися синхронізованими. Ми беремо плату лише якщо ви пізніше хочете, щоб ми моніторили, що воно правильно залишається увімкненим.
Золоте правило: спочатку вмикайте підписання (що створює DNSKEY), потім публікуйте DS-запис у реєстраторі — ніколи не навпаки і ніколи одне без іншого. Публікація DS до того, як існує ключ, — саме те, що спричиняє збої.
Простий шлях (рекомендований — Cloudflare):
- У Cloudflare переконайтеся, що Cloudflare насправді запускає ваш DNS (ваші сервери імен вказують на Cloudflare).
- Перейдіть до DNS → Settings → DNSSEC → Enable DNSSEC. Cloudflare генерує та керує ключами за вас (це автоматично створює сторону DNSKEY).
- Cloudflare показує вам деталі DS-запису для публікації у вашому реєстраторі.
- Увійдіть до вашого реєстратора домену (наприклад, GoDaddy, Namecheap, OVH) і знайдіть розділ DNSSEC. Вставте значення DS, що дав вам Cloudflare.
- Зачекайте 24-48 годин для повного поширення. Ваш сайт і пошта продовжують працювати протягом усього часу.
Інші DNS-провайдери (AWS Route 53, ваш веб-хост тощо):
- У панелі керування DNS-провайдера вмикайте DNSSEC / «підписати цю зону». Це генерує ключі підписання і публікує DNSKEY-записи.
- Скопіюйте DS-запис, що виробляє провайдер.
- Додайте цей DS-запис у вашого реєстратора під його налаштуваннями DNSSEC.
- Підтвердіть, що реєстратор прийняв його, і зачекайте поширення.
Примітки по платформі:
- Cloudflare — одне натискання для вмикання, потім одна вставка DS у реєстратора. Найлегший шлях на сьогодні.
- AWS Route 53 — вмикайте підписання DNSSEC в розміщеній зоні, потім додайте DS-запис у реєстратора вашого домену (якщо домен зареєстрований у Route 53, AWS може зв’язати його для вас).
- Microsoft 365 / Google Workspace — вони запускають вашу пошту, а не зазвичай вашу DNS-зону. DNSSEC вмикається там, де DNS-записи насправді знаходяться (часто ваш реєстратор, хост або Cloudflare), не в центрі адміністратора 365/Workspace.
- Ваш DNS-провайдер взагалі не підтримує DNSSEC? Це поширено зі старішими або бюджетними хостами. Чисте виправлення — перемістити управління DNS до провайдера, що підтримує (Cloudflare безкоштовний), потім дотримуватися простого шляху вище. Переміщення DNS не вимагає переміщення вашого сайту або пошти.
Перевірте, що воно спрацювало:
- Запустіть
dig DS yourdomain.comіdig DNSKEY yourdomain.com— обидва повинні повертати записи. - Або використайте будь-який безкоштовний онлайн-DNSSEC-чекер і підтвердіть зелений/дійсний ланцюжок довіри.
- Не вважайте це зробленим, поки обидва не повернуть відповідні записи. DS без DNSKEY — зламаний стан — виправте або видаліть його негайно.
Поширені помилки
- Публікація DS до того, як існує ключ. Єдина найбільш шкідлива помилка: додавання DS-запису у реєстраторі до того, як підписання насправді живе у DNS-провайдера. Це створює стан «опублікована печатка, відсутній ключ», що робить ваш домен нерозв’язним для відвідувачів з DNSSEC-перевіркою. Завжди спочатку вмикайте підписання, потім публікуйте DS.
- Залишення застарілого DS після зміни провайдерів. Якщо ви переходите до DNS-провайдерів (або вимикаєте підписання), але забуваєте видалити або оновити старий DS-запис у реєстраторі, ви залишаєтесь з вказівкою на ключ, якого більше не існує — той самий зламаний результат. Коли ви вимикаєте DNSSEC або переміщуєте його, оновіть DS у реєстраторі в тій самій зміні.
- Зупинка після першого кроку. Вмикання підписання у DNS-провайдері (створення DNSKEY), але ніколи не додавання DS у реєстраторі. Все виглядає «увімкненим» в інформаційній панелі DNS, але без DS захист ніколи не активується. Ви зробили роботу і не отримали нічого від переваги.
- Припускаючи, що HTTPS або аутентифікація пошти вже покриває це. Замок і аутентифікація пошти (SPF / DKIM / DMARC) є цінними, але вирішують різні проблеми. Жодна з них не зупиняє підроблену DNS-відповідь від відправки відвідувачів не туди спочатку.
- Не моніторити після вмикання. Ключі обертаються, провайдери змінюються, записи редагуються. Налаштування, що ідеальне сьогодні, може тихо зламатися через місяці. Якщо DNSSEC достатньо важливий для вмикання, варто periodically перевіряти, що він все ще дійсний.
Налаштуйте на своєму хості
Покроково для популярних провайдерів:
- Налаштувати DNSSEC на GoDaddy
- Налаштувати DNSSEC на Namecheap
- Налаштувати DNSSEC на Cloudflare
- Налаштувати DNSSEC на AWS Route 53
FAQ
Я не технічний фахівець — чи повинен я особисто з цим розібратися?
Ні. Вам потрібно розуміти, чому це важливо (ця сторінка охоплює це), але фактична зміна знаходиться у вашому DNS і налаштуваннях реєстратора, тому вона належить тому, хто керує вашим доменом або сайтом. Передайте їм розділ «Як це виправити» — це безкоштовно і зазвичай займає менше півгодини. Ми беремо плату лише якщо ви пізніше хочете, щоб ми продовжували стежити за тим, що це правильно увімкнено.
Якщо мій сайт вже має замок (HTTPS), хіба я вже не захищений?
Вони захищають різні речі. Замок захищає з'єднання, як тільки відвідувач досягнув правильного сервера. DNSSEC захищає крок до цього — переконуючись, що вони взагалі досягли правильного сервера. Зловмисник, що підробляє ваш DNS, може відправити відвідувачів на свій власний сервер, що може мати власний дійсний замок на схожому домені або навіть копії вашого. Вам потрібні обидва; один не замінює інший.
Чи може ввімкнення DNSSEC зламати мій сайт або пошту?
При вмиканні в одному місці провайдером, що його підтримує, — ні, сучасні провайдери керують ключами за вас і це просто працює. Ризик виникає при виконанні в двох відключених кроках і завершенні лише одного: публікації публічної «печатки» (DS-запис) у вашому реєстраторі, поки відповідний ключ (DNSKEY) відсутній або не відповідає. Цей зламаний стан гірше, ніж відсутність DNSSEC і спричиняє переривчасті збої. Кроки нижче тримають дві половини синхронізованими, щоб цього не сталося.
Ми використовуємо Cloudflare / Google Workspace / Microsoft 365 — чи це покрито?
Не автоматично, але це полегшує. Важливо, де керується ваш DNS. Якщо Cloudflare запускає ваш DNS, це одне натискання плюс вставка одного запису у вашому реєстраторі. Microsoft 365 і Google Workspace обробляють пошту, а не зазвичай вашу DNS-зону — DNSSEC вмикається там, де фактично знаходяться DNS-записи вашого домену (часто Cloudflare, ваш реєстратор або ваш хост). Кроки нижче охоплюють поширені випадки.
Що саме таке 'DS' і 'DNSKEY' — і чому ця сторінка згадує обидва?
Це дві половини одного замка. DNSKEY — це ключ, що ваш DNS-провайдер тримає і використовує для підписання ваших записів. DS — це відбиток цього ключа, опублікований на один рівень вище у вашому реєстраторі, щоб решта інтернету могла підтвердити, що ключ справді ваш. Обидва повинні бути присутніми і відповідати одне одному. Ми перевіряємо обидва: відсутній DS означає, що DNSSEC не увімкнений; DS без відповідного DNSKEY означає, що він увімкнений, але зламаний.
Скільки часу, поки він запрацює, і як я підтвердити?
Дозвольте 24-48 годин для повного поширення зміни по інтернету; ваш існуючий сайт і пошта продовжують працювати протягом усього часу, якщо це зроблено правильно. Для підтвердження ваш IT-фахівець може запустити 'dig DS yourdomain' і 'dig DNSKEY yourdomain' і бачити записи, що повертаються для обох, або використати будь-який безкоштовний онлайн-DNSSEC-чекер. Ми також можемо постійно моніторити його, щоб майбутній збій був виявлений в день, а не в день, коли скаржиться клієнт.