В корен DNS

Принципи на работа резолюция име система

Зоната на корен, който съдържа информация за всички поддомейни: мрежа. МС. орг. ЖП. су. и т.н. По-точно, информацията на сървърите, обслужващи тези домейни.

Домейн узрели. съдържащ информация за всички поддомейни, както и имена на сървъри са регистрирани директно в тази област, като WWW. узрели. нето.

Фигура 1 процес на транслация на имена в DNS

Тази архитектура позволява на DNS за разпределение на натоварването и отговорността за експлоатацията на системата между администраторите на отделните области. Техните задължения включват осигуряване нормалното протичане, когато в отговор на искания до зоната, уникалната подкрепа на имената в рамките на зоната и уведомлението за родителска зона администратор относно промени в сървърите за зоната.

Това йерархично разпределени DNS архитектура се осигурява дълголетие на системата и нейното еволюционно развитие за над една четвърт от един век.

Но има и в системата на DNS е една функция, която го отличава от много други системи в Интернет, които са децентрализирани. Това е същата точка, DNS корена на дървото. където всичко започва пресни запитвания. За него ще говорим повече.

DNS ниво корен

Root сървъри (CS) DNS е критичен компонент на системата, тъй като те осигуряват достъп до зоната на корен DNS. Root зона съдържа информация за всички домейни от първо ниво: Национални домейни (например .ru), домейни с общо предназначение (например .com) и спонсорирани домейни (например .museum). Тази информация показва на клиента какво DNS сървърите за изпращане на последващо искане за разрешение да продължи пълното домейн име. С други думи, всеки "свеж" (т.е., не се съхраняват в кеша на клиент) заявка започва с позоваване на корен сървър.

Днешната система корен сървър и координирането на работата си

Нека разгледаме членовете на СКС. За това ние се обръщаме към процеса на извършване на промени в съдържанието на зоната на корените, показани на фигура 2.

Процесът на Фигура 2 промени в зоната на корените

Искането за промяна идва от домейна на администратора най-високо ниво (ccTLD, домейни от първо ниво, и т.н.) и е служил IANA. Типичен пример за такова искане е да се промени състава на сървъри за домейн.

след това промени се изпращат на организацията, отговорна за действителното редактирането и публикуването на DNS зона. В момента Тази роля се изпълнява от компанията VeriSign. Между другото, една и съща фирма е оператор на 2 основни сървъри - a.root-servers.net и j.root-servers.net.

Площ първоначално публикувана на скритата главен сървър и след това разпространява във всички копия, използващи TSIG протокол за защита на данните от промяна по време на прехвърлянето.

оператори COP

оператори COP са различни организации, които са получили право да управлява сървърите в относително далечното минало, когато тези въпроси се разглеждат по-малко формално. Сред операторите са университети, организацията на Министерството на отбраната, сдружение с нестопанска цел в САЩ. Операторите са финансово и юридически независими от корпорацията ICANN, при която действията на IANA. При вземане на оперативни решения се ръководят от операторите и техническа осъществимост съществуващите стандарти (например, RFC2870), основно от запазване на статуквото. Най-големият решението на вида взети от независим е сървъра оператор. кореноплодни - сървъри. Нетната компания ISC, беше решението за използване anycast технология. Въпреки, че това решение е преминал строгите експерти за партньорска проверка, че не е регулиран от ICANN или някоя от неговите съвети. Впоследствие ISC присъединиха и редица други оператори.

Смята се, че тази независимост и разнообразие на операторите COP е в основата на техническата и политическата стабилност на системата като цяло, с изключение на узурпирането на управлението на всяка от страните.

оператори COP формират неформална група, чиято цел е да координира кооперативно действие на информацията за работа и обмен и опит. Групата провежда редовни заседания 3 пъти годишно, за да отбележат IETF събрание. Един от резултатите от тези срещи е да се генерира таен ключ за протокола TSIG.

Членовете на групата са и членове на Консултативния съвет на ICANN KSK (сървър Консултативен комитет коренова система, RSSAC), който е натоварен със задачата да направи препоръки за управление на CSC и въвеждането на различни промени в системата.

Доскоро не е имало официална връзка между операторите и ICANN / IANA. Тази ситуация се променя с подписването на първото споразумение между ICANN и оператора на сървъра f.root обслужен R s.net от ISC. Това споразумение не предвижда никакви финансови селища, а само определя взаимните задължения на страните по отношение на управлението на CS. Известно е, че много оператори, също обсъждаме подобни споразумения с ICANN.

По-долу е даден списък и кратко описание на настоящите оператори СКС.

алтернатива SCS

Въпреки че възможността за умишлено нарушение на Конференцията на страните или на промяната на съдържанието на зоната на корените в някое от обстоятелствата или ICANN / IANA малко вероятно, по-точно казано, в момента не съществува формален процес или международни закони, които биха могли да възпрепятстват това. Можем да кажем, че нормалното функциониране на SCS зависи отчасти от "добрата воля" на участниците.

Трябва да се отбележи, че такова "неформална" зависимост, основани на доверие, се характеризира за функциониране на системата за DNS (и в много отношения интернет) като цяло. В крайна сметка, изборът на които да се използват на Конференцията на страните остава за клиента. Тази информация се съдържа в конфигурационния файл и съвети могат да бъдат променяни.

Тази функция, заедно с недоволство от съществуващата система за управление на кабела начело с ICANN с участието на правителството на една държава - Съединените щати, е довело до създаването на така наречената алтернативна SCS. Примери за такива системи са за публично-корен, Open Network Root сървър (ORSN) и UnifiedRoot. Въпреки че тези системи се копират текущото състояние на зоната на корените, самата архитектура предвижда, че при определени обстоятелства алтернативните SCS могат да осигурят алтернативен пространство от имена. DNS клиент администратор (обикновено DNS сървъра. Обслужва корпоративни потребители или клиенти на кабелната мрежа) може да избере алтернативно SCS се променя съответно загатва файл.

Алтернативен SCS получи критична оценка от IETF като отваряне на потенциала за част от единен интернет (вж. RFC2826).

Техническото развитие на нивото на DNS корен

DNS система корен ниво е много консервативна. Това е разбираемо - всяка промяна на това ниво се отрази на функционирането на цялата глобална система на име на домейн. Въпреки това, няколко важни промени са въведени в SCS и зоната на корените през последните години.

Може би сте забелязали, че броят на COP и COP точното име е "щастлив" номер 13. Това не е предизвикателство за суеверие, броят 13 се дължи на ограничаването на размера на съобщение на 512 байта, се превръща в образец DNS [RFC1035 4.2.1]. Въпреки, че в исторически план това ограничение се дължи на ограничение на UDP пакети се избегне раздробяването, тя продължава да съществува в протокола за DNS, въпреки появата на нови мрежови протоколи, като IPv6. Разширено стандартна DNS (EDNS0, RFC2671 2.3, 4.5) осигурява предварително споразумение за размера на комуникация между клиента и сървъра, но степента на този протокол в текущия DNS системата не е достатъчно, за да се премахне ограничението за 512 байта в близко бъдеще.

Всички имена на COP 13 (корен -. Servers нето -. М корен - .. сървъри нето) се вписват в запазената байт 512, а в случай на четиринадесет име за значителна част искания отговор не може напълно да се поберат на отпуснатите 512 байта. Резултатът може да бъде значително намаляване на производителността на системата, като част от клиентът ще трябва да се повтаря искането, но сега с много повече "бавен" TCP протокол.

anycast технология е най-подходящ за приложения, използващи UDP протокол. експлоатира без непрекъсната комуникация. В противен случай, ако има някакви промени в топологията на интернет (които са константа), най-краткия път може да доведе до друг клиент anycast мрежа. и връзката ще бъде прекъсната.

На пръв поглед проста задача, включването на тази информация в зоната на корените са свързани със сериозен проблем - надвишава размера на отговор, и по-специално в отговор на първичния (грундиране) искането за същите 512 байта!

Накрая, третата възможно проблемът може да междинни системи, като например защитни стени (системи защитна стена), които не могат да преминат DNS -packet чийто размер надвишава 512 байта или записи включва IPV 6 протокол.

Изучаването на тези въпроси, е показал, че има конкретна причина за безпокойство: повечето от днешните клиенти подкрепи EDNS разширяване 0, което позволява предаването на DNS -Package по-големи. Дори и по друг начин, основният отговор на искане, което не надвишава 512 байта, съдържа достатъчно информация, за да започнете търсенето. Тестване също не показа никакви проблеми с новите записи във файла с намеци.

Основният проблем, както се оказва, може да бъде междинни системи, но изследване показа, че много от тях не налагат ограничения върху размера на предава DNS пакета. Единственият начин да се реши този проблем е най-широка образователна работа.

IDN щандове за интернационализирането на домейн имената. или международни имена на домейни, и означава, че можете да използвате международни герои, когато зададете име на домейн или сървър. Технологията е много привлекателен, както от техническа, и от политическа гледна точка, както за потребители с нелатински азбуки Тя позволява на практика да премахне необходимостта от използването на латинската азбука, когато използвате интернет.

Въпреки това, DNS основен стандарт позволява само на 7-битово кодиране за героите, така наречената ASCII таблица. и след това само с определени ограничения за имената на хостовете. В същото време, стандартна форма на кодиране символ на националните писмен език е Unicode (Unicode).

За превод на Unicode символи в серия от DNS валидни знаци използва т.нар Pyunikod (Punycode). Имената в Pyunikode изглеждат малко странни, например, думата "тест", ще бъдат представени като Xn - 80akhbyknj4f, но те напълно отговарят на стандартите за DNS.

В момента в процес на обсъждане на така наречената процеса на "Fast Track", която ще позволи на операторите на съществуващ домейн от първо ниво, за да се регистрират тези национални домейни на националните езици.

С използването на IDN е свързано с редица проблеми. Например, IDN отваря повече възможности за спуфинг (фишинг) имена, когато името на сървъра е външно много прилича на друго име, но в действителност използва другите герои, така наречените homography. Наистина, как да се прави разлика WWW. PayPal. ком от WWW. р и ypal. COM, в който втората буква "а" е написан на кирилица. В сравнение с конвенционалните имена, където 1 е подобен на л. и 0 на О. IDN съдържа много повече homography. Решаването на този проблем изисква стриктно наблюдение от регистраторите на домейни, ограничаване на броя на поддържаните езици в рамките на домейна, както и забраната за смесване на различни езици в името на домейна.

Основният недостатък е слаба системата за закрила на DNS данни. Това означава, че данните могат да се променят в процеса на прехвърляне на данни от сървъра към клиента. Възможно е също така да се създаде фалшиви DNS сървъри, доставящи променените данни. DNSSEC. който е разширение на стандарта за DNS. решава този проблем, като цифрово подписан с администратора на домейна данни на сертификата, от която са получени данните. На свой ред, подпис на администратора на домейна е сертифициран от администратора на родителска зона. Такава верига от сертификати продължава до зоната на корените и DNS -client да се уверите, че самото име, и по цялата верига на делегации автентични и не са били променени.

В момента DNSSEC подкрепа е много пръснати в DNS дървото. че в повечето случаи не позволява да се изгради така наречената верига на доверие. Няма поддръжка DNSSEC в зоната на корените. Всичко това е в действителност, отрича ползите от DNSSEC.

Технически директор на RIPE NCC Андрю Robachevsky

Мненията, изразени в статията, не отразяват непременно официалната позиция на RIPE NCC