11 жовтня 2026 року о 14:00 за UTC (17:00 за київським часом) кореневу зону DNS — вершину системи доменних імен — почав підписувати новий криптографічний ключ KSK-2024. Це лише друга заміна так званого «головного ключа Інтернету» відтоді, як корінь DNS захистили підписами у 2010 році. За повідомленням ICANN, заміну завершено за планом, хоча організація ще перевіряє повідомлення про проблеми на окремих системах. Більшість людей нічого не помітили — і саме так усе мало відбутися.
Головне
11 жовтня 2026 року кореневу зону DNS почав підписувати новий ключ KSK-2024 (key tag 38696); попередній KSK-2017 пропрацював вісім років.
За вимірюваннями APNIC, глобального збою не сталося: частка користувачів за резолверами з перевіркою DNSSEC зросла з 39,7% до 40,6%.
«Сім ключів від Інтернету» — міф: у церемоніях беруть участь 14 криптоофіцерів і 7 власників часток ключа відновлення, а для роботи апаратного модуля потрібні 3 смарт-карти із 7.
Звичайним користувачам нічого робити не потрібно; адміністраторам власних DNS-резолверів варто переконатися, що в них є ключ 38696, до 11 січня 2027 року.
Наступний крок — перехід кореня DNS з RSA на ECDSA: новий ключ планують згенерувати у 2027 році, а RSA вивести з ужитку до 2030-го.
Що таке ключі захисту Інтернету
Коли йдеться про «ключі захисту Інтернету» чи «ключі від Інтернету», найчастіше мають на увазі одну конкретну річ — кореневий ключ DNSSEC, офіційно Root Zone Key Signing Key (KSK). Його також називають «якорем довіри» (trust anchor): саме з нього починається перевірка справжності адрес у мережі.
DNS працює як довідник Інтернету: перетворює зрозумілі людині адреси на кшталт cybercalm.org на IP-адреси серверів. Спочатку ця система не мала захисту від підробки: відповідь DNS можна було підмінити, і користувач потрапляв на фальшивий сайт, навіть правильно ввівши адресу. Розширення DNSSEC (Domain Name System Security Extensions) додає до записів DNS криптографічні підписи. Завдяки їм резолвер — сервер, який шукає адреси замість користувача, — може перевірити, що відповідь справжня і її не змінили в дорозі.
Підписи утворюють ланцюжок довіри згори донизу. KSK підписує інший ключ — ключ підписування зони (Zone Signing Key, ZSK), а вже ZSK підписує дані кореневої зони, зокрема записи доменів верхнього рівня, які своєю чергою ручаються за домени нижче. Якщо резолвер не довіряє ключу на самій вершині, він не зможе перевірити жодної відповіді під ним. Ролі розподілені між двома організаціями: ICANN є оператором KSK, а компанія Verisign — оператором ZSK.
Читайте також30 цікавих фактів про інтернет: історія, цифри та міфи
Що сталося 11 жовтня 2026 року
Того дня кореневу зону почав підписувати KSK-2024 з ідентифікатором (key tag) 38696, а KSK-2017 з ідентифікатором 20326 перестав її підписувати. Попередній ключ виконував цю роботу вісім років — з 11 жовтня 2018-го.
Заміна не була раптовою. Новий ключ згенерували 26 квітня 2024 року, а з 11 січня 2025-го його відкрита частина вже перебувала в кореневій зоні. Майже два роки резолвери в усьому світі мали, щоб «познайомитися» з ним. Механізм RFC 5011 дозволяє резолверу автоматично додати новий ключ до довірених, якщо той протягом 30 днів спостерігається в зоні підписаним чинним ключем. Уже за місяць після публікації більшість резолверів почали довіряти KSK-2024, а приблизно за 500 днів частка тих, що його прийняли, перевищила 95%.
Після перемикання наслідки проявляються не одразу: кешована копія кореневого набору ключів зберігається в резолверах два дні, тому справжня перевірка готовності тривала до 13 жовтня.
Чи все пройшло гладко
Вимірювання APNIC, оприлюднені 21 жовтня, свідчать: масштабного збою DNS не сталося, а глобальна частка перевірок DNSSEC навіть зросла — з 39,7% до 40,6%. Проте середні цифри приховують локальні проблеми. Великого індійського провайдера встигли попередити 9 жовтня, і він вчасно виправив налаштування; з бразильськими провайдерами звʼязатися не вдалося, і частка валідації в Бразилії впала з 54% до 50%. Загалом дослідники нарахували 660 мереж, де рівень перевірки DNSSEC після заміни знизився на 10% і більше.
Для користувача такий збій виглядає неочевидно: резолвер без нового ключа не може визначити жодного домену — ні підписаного, ні непідписаного — і масово повертає помилку SERVFAIL. Сайти працюють, але їхні імена раптом перестають «відкриватися». Саме так сталося, наприклад, із власниками роутерів OpenMPTCProuter, які встановили прошивку менш ніж за 30 днів до заміни: 12 жовтня в них перестали визначатися зовнішні адреси.
ICANN продовжує моніторинг: процес заміни ще не завершено.
Що далі
11 січня 2027 року KSK-2017 опублікують із позначкою відкликання (REVOKE), щоб резолвери, які підтримують RFC 5011, перестали йому довіряти.
22 березня 2027 року KSK-2017 видалять з кореневої зони.
Хронологія: від незахищеного DNS до третього кореневого ключа
Дата Подія 1983 Створено систему DNS — без вбудованих механізмів захисту від підробки. 2005 Опубліковано стандарти DNSSEC — RFC 4033–4035. 16 червня 2010 Згенеровано перший кореневий ключ KSK-2010. 15 липня 2010 KSK-2010 почав підписувати кореневу зону — у мережі зʼявився єдиний якір довіри. 27 березня 2012 Зону .UA підписано DNSSEC; 13 квітня її запис додано до кореня. 27 жовтня 2016 Згенеровано KSK-2017. Вересень 2017 Першу заміну ключа відклали на рік: телеметрія показала, що частина резолверів не готова. 11 жовтня 2018 Перша заміна: KSK-2017 замість KSK-2010. 2019 KSK-2010 відкликано 11 січня і видалено 22 березня. Зона .UA перейшла на алгоритм ECDSA. 27 квітня 2023 Згенеровано KSK-2023, але від нього відмовилися: апаратні модулі безпеки (HSM), що зберігали ключ, завершували строк підтримки. 26 квітня 2024 Згенеровано KSK-2024 — уже на нових HSM іншого виробника. 11 січня 2025 KSK-2024 опубліковано в кореневій зоні. 11 жовтня 2026 KSK-2024 почав підписувати кореневу зону. 11 січня 2027 Заплановане відкликання KSK-2017. 22 березня 2027 Заплановане видалення KSK-2017.
Як часто змінюються ключі
Кореневих ключів два типи, і живуть вони по-різному. ZSK змінюють кожні 90 днів — це рутина, яку ніхто не помічає. KSK змінюють значно рідше. Спершу йому відводили пʼять років, але перший ключ прослужив набагато довше — вісім.
Тепер IANA планує ідеалізований трирічний цикл: новий ключ приблизно два роки перебуває в кореневій зоні в режимі очікування, а наступника генерують після кожної заміни. Такий інтервал, за поясненням IANA, — баланс: процедури й програмне забезпечення залишаються готовими до нових ключів, а надто часті заміни не ускладнюють роботу. Довгий період очікування до того ж дає змогу прискорити заміну, якщо виникне потреба.
Хто насправді тримає «ключі від Інтернету»
Популярна історія про «сімох людей, які володіють ключами від Інтернету», — спрощення. ICANN пояснює: безпосередньо в церемоніях задіяно близько пʼятдесяти експертів, частину з них поділено на три групи по сім осіб — звідси й міф про «сім ключів».
Ці люди — Trusted Community Representatives (TCR), довірені представники інтернет-спільноти. Їх обирають із заявок технічної спільноти; людина, повʼязана з PTI, ICANN чи Verisign, стати TCR не може. Станом на жовтень 2026 року до складу входять 14 криптоофіцерів — по сім для кожного з двох обʼєктів, — 7 власників часток ключа відновлення та 12 резервних представників. Криптоофіцери й власники часток представляють 17 країн — від Австралії та Чилі до Зімбабве та Ісландії. Представників України серед них немає.
Криптоофіцери (Cryptographic Officers)
Щоб апаратний модуль безпеки працював під час церемонії, потрібно активувати 3 із 7 смарт-карт, виданих для цього HSM. ICANN намагається, щоб на кожній церемонії було щонайменше четверо криптоофіцерів — на випадок, якщо хтось не зможе виконати свою роль.
Важливе уточнення: смарт-карта — не «шматочок» кореневого ключа, а лише засіб увімкнути модуль, у якому ключ зберігається. Самі по собі ці фізичні ключі (металеві або смарт-карти) не дають доступу до кореневого ключа: для цього представникам довелося б опинитися всередині захищеного обʼєкта, а сейф із резервними картами мав би бути відчинений.
Власники часток ключа відновлення (Recovery Key Share Holders)
ICANN тримає по два HSM на кожному обʼєкті, а на найнеймовірніший випадок — зашифровану резервну копію кожного кореневого ключа в сейфі на кожному обʼєкті. Власники часток ключа відновлення беруть участь у процесах генерації та резервного копіювання ключа — їхня роль потрібна саме для сценарію, коли ключ доведеться відновлювати з резервної копії.
Як відбувається церемонія ключа
Церемонії KSK зазвичай проводять чотири рази на рік у захищених приміщеннях. Під час типової церемонії ключем підписують матеріал, який використовуватимуть у DNSSEC протягом наступних місяців. Обʼєктів два, і обидва розташовані в США: Root Zone Key Management Facility East у Калпепері (Вірджинія) та Root Zone Key Management Facility West в Ель-Сегундо (Каліфорнія). Кожна церемонія триває від трьох до восьми годин.
Головний принцип — прозорість. Церемонії публічні: їх транслюють онлайн, а після завершення оприлюднюють записи та матеріали. Наприклад, для церемонії 62 опубліковано записи трьох аудиторських камер, анотований сценарій, журнали підписування й навіть образ операційної системи підписувального компʼютера.
Спрощено церемонія виглядає так:
Учасники проходять контроль доступу до захищеного приміщення. Дії виконуються строго за сценарієм, а внутрішній свідок фіксує будь-які відхилення від нього.
Із сейфів дістають апаратний модуль безпеки та смарт-карти криптоофіцерів.
Криптоофіцери активують HSM своїми картами — потрібно щонайменше 3 із 7.
Кореневим ключем підписують ключі ZSK на наступний квартал. Сам ключ при цьому не залишає HSM: це не файл, а цифровий ключ, який зберігається всередині апаратного модуля.
Обладнання повертають у сейфи, а записи й журнали церемонії публікують.
Церемонія, яка підготувала заміну
Церемонія 62 відбулася 12 серпня 2026 року в Ель-Сегундо: на ній підписали ZSK на четвертий квартал 2026 року та знищили два старі апаратні модулі — 5W і 6W. Саме в цьому кварталі відбулося перемикання на KSK-2024, тож підписи, які почали діяти 11 жовтня, створили ще в серпні. Серед оприлюднених журналів — підписи як для переходу до нової фази заміни ключа, так і для резервних сценаріїв її відкату.
Наступну, 63-тю церемонію заплановано на 12 листопада 2026 року в Калпепері — на ній підпишуть ZSK на перший квартал 2027 року.
Що станеться, якщо ключ викрадуть
Загроза реальна, але її часто перебільшують. Компрометація KSK дала б змогу створювати «правильні» з погляду DNSSEC підписи для будь-якого домену. Утім між викраденим ключем і масштабною атакою — кілька серйозних перешкод:
Підроблену відповідь ще треба доставити жертві. Для цього зловмисник має опинитися на шляху трафіку або атакувати кеш резолвера — самого ключа для цього замало.
За оцінкою APNIC, лише близько 40% користувачів у світі працюють через резолвери, що перевіряють DNSSEC. Для решти підписи взагалі не перевіряються, тож підробити для них DNS можна й без кореневого ключа.
HTTPS додає окремий рубіж: підмінена адреса сама по собі не дає зловмиснику дійсного сертифіката для чужого домену, тож браузер попередить про проблему.
У разі компрометації довелося б провести позапланову заміну ключа. Тривалий період, протягом якого наступний ключ заздалегідь перебуває в кореневій зоні, передбачено зокрема для того, щоб у разі потреби пришвидшити заміну. Але навіть тоді частині операторів довелося б оновлювати якорі довіри вручну, а це означає тимчасові збої для користувачів їхніх мереж.
Як захищено ключ
Апаратне зберігання. Кореневий ключ — не файл, а цифровий ключ усередині апаратного модуля безпеки.
Дублювання. Два обʼєкти, по два HSM на кожному, плюс зашифровані резервні копії в сейфах.
Розподіл повноважень. Для роботи модуля потрібні 3 із 7 смарт-карт, а їхніми власниками не можуть бути люди, повʼязані з ICANN, PTI чи Verisign.
Публічність. Церемонії транслюють, записи й журнали публікують, а процеси керування ключем проходять сертифікацію незалежним аудитором.
Що це означає для користувачів і адміністраторів
Для більшості — нічого. Домашні користувачі, які покладаються на DNS провайдера або великого публічного резолвера, не мали робити жодних дій.
Більшість користувачів Інтернету не помітять жодних змін, однак операторам DNS-програм варто заздалегідь переконатися, що їхні системи правильно налаштовані й довіряють новому ключу
Кім Девіс, віцепрезидент ICANN з питань IANA, президент PTI
Перевірка потрібна тим, хто сам підтримує резолвер із перевіркою DNSSEC: на сервері компанії, домашньому сервері чи роутері (наприклад, з Unbound або BIND). Порядок дій такий:
Переконатися, що серед якорів довіри є ключ з ідентифікатором 38696. Типові файли: bind.keys (ISC BIND), root.key (Unbound і PowerDNS Recursor), root.keys (Knot Resolver).
Якщо ключа немає — перевірити, чи ввімкнено автоматичне оновлення якорів довіри і чи має процес резолвера право запису до каталогу з ключами. ICANN радить не вважати, що автоматичне оновлення спрацювало, а перевірити це.
Перевірити довіру до нового ключа на практиці можна механізмом KSK Sentinel: запит до імені виду root-key-sentinel-is-ta-38696 має повертати відповідь, а до root-key-sentinel-not-ta-38696 — помилку SERVFAIL.
Якщо збій уже стався, ICANN пропонує тимчасово вимкнути перевірку DNSSEC або налаштувати для кореня негативний якір довіри (RFC 7646), а потім якнайшвидше встановити KSK-2024 і знову ввімкнути перевірку.
Усе це варто зробити до 11 січня 2027 року, коли KSK-2017 офіційно відкличуть.
А що з доменом .UA
Українська доменна зона пройшла цей шлях раніше за багатьох. Зону .UA підписали DNSSEC у березні 2012 року, а в квітні її запис зʼявився в корені. У 2019 році адміністратор зони — компанія Hostmaster — перевів ключ .UA на алгоритм ECDSA P-256 і запровадив DNSSEC для реєстраторів у публічних доменах — тобто власник домену в .ua може попросити свого реєстратора підписати його зону.
Майбутнє: ECDSA, а потім постквантова криптографія
Ані під час першої заміни у 2018 році, ані під час нинішньої алгоритм кореневого ключа не змінювався — корінь DNS досі підписують RSA. Це наступний крок. У лютому 2026 року ICANN винесла на публічне обговорення план: згенерувати новий кореневий ключ на ECDSA P-256 у 2027 році й вивести RSA-ключ з ужитку до 2030-го. На час переходу обидва алгоритми працюватимуть паралельно, а розмір RSA-ключа ZSK заздалегідь зменшать з 2048 до 1536 біт, щоб відповіді DNS рідше доводилося обрізати й повторно передавати через TCP. Комітет ICANN із безпеки та стабільності (SSAC) підтримав перехід.
ECDSA дає компактніші ключі й підписи, але не є постквантовим алгоритмом. Досвід зміни алгоритму на вершині DNS знадобиться пізніше — учасники обговорення вже просять ICANN врахувати його для майбутніх постквантових переходів. Детальніше про те, чому квантові компʼютери загрожують сучасній криптографії, — у матеріалах про постквантову криптографію та квантово-захищене шифрування.
Висновки
Заміна кореневого ключа DNS у жовтні 2026 року показала, як має працювати критична інфраструктура: майже два роки підготовки, публічні церемонії, вимірювання на кожному етапі — і подія, яку більшість людей навіть не помітили. «Ключі від Інтернету» — не чарівний вимикач у руках кількох людей, а ретельно розподілена система довіри, у якій жодна людина чи організація не може діяти одноосібно.
Проте ланцюжок довіри настільки міцний, наскільки міцна його найслабша ланка. Для більшості користувачів нею є не кореневий ключ, а налаштування їхнього провайдера, роутера чи корпоративного DNS-сервера. Саме тому наступні етапи — відкликання старого ключа в січні 2027-го та перехід на ECDSA — потребуватимуть такої самої уваги адміністраторів, як і 11 жовтня.
Ця стаття Ключі захисту Інтернету: хто їх контролює, як у 2026 році змінили кореневий ключ DNS і що буде, якщо його викрадуть раніше була опублікована на сайті CyberCalm, її автор — Олена Кожухар
