Принципи роботи системи розпізнавання імен
Коренева зона, яка містить інформацію про всіх піддоменів: net. com. org. ru. su. і т.д. Точніше, інформацію про серверах, обслуговуючих ці домени.
Домен ripe. що містить інформацію про всіх піддоменів, а також імена серверів, зареєстрованих безпосередньо в цьому домені, наприклад www. ripe. net.
Рис 1 Процес трансляції імен в DNS
Така архітектура DNS дозволяє розподілити навантаження і відповідальність за роботу системи між адміністраторами окремих доменів. В їх обов'язки входить забезпечення нормальної продуктивності при відповіді на запити до зони, підтримка унікальності імен в рамках зони а також повідомлення адміністратора батьківської зони про зміни в складі серверів, які обслуговують зону.
Ця ієрархічно розподілена архітектура DNS забезпечила долгожітіе системи і її еволюційний розвиток вже протягом більше чверті століття.
Але є в системі DNS одна особливість, яка відрізняє її від багатьох інших систем Інтернету, мають децентралізований характер. Це та сама точка, корінь дерева DNS. звідки починаються всі свіжі запити. Про нього ми і поговоримо докладніше.
Кореневої рівень DNS
Кореневі сервери (КС) DNS є критичним компонентом системи, оскільки забезпечують доступ до кореневої зоні DNS. Коренева зона містить інформацію про всі доменах самого верхнього рівня: національні домени (наприклад .ru), домени загального призначення (наприклад .com) і спонсоровані домени (наприклад .museum). Ця інформація вказує клієнту на які сервери DNS відправити наступний запит для продовження дозволу повного доменного імені. Іншими словами, будь-який "свіжий" (тобто не було збережено в кеші клієнта) запит починається зі звернення до кореневого сервера.
Сьогоднішня система кореневих серверів і координація її роботи
Розглянемо докладніше учасників СКС. Для цього звернемося до процесу внесення змін до вміст кореневої зони, представленому на малюнку 2.
Рис 2 Процес внесення змін до кореневу зону
Повідомлення про порушення надходить від адміністратора домену верхнього рівня (ccTLD, gTLD, і т.д.) і обслуговується IANA. Типовим прикладом такого запиту є зміна складу серверів, які обслуговують домен.
Потім зміни направляються організації, відповідальної за фактичне редагування і публікацію зони в DNS. Цю роль в даний час виконує компанія VeriSign. До речі, ця ж компанія є оператором 2 кореневих серверів - a.root-servers.net і j.root-servers.net.
Зона спочатку публікується на прихованому майстер-сервері і потім поширюється на всі репліки з використанням протоколу TSIG, що захищає дані від модифікації при передачі.
Оператори КС
Операторами КС є різні організації, які отримали право керування серверами у відносно віддаленому минулому, коли подібні питання вирішувалися менш формально. Серед операторів знаходяться університети, організації Міністерства Оборони США, некомерційні асоціації. Оператори є фінансово і юридично незалежними від корпорації ICANN, в рамках якого діє IANA. При прийнятті операційних рішень оператори керуються технічної доцільністю і існуючими стандартами (наприклад, RFC2870), в основному підтримуючи статус-кво. Найбільшим рішенням такого роду, прийнятого незалежно оператором сервера f. root - servers. net компанією ISC, було рішення про застосування технології anycast. Хоча це рішення пройшло ретельну експертну перевірку фахівців, воно не було регламентовано ICANN або яким-небудь з його Рад. Згодом до ISC приєднався ряд інших операторів.
Прийнято вважати, що така незалежність і різнорідність операторів КС є основою технічної і політичної стабільності системи в цілому, виключаючи узурпацію управління будь-якої зі сторін.
Оператори КС утворюють неформальну групу, метою якої є координація спільних дій і обмін операційної інформацією і досвідом. Група проводить регулярні зустрічі 3 рази в рік, приурочені до наради IETF. Одним з результатів таких нарад є генерація секретного ключа для протоколу TSIG.
Члени групи є також членами Консультаційної Ради КСК ICANN (Root Server System Advisory Committee, RSSAC), в завдання якого входить вироблення рекомендацій з управління КСК і внесення різних змін в систему.
До недавнього часу були відсутні будь-які формальні відносини між операторами і ICANN / IANA. Ця ситуація змінилася з підписанням першої угоди між ICANN і оператором сервера f.root-serve r s.net компанією ISC. Дана угода не передбачає жодних фінансових розрахунків і лише визначає взаємні обов'язки сторін щодо управління КС. Відомо, що ряд операторів також обговорюють подібні угоди з ICANN.
Нижче наведено список і коротка характеристика поточних операторів СКС.
альтернативні СКС
Хоча можливість навмисного порушення роботи КС або модифікація вмісту кореневої зони будь-яким з операторів або ICANN / IANA малоймовірна, строго кажучи, в даний час не існує формальних процесів або міжнародних законодавчих актів, які могли б цьому перешкодити. Можна сказати, що нормальне функціонування СКС частково залежить від "доброї волі" учасників.
Необхідно зауважити, що подібні "неформальні" залежності, засновані на довірі, характерні для роботи системи DNS (і багато в чому мережі Інтернет) в цілому. В кінцевому підсумку, вибір, які КС використовувати, залишається за клієнтом. Ця інформація міститься в файлі конфігурації hints і може бути змінена.
Ця особливість укупі з незадоволеністю існуючою системою управління СКС на чолі з ICANN за участю уряду однієї країни - США, привела до створення так званих альтернативних СКС. Прикладами таких систем служать Public-Root, Open Root Server Network (ORSN) і UnifiedRoot. Хоча ці системи копіюють поточний стан кореневої зони, сама архітектура передбачає, що в певних умовах альтернативні СКС можуть надати альтернативний простір імен. Адміністратор клієнта DNS (зазвичай сервера DNS. Обслуговуючого корпоративних користувачів або клієнтів кабельної мережі) може вибрати альтернативну СКС змінивши відповідним чином файл hints.
Альтернативні СКС отримали критичну оцінку з боку IETF як відкривають потенційну можливість розколу єдиного Інтернету (див. RFC2826).
Технічний розвиток кореневого рівня DNS
Система кореневого рівня DNS дуже консервативна. Це і зрозуміло - будь-які зміни на цьому рівні зачіпають функціонування всієї глобальної системи доменних імен. Тим не менше, кілька важливих змін були впроваджені в СКС і кореневу зону протягом останніх років.
Ви напевно помітили, що кількість КС, а точніше імен КС, є "щасливим" числом 13. Це не виклик забобони, число 13 пов'язане з обмеженням на розмір повідомлення в 512 байт, встановленим стандартом DNS [RFC1035 4.2.1]. Хоча історично це обмеження було викликано обмеженням на пакети UDP не допускає фрагментації, воно продовжує існувати в протоколі DNS, незважаючи на появу нових мережевих протоколів, наприклад IPv6. Розширений стандарт DNS (EDNS0, RFC2671 2.3, 4.5) передбачає попередню угоду про розмір сполучення між клієнтом і сервером, проте ступінь поширення цього протоколу в сьогоднішніх системах DNS недостатня для зняття обмеження в 512 байт в найближчому майбутньому.
Всі 13 імен КС (a. Root - servers. Net - m. Root - servers. Net) уміщаються в відведені 512 байт, а в разі чотирнадцяти імен для значної частини запитів відповідь не зможе повністю поміститися в відведені 512 байт. Результатом може стати істотне зниження продуктивності системи, так як частина клієнтів змушена буде повторити запит, але тепер з використанням набагато більш "повільного" протоколу TCP.
Технологія anycast найбільш підходить для додатків, що використовують протокол UDP. працює без встановлення тривалого зв'язку. В іншому випадку, при будь-яких змінах в топології Інтернет (які відбуваються постійно), найкоротший шлях може привести клієнта до іншої мережі anycast. і зв'язок буде розірвана.
На перший погляд нескладна завдання, включення цієї інформації в кореневу зону було пов'язано з основною проблемою - перевищення розміру відповіді, і зокрема відповіді на первинний (priming) запит, все ті ж 512 байт!
Нарешті, третій можливої проблемою можуть бути проміжні системи, наприклад мережеві екрани (системи firewall), які можуть не пропускати DNS -пакети, розмір яких перевищує 512 байт або містить записи протоколу IPv 6.
Дослідження цих питань показало, що особливих причин для занепокоєння немає: більшість сучасних клієнтів підтримують розширення EDNS 0, що дозволяє передачу DNS-пакет більшого розміру. Навіть в іншому випадку, відповідь на первинний запит, який не перевищує 512 байт, містить достатньо інформації для початку пошуку. Тестування також не виявило проблем з новими записами у файлі hints.
Основною проблемою, як виявилося, могли бути проміжні системи, хоча тестування показало, що багато хто з них не накладають обмежень на розмір переданого пакета DNS. Єдиним способом вирішити цю проблему з'явилася широка просвітницька робота.
IDN розшифровується як Internationalised Domain Names. або міжнародні доменні імена, і означає можливість використання національних алфавітів при завданні імені домена або сервера. Технологія дуже приваблива, як з технічної, так і з політичної точки зору, оскільки для користувачів з нелатинськими алфавітами вона дозволяє практично повністю виключити необхідність використання латиниці при роботі в Інтернеті.
Однак базовий стандарт DNS допускає використання тільки 7-бітної кодування для символів, так звану таблицю ASCII. та й то з деякими обмеженнями для імен хостів. У той же час стандартною формою кодування символів національних письмових мов є Юнікод (Unicode).
Для трансляції символів Юнікоду в набір допустимих символів DNS використовується так званий Пюнікод (Punycode). Імена в Пюнікоде виглядають трохи дивно, наприклад, слово "випробування" буде представлено як xn - 80akhbyknj4f, але зате вони повністю відповідають стандарту DNS.
В даний час ведеться обговорення так званого процесу "Fast Track", який дозволить операторам існуючих національних доменів верхнього рівня зареєструвати ці домену на національних мовах.
З використанням IDN пов'язаний і ряд проблем. Наприклад, IDN відкриває ширші можливості для спуфинга (spoofing) імен, коли ім'я сервера зовні дуже схоже на інше ім'я, але насправді використовує інші символи, так звані гомографи. Дійсно, як відрізниш www. paypal. com від www. p а ypal. com в якому друга буква "а" набрана кирилицею. У порівнянні зі звичайними іменами, де 1 схоже на l. а 0 на O. IDN містить набагато більше гомографов. Вирішення цієї проблеми вимагає суворого контролю з боку реєстраторів доменів, обмеження числа підтримуваних мов в рамках домену та заборони змішування різних мов в доменному імені.
Основним недоліком DNS є слабка система захисту даних. Це означає, що в процесі передачі даних від сервера до клієнта, дані можуть бути модифіковані. Також можливе створення помилкових DNS серверів, що постачають модифіковані дані. DNSSEC. який є розширенням стандарту DNS. дозволяє вирішити цю проблему шляхом посвідчення даних цифровим підписом адміністратора домену, від якої отримані дані. У свою чергу, підпис адміністратора домену засвідчується адміністратором батьківської зони. Такий ланцюжок посвідчень триває аж до кореневої зони і DNS-клієнт може упевнитися, що саме ім'я і весь ланцюжок делегацій достовірні і не були модифіковані.
В даний час підтримка DNSSEC вельми розкидана по дереву DNS. що в більшості випадків не дозволяє побудувати так звані ланцюжка довіри. Відсутня підтримка DNSSEC і в кореневій зоні. Все це, по суті, зводить нанівець переваги DNSSEC.
Технічний директор RIPE NCC Андрій Робачевскій
Думки, представлені в статті, не обов'язково відображають офіційну позицію RIPE NCC