DNSSEC

Спочатку Domain Name System (DNS) розроблявся не в цілях безпеки, а для створення масштабованих розподілених систем. З часом система DNS стає все уразливішою. Зловмисники без труднощів перенаправляють запити користувачів по символьному імені на підставні сервери і таким чином отримують доступ до паролів, номерів кредитних карт і іншої конфіденційної інформації. Самі користувачі нічого не можуть з цим поробити, оскільки в більшості випадків навіть не підозрюють про те, що запит був перенаправлений. DNSSEC є спробою забезпечення безпеки при одночасній зворотної сумісності.

DNSSEC була розроблена для забезпечення безпеки клієнтів від фальшивих DNS даних, наприклад, створюваних DNS cache poisoning. Усі відповіді від DNSSEC мають цифровий підпис. При перевірці цифрового підпису DNS розпізнавач перевіряє вірність та цілісність інформації. Хоча захист IP адрес є безпосередньою проблемою для багатьох користувачів, DNSSEC може захистити іншу інформацію, таку як криптографічні сертифікати загального призначення, що зберігаються в CERT record DNS. RFC 4398 описує, як розподілити ці сертифікати, у тому числі електронною поштою, що дозволяє використовувати DNSSEC як глобальну інфраструктуру відкритих ключів електронної пошти.

DNSSEC не забезпечує конфіденційність даних; зокрема, всі DNSSEC відповіді аутентіфіковані, але не шифруються. DNSSEC не захищає від DoS-атак безпосередньо, хоча певною мірою робить це побічно. Інші стандарти (не DNSSEC) використовуються для забезпечення великої кількості даних, що пересилаються між серверами DNS.

DNSSEC специфікації (DNSSEC-bis) докладно описують поточний протокол DNSSEC. Див RFC 4033, RFC 4034 та RFC 4035.

DNS є одним з найважливіших і основних інтернет-сервісів. Проте в 1990 Стів Белловін (Steve Bellovin) виявив серйозні недоліки в безпеці. Дослідження в цій області почалися і проводилися повним ходом з часів публікації доповіді в 1995.

RFC 2065 був опублікований IETF в 1997. Перші спроби реалізації цієї специфікації призвели до нової специфікації RFC 2535 у 1999. Було заплановано реалізовувати DNSSEC, ґрунтуючись на IETF RFC 2535.

На жаль, у специфікації IETF RFC 2535 були дуже серйозні проблеми з масштабуванням на весь інтернет. До 2001 року стало ясно, що ця специфікація була непридатна для великих мереж. При нормальній роботі DNS сервери часто десинхронізіровалися зі своїми батьками. Зазвичай це не було проблемою, але при включеному DNSSEC десинхронізовані дані могли нести мимовільний DoS ефект. Дійсний DNSSEC вимагає складного протоколу з шести повідомлень і велику кількість даних для здійснення змін спадкоємця (всі DNS зони спадкоємця повинні бути повністю передані батькам, батько вносить зміни і відправляє їх спадкоємцю). Крім того, зміни у публічному ключі можуть мати абсурдний ефект. Наприклад, якщо зона ". Com" змінить свій ключ, доведеться відправити 22 млн записів (тому що доведеться оновити всі записи у всіх спадкоємців). Таким чином, DNSSEC у вигляді RFC 2535 не може бути масштабований до розміру інтернету.

IETF здійснила принципову зміну DNSSEC, яке називається DNSSEC-bis (назва була дана щоб відрізняти DNSSEC-bis від первісного підходу DNSSEC в RFC 2535). Нова версія використовує принцип DS (англ. Delegation Signer) для забезпечення додаткового рівня непрямої делегації при передачі зон від батька до спадкоємця. У новому підході при зміні відкритого ключа відсилається тільки одне повідомлення замість шести: спадкоємець посилає новий відкритий ключ батьку. Батько просто зберігає один відкритий ключ для кожного із спадкоємців. Це означає, що зовсім невелика кількість даних буде відправлено батькові замість обміну величезною кількістю даних між спадкоємцем і батьком. Це також означає, що спадкоємцям доведеться здійснювати додаткові дії для перевірки ключів. Більшість вважає, що це невелика плата за можливість практичнішого застосування DNSSEC.

DNSSEC вже набув великого поширення в усьому світі. Тепер, з ініціативи російського реєстратора доменних імен R01, домен RU також інтегрований у систему DNSSEC.

перший варіант використання DNSSEC другий варіант використання DNSSEC

В основі дії протоколу DNSSEC лежить метод цифрового підпису відповідей на запит DNS lookup, який забезпечує недоторканність даних в системі DNS. Для цього було створено кілька типів DNS записів, в їх числі RRSIG, DNSKEY, DS і NSEC. Вся інформація про захищений домен (COM, NET, UA ...) в системі DNSSEC певним чином зашифрована, тому може бути змінена тільки за допомогою закритого ключа шифрування. У процесі захищеного делегування домену відбувається генерація пари ключів. Інформація про ключі зберігається на первинному DNS-сервері. Закритий ключ використовується для підпису зони після кожної зміни. Цифровий підпис закритого ключа DS-запису (англ. Designated Signer) передається адміністратору батьківської зони і підписується його особистим ключем. Таким чином організовується ланцюжок довіри. Знаючи відкритий ключ адміністратора батьківської зони можна перевірити валідність відкритого ключа в будь-який з дочірніх зон.

Отримавши доступ до файлів з описом домену на первинному або вторинному серверах DNS або під час передачі даних між серверами, зловмисник не зможе внести зміни, тому що не є власником закритого ключа - будь-які несанкціоновані зміни файлів будуть відкинуті як недостовірні. Так само ні до чого не призведе спроба зловмисника послати динамічний запит на оновлення даних про домен від імені іншої системи. Кешуючі сервери провайдера (організації) і призначені для користувача системи (резолверів) також перевіряють достовірність змін, використовуючи відкритий ключ.

Інтернет вважається найважливішим засобом інфраструктури, проте його працездатність залежить від принципово небезпечного DNS. Таким чином, існує великий стимул убезпечити DNS, і застосування DNSSEC, як правило, вважається найважливішою частиною роботи.

Однак DNSSEC має складності у розвитку. Крім того, розгортання DNSSEC у великомасштабних мережах також проблематично. DNS сервери повинні бути оновлені програмним забезпеченням, що підтримує DNSSEC. Клієнт, який використовує TCP/IP повинен мати оновлений DNS Resolver для використання можливостей DNSSEC. Більш того, будь-який DNS Resolver повинен мати спосіб отримати принаймні один достовірний відкритий ключ до того, як він почне використовувати DNSSEC. Для вирішення цих завдань вже ведеться значна робота, тому що інтернет має настільки важливе значення для багатьох організацій. [Ред] Підпис кореневої зони

Для повноцінної валідації всіх даних, передаваних за допомогою DNSSEC, потрібна ланцюжок довіри, що йде від кореневої зони (.) DNS. Впровадження підписаної коректним чином кореневої зони на всі кореневі сервери DNS могло викликати крах сучасного Інтернету, тому IETF разом з ICANN була розроблена поступова процедура впровадження підписаної кореневої зони та механізму поширення ключів. Процедура затягнулася більше, ніж на 8 місяців і включала в себе покрокове впровадження на сервери DNS спочатку кореневої зони, підписаної недійсним ключем електронного підпису. Цей крок був необхідний для того, щоб забезпечити тестування серверів під навантаженням, зберегти зворотну сумісність зі старим програмним забезпеченням і залишити можливість відкату до попередньої конфігурації.

До червня 2010 року всі кореневі сервери коректно працювали з зоною, підписаної невалідним ключем. У липні ICANN провів міжнародну конференцію, присвячену процедурі генерації ключів електронного підпису, яким згодом була підписана коренева зона.

15 липня 2010 відбулося підписання кореневої зони і почалося впровадження підписаної зони на сервери. 28 липня ICANN повідомив [2] про завершення цього процесу. Коренева зона була підписана електронним підписом і розповсюдилася в системі DNS.

ICANN вибрав таку модель, коли управління підписанням зони відбувається під контролем представників інтернет-співтовариства (Trusted community representative, TCR). Представники вибиралися з числа не пов'язаних з керуванням кореневої зони DNS. Вибрані представники обіймали посади крипто-офіцерів (Crypto Officer, CO) і власників частин ключа відновлення (Recovery key shareholder, RKSH). CO були вручені фізичні ключі, що дозволяють активувати генерацію ключа ЕЦП ZSK, а RKSH володіють смарт-картками, що містять частини ключа (KSK), використовуваного всередині криптографічного обладнання. Деякими ЗМІ був зроблений висновок, що процедури, які потребують присутності CO або RKSH, будуть проводитись у разі надзвичайних ситуацій в мережі [3]. Проте відповідно до процедур ICANN, CO будуть залучатися кожен раз при генерації ключа підписання зони (ZSK), до 4 разів на рік, а RKSH - ймовірно, ніколи або у разі втрати ключів CO або скомпрометованої кореневої зони [4].

На жовтень 2010 року в кореневій зоні присутні 39 національних доменів верхнього рівня і 9 загальних доменів верхнього рівня, підписаних DNSSEC і забезпечують таким чином ланцюжок довіри доменах другого рівня. У 2011 році очікується підписання російського домену. Ru. [5] У лютому 2012-го розпочалося тестування серверу DNSSEC для домену .UA [7].

Використання DNSSEC вимагає програмного забезпечення як на серверної, так і на клієнтській стороні.

• BIND (англ. Berkeley Internet Name Domain).
• Drill це інструмент з підтримкою DNSSEC що входить в набір інструментів ldns.
• DNSSEC-Tools проект SourceForge спрямований на забезпечення простого у використанні набору інструментів для роботи з DNSSEC.
• Unbound Резолвер написаний з нуля, ґрунтуючись на принципах роботи DNSSEC.
• Підтримка DNSSEC була надана в Windows 7 і Windows Server 2008 R2. [6]
• MysqlBind
• OpenDNSSEC

1. "Using the Domain Name System for System Break-Ins" by Steve Bellovin, 1995
2. DNSSEC Root Signing Announcement
3. Шести программистам раздали "ключи для перезагрузки интернета"
4. DNSSEC for the Root Zone
5. А. Ильин, ТЦИ. Опыт создания пилотной зоны DNSSec для RU
6. DNSSEC in Windows Server
7. В домене .UA появился "Маяк DNSSEC"

• DNSSEC - DNSSEC інформаційний сайт: DNSSEC.ru
• DNSSEC - DNSSEC information site: DNSSEC.net
• DNSEXT DNS Extensions IETF Working Group
• CircleID - News and Opinions on all DNSSEC related issues
• DNSSEC-Tools Project
• DNSSEC Deployment Coordination Initiative