Лиценз: Creative Commons -
Признание-Споделяне на споделеното 2.5
Дезинформацията и измислиците, изречени от лицето Вени Марковски, които се тиражираха по вестници, интернет страници са толкова плоски, че няма нищо по-лесно от това да бъдат изобличени. Иска се просто бегло познаване на системата за имена в Интернет.
Разбира се, старанието на лицето Марковски (чиито мандат в ICANN изтича през есента), е да направи нещо за себе си (имиджово и финансово), както и за кандидатпрезидентската кампания на своя любим президент, наричан по народному "Гоце", "Седефчо" и т.н. Същият този "Гоце", който посреща като благородни джентълмени представители на компанията "Майкрософт", която е осъждана в Европа, вместо да им предложи да обядват сами в близката бира-скара.
Капманията с измислиците се подхвана от
Държавната агенция за информационни технологии и съобщения, в която за системата за имена знаят само от прочетено по вестниците. На тяхната интернет страница и по точно на адрес:
http://www.daits.government.bg/organization.php?pID=170четем следната брутална простотия:
"Годишен абонамент от $1 за домейн в зоната .org , поевтиняване на имената, завършващи на .bg и пускане на регионален сървър за по-бърз достъп до интернет, обявиха ръководители на световни ИТ компании".Всички залъгалки в нея няма да коментирам (трудно е да се излъже толкова пъти в едно изречение, без голям талант). Забележете
"пускане на регионален сървър за по-бърз достъп до интернет". Какъв ли ще е този вълшебен сървър, който ще направи по-бърз достъпа до Интернет? Може би това е сървър, който ще даде огромни като капацитет канали до световното интернет пространство (само дето нали някой трябва да ги докара до България, пък и защо ли ще минават през един сървър, нещо не е много ясно). След като обаче се види на чия страница е изнесена тази информация, човек си казва "
тези скоро се научиха да използват електронна поща, с
радиотелескопи правят интернет свързаност и междугалактични високоскоростни трасета, я да взема аз по-добре да питам някой по-запознат по темата "какво ще се прави всъщност у нас" (не и Вени, защото той е източник на дезинформация, а не на информация). След подобно запитване се оказва, че на компанията
VeriSign (забележете, не на неправителствена или нестопанска компания, а на компания, станала символа на комерсиализирането на системата за имена в Интернет), ще бъде дадена възможност да изгради у нас локален anycast нод на управляван от нея коренов сървър за имена в Интернет. Уместният въпрос е кой ще плати обслужването на този коренов сървър. Може би Вени от джоба си или
ДАИТС от държавната хазна. Всеки оператор на коренов сървър управлява anycast нодовете си отдалечено, следователно плаща на свои специалисти за работата и тези пари идват от този, който е поръчал нода. Всеки нод има хардуерно обезпечаване, което не е от типа "к'во да е" и спецификата се указва не от
конструкторите на зомби мрежи в ДАИТС, а от оператора на кореновия сървър (в нашия случай VeriSign). Този хардуер е доста скъп!
И така, след изсясняване стигаме до коренов сървър за имена в Интернет, а не до вълшебния сървър на Вени, който така ще ускори Интернет, че сайтът на ISOC.bg ще започне да се отваря малко по-бързо от сега.
Очевидна е лъжата с ускорението. По-долу ви предлагам лесносмилаем технически анализ на тази лъжа. Надявам се повече хора да прочетат това и да видят за каква наглост иде реч.
***
Какво е коренов ("root") сървър за имена? Това е сървър за имена, който съдържа зоната "." - най-висшестоящата зона на домейн в Интернет, която дава начало на другите домейни. Тя би трябвало да се управлява от IANA, но на практика всеки запис в нея се прави след взимане на съответното решение от страна на ICANN. След това зоната се подлага на разпространение от VeriSign. В тази зона са описани делегиранията на всички домейни от първо ниво (а има и директни делегирания от второ ниво, както и "залепени" ("glue") A ресурсни записи).
В Интернет има 13 коренови сървъра за имена. Повече информация за тях може да се намери на адрес:
http://www.root-servers.orgVeriSign оперират два от кореновите сървъри за имена: a.root-servers.net и j.root-servers.net. Забележете, че те нямат публични страници, каквато има например f.root-servers.net (публичната страница е на адрес
http://f.root-servers.org).
В таблицата с кореновите сървъри се вижда, че от двата коренови сървъра за имена, които VeriSign управлява, само j.root-servers.net е подложен на
йерархичен anycast. Следователно, ако те искат да изградят anycast нод у нас, те ще направят това за j.root-servers.net.
Да предположим, че това стане факт. Нека видим колко по-бързо обслужване на заявките ще се получи при наличието на този сървър за имена в родното интернет пространство.
Към момента:
Средното време на изпращане на пакет към j.root-servers.net и връщането му до клиентския процес, който го е изпратил, е средно 137.12 ms (+/- 1.19 ms изчислено на база 100 запитвания, описани като характер малко по-долу). Това време е изчислено на базата на ICMP запитване/ехо (известно като ping) и успоредното му преизчисляване чрез изпращане на UDP пакет и връщането на служебен отговор (ICMP port unreachable). Успоредно с това се подават UDP заявки за извличане на NS ресурсен запис от зоната ".". Средното време на отговор на DNS заявка по протокол UDP е 137.85 ms (+/- 1.46 ms на база 100 запитвания). Следователно отговорът на заявката е в рамките на около 1 милисекунда и времето за отговор се определя единствено и само от забавянето на пакетите при маршрутизацията.
Да си представим, че anycast нода на j.root-servers.net е в локалното българско интернет пространство и закъснението на пакетите вследствие на маршрутизацията е средно 2-3 милисекунди в софийския локален интернет. Да прибавим към това време още 1 милисекунда за обслужване на DNS заявката. Следователно имаме 3 милисекунди общо закъснение за изпълнение на заявката.
До тук всичко изглежда прекрасно. Но дали е така на практика?
Първо този нод ще бъде запитван средно в 1/13 от случаите, в които се иска да се получи информация от "." зоната. Това е заложено в т.нар. "round robin" схема на запитванията. Следователно за какво ускорение може да се говори, ако то е на лице само в 1/13 от случаите?
Второ, нека проследим механизма на използване на заявките. Да, именно на използване, защото той е решаващ относно процеса на ускорение на комуникациите, които са базирани на имена на хостове или ресурсни записи за услуги.
В системата за имена има йерархия от гледна точка на това кой е клиент и кой сървър, ако трябва да уточним понятията, това е йерархия определена от това кой е кеширащ сървър за имена и кой е клиент на кеширащия сървър. Тази йерархия пък е подчинена на топологичната йерархия, която се определя от схемата на извличане на отговор на заявката. В рамките на последната се случва така, че кеширащия сървър изпълнява зададена от клиента заявка и подава нейния отговор на клиента. Следователно в Интернет има групиране на клиенти около един кеширащ сървър за имена. Тази схема позволява да се разпредели натоварването не само върху кореновите сървъри за имена, но и върху тези, които лежат по-долу в йерархията (които са достоверни за домейните от по-ниско ниво, субдомейните им и т.н). Обикновено доставчиците на интернет свързаност и др. услуги, предоставят на клиените си кеш сървър. Колкото е по-голям един кеш сървър, толкова по-голямо натоварване се спестява на кореновите и другите сървъри за имена в Интернет.
Нека погледнем на картината от гледна точка на времето на живот на кешираните записи в памета на кеширащите сървъри за имена. Когато кеш сървърът извлече даден запис по заявка на свой клиент, той го записва в своята памет и го пази там докато изтече времето на живот на записа. Времето на живот на записа (TTL - Time To Live) е неотменим параметър на всеки запис. Той се задава в зоната на домейн, в която записа е описан. След като записът бъде кеширан в някой кеш сървър, той живее там TTL секунди. След това се изтрива от кеша. През времето, през което записът е жив, ако клиент заяви кеширания запис, не се прави повторно извличане на записа, а на клиента се подава този, който е наличен в кеша. Оттук излиза, че колкото по-голяма е стойността на параметъра TTL за записа, толкова по-рядко се налага да се пита за този запис.
Къде в цялата йерархия на извличане на заявката помагат кореновите сървъри? Те помагат при извличането на ресурсни записи за сървърите за имена за домейните, които са делегирани в "." зоната (домейните от първо ниво и делегираните в "." зоната домейни от по-ниско ниво). Кореновите сървъри съобщават кои са достоверните сървъри за имена за домейните, които са делегирани в "." зоната. И нищо повече. След като съобщят това на запитващия ги кеширащ сървър за имена, той довършва останалата част на йерархията сам.
Работата е там, че записите за сървърите за имена за даден домейн от първо ниво или друг такъв, делегиран в "." зоната имат голяма стойност на времето си на живот. Следователно, те "живеят" достатъчно дълго в кеша на кеширащия сървър, за да се налагат чести запитвания до кореновите сървъри за имена. Ето времената на живот за сървърите за имена на някои домейни от първо ниво:
com --> 172800 секунди (48 часа - 2 дни)
net --> 172800 секунди (48 часа - 2 дни)
org --> 86400 секунди (24 часа - 1 ден)
Следователно един кеш сървър, който е кеширал NS ресурсните записи за TLD COM, няма два дни да запита коренов сървър отново за тях. На практика всеки кеш сървър кешира NS записите за почти всички TLD до час след започване на функционирането си.
Следователно ускорението, което може да се получи от разполагането на локален коренов сървър за имена, няма как да се почувства осезаемо при схемата на работа с кеширащи сървъри за имена, която е застъпена по правило в Интернет.
Ето това обяснява защо Вени най-нагло заблуждава хората. Защото той знае, че повечето ползватели на интернет услуги у нас са технически инвалиди и разчита на първосигналната им реакция при обявяване на "по бърза връзка до Интернет". Представете си какъв технически потенциал имат в ДАИТС, щом те му припяват по този начин. Трагедия!
Истината е следната. Anycast нодовете се строят из Интернет не за да ускорят заявките. Те се стоят за да разпределят натоварването върху кореновите сървъри и системата за имена като цяло, върху много точки на обслужване на заявките. Anycast нодовете имат за цел да предпазват системата за имена от дистрибутивни атаки "отказ на услуга" (DDoS). На практика скоростта на обслужване на DNS заявките се определя преди всичко от скоростта на обслужване за последния в йерархията домейн, записи от който се извличат, а не от по-висшестоящите домейни. Например, за бързината на извличане на записи от зоната на домейна redhat.com от решаващо значение са отговорните за тази зона сървъри за имена, а не тези за com и ".", защото последните два почти сигурно за налични в кеширащия сървър, който се използва.