Конструкция на AS112 в мрежата на Софийския Университет "Св. Климент Охридски"

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Цел на автономна система AS112

Адресен план за използване на адресното пространство на AS112

Физическа локация на решението в мрежата на СУ "Св. Климент Охридски" (AS5421)

Дефиниране и конфигуриране на виртуален мрежови интерфейс dummy0

Динамична маршрутизация на адресното пространство на AS112

Създаване на алтернативни демони на named в BIND9

Програмни настройки на алтернативния демон named-as112 за нуждите на AS112

Обслужвани зони на домейни от демона named-as112

Конфигурационен файл named.conf на демона named-as112

Особености на използването на rndc

Неприложимост на TSIG в рамките на проекта AS112

Предишни версии на публикацията

1. Цел на автономна система AS112

В рамките на IP адресното пространство версия 4 (IPv4), има адресни сегменти, които са отделени за частно (локално) използване. Това ще рече, че те не се маршрутизират глобално, а само локално, за локални (частни) цели. RFC3330 (първото указване е в RFC1918, а RFC3330 е по-обобщаващ документ, който прави "карта" на адресните сегменти за специално използване в рамките на IPv4 адресното пространство), указва кои от адресните пространства в рамките на IPv4 могат да бъдат използвани за частни цели. Такива са (представянето по-долу е в CIDR):

Уместен е въпросът "а след като всеки може да използва тези адресни пространства или част от тях, кой тогава извършва записите в съответната in-addr.arpa зона на домейна, отговарящ за съответното адресно пространство". Отговорът на този въпрос е "този, който оперира съответното адресно пространство за частни цели". Съгласно този отговор, всеки оператор, който използва адресен сегмент за частни цели (т.е. в споменатите по-горе група от адресни сегменти), трябва да изгради сървър за имена, който да се използва от хостовете, които достъпват адресно пространство за частни цели, за намиране на стойността на PTR ресурсните записи за всеки хост от частната мрежа. В най-простия случай това са хостовете от мрежата за частно ползване. В по-сложни мрежови топологии е възможна ограничена видимост между публични и частни адресни пространства и в този случай е необходимо не само хостовете от адресното пространство за частно ползване, но и хостовете от публичните адресни пространства да знаят кой е сървъра за имена, отговорен за съответната in-addr.arpa зона, за да могат да намират съответните стойности на PTR ресурсните записи за даден хост от адресното пространство за частно ползване. Доколкото всеки оператор на частна мрежа може да дефинира своя in-addr.arpa зона на домейн за използваното от него адресно пространство, то всеки такъв оператор може да изгради своя in-addr.arpa зона на домейн върху негов сървър за имена.

Горното може да се илюстрира с пример. Нека даден оператор използва адресно пространство 192.168.100.0/24. Той трябва да изгради зоната на домейна 100.168.192.in-addr.arpa върху свой сървър за имена и да направи съответните PTR ресурсни записи за хостовете в 192.168.100.0/24. Освен това трябва да направи така, че всички хостове от 192.168.100.0/24 да използват такъв сървър за имена, който да обслужва заявките именно към локалната за хостовете зона на домейн 100.168.192.in-addr.arpa, а не да ги насочва по обичайния за заявките в системата за имена в Интернет път, който да минава през кореновите сървъри за имена и от там през съответната йерархия.

Какво се случва обаче, ако даден хост комуникира с хостове от мрежа за частно ползване, но сървърите за имена, които използва, не извършват локално обслужване на заявки за извличане на стойността на PTR записа в съответния in-addr.arpa локален домейн, отговорен за мрежата за частно ползване? Тогава заявките следват йерархичната схема за имена и "излизат" в Интернет. Ако заявката попадне в йерархията, тя най-накрая ще стигне до сървърите за имена на IANA, които в глобален мащаб са отговорни за обслужване на in-addr.arpa домайните за адресните пространства за частно ползване. Тези сървъри за имена са:

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

2. Адресен план за използване на адресното пространство на AS112

Както бе споменато по-горе, адресното пространство, алокирано към AS112 има само една единствена сегментна адресна алокация (RPSL inetnum - 192.175.48.0-192.175.48.255. Именно този маршрутен обект е обявен в в режим на anycast. От него за нуждите на сървърите за имена за in-addr.arpa домейните на мрежовите адресни пространства за частно ползване, се използват следните три IP адреса:

Останалите адреси от сегмента нямат целево назначение. Основателно възниква въпроса "защо за нуждите на anycast е заделено адресно пространство с дължината на мрежовата маска 24 бита, след като в него се използват реално само три IP адреса"? Причината е в глобалната система за маршрутизация в Интернет. Транзитните доставчици осъществяват транзит (съгласно информацията в динамичните протоколи за маршрутизация), само на BGP префикси за мрежови сегменти, които са декларирани като маршрутни обекти в бази от данни на IP регистрите (виж http://www.radb.net за повече подробности) и са с дължина на мрежовата маска по-малка или равна на 24 бита.

3. Физическа локация на решението в мрежата на СУ "Св. Климент Охридски" (AS5421)

Проектът "AS112 в мрежата на Софийския Университет "Св. Климент Охридски" използва два физически отделни DNS процеса, локирани върху два различни сървъра. Първият процес се изпълнява върху сървъра ns.uni-sofia.bg (unicast IP адрес 62.44.96.1), а втория върху сървъра ady.uni-sofia.bg (unicast IP адрес 62.44.96.7). Двата сървъра имат идентична конфигурация на DNS сървърските процеси (ще бъде дискутирана в подробности по-долу). Подобно локиране на процесите върху два сървъра определя решението като "двувъзлово" ("двунодово").

4. Дефиниране и конфигуриране на виртуален мрежови интерфейс dummyN

Използваемите IP адреси от AS112 се конфигурират върху мрежови интерфейс dummyN (N=0..255). Този интерфейс не е обвързан с никое физическо мрежово устройство, а е специален псевдо мрежови интерфейс за Linux ядрата от версия 2.6. За изрграждането на интерфейси dummyN (N=0..255), се използва модула dummy. Стандартно той е част от модулната колекция в дистрибутивния за Red Hat Enterprise Linux пакет kernel.

В Red Hat Enterprise Linux конфигурирането на интерфейсите става чрез конфигурационни файлове, които се намират в директория /etc/sysconfig/network-scripts/. За всеки интерфейс, бил той физически или псевдо, има поне един конфигурационен файл. Изчерпателна информация за структурата на конфигурационните файлове, възможните декларации и синтаксиса на описанието в тях, може да се намери във документалния файл /usr/share/doc/initscripts-*/sysconfig.txt, част от пакета initscripts. По принцип, за изграждането на виртуалните мрежови интерфейси се използва модула dummy в състава на колекцията модули в ядра 2.6. Доколкото върху един мрежови интерфейс ще трябва да се разположат и трите IP адреса, то е ясно, че ще от гледна точка на задаването им, ще има една дефиниция за виртуален интерфейс (споменатият вече dummy0) и две дефиниции за псевдоними към интерфейса (съответно dummy0:0 и dymmy0:1). За реализирането на проекта е използвана дистрибуцията Red Hat Enterprise Linux. Модулът dummy стандартно идва с дистрибутивния пакет kernel. Мястото на конфигурацията за виртуалния интерфейс в тази дистрибуция е във файла /etc/sysconfig/network-scripts/ifcfg-dummy0:

Псевдонимът dummy0:0 на виртуалния мрежови интерфейс dummy0 е дефиниран във файла ifcfg-dummy0:0, който също, както и съответния конфигурационен файл за интерфейса dummy0, се намира в директория /etc/sysconfig/network-scripts:

Аналогично е положението и при дефинирането и управлението на псевдонима dummy0:1:

Точно на това място трябва да бъде обсъден един дискусионен момент, а именно защо е нужно да се използва виртуален интерфейс вместо да се дефинират всички нужни адреси върху псевдоними на някой от реалните физически интерфейси на машината (например eth0). Трябва да се каже, че чрез използването на виртуален мрежови интерфейс и поставяне на псевдонимите върху него, се избягва излагането на сегмента 192.175.48.0/24 директно в етернет средата. За да се поясни значението на това изолиране на сегмента от етернет средата, трябва да се каже, че подобна изолация не позволява arp запитвания към адрес от сегмента и така се предотвратява евентуална колизия на IP адреси, която е винаги вероятна в една етернет среда. Също така, по този начин в един етернет сегмент може да има два или повече възела на AS112, без те да си пречат - нека си представим какво би станало, ако двата възела са в един мрежов сегмент и адресите от 192.175.48.0/24 са дефинирани върху псевдоними на мрежовите интерфейси, с които машините на възлите членуват в един и същи етернет сегмент.

5. Динамична маршрутизация на адресното пространство на AS112

Двата възела на AS112 в мрежата на Софийския Университет "Св. Климент Охридски" излъчват префикса 192.175.48.0/24 към Интернет, чрез транзит през AS5421. За целта всеки един от възлите на AS112 осъществява с граничен маршрутизатор на AS5421 (в случая с този с BGP ID 62.44.127.11) BGP сесия.

Съответните BGP конфигурационни файлове /etc/quagga/bgpd.conf за двата възела изглеждат по следния начин:

Ето и скица, показваща топологията на свързване между граничните маршрутизатори на AS112 и AS5421:

6. Създаване на алтернативни демони на named в BIND9

Особеност на реализацията на AS112 в мрежата на Софийския Университет "Св. Климент Охридски" е, че върху сървърите, които я реализират, са реализирани и достоверни сървъри за имена за домейна uni-sofia.bg и поддомейните му, и кеширащи сървъри за имена с публичен достъп (използващи unicast IP адреси 62.44.96.1 и 62.44.96.7). Основателен е въпроса дали е коректно да се използват тези сървъри за имена и за обслужване на заявки за AS112. Отговорът е, че не е. Този отговор има два аспекта - обществен и технически.

Общественият аспект на отговора указва на това, че не може един сървър за имена, работещ с идеална цел да обслужва и зони на домейни, които не са свързани по някакъв начин с AS112 (примерно сървърите за имена за целите на AS112 в мрежата на Софийския Университет "Св. Климент Охридски" да обслужват и зоните на домейна uni-sofia.bg и поддомейните му).

Техническият аспект включва в себе си осъзнаване на това, че натоварването на една услуга зависи не само от натоварването на машината, на която тя се извършва, а и от натоварването на самия демон, който предоставя тази услуга. За това при реализацията на AS112 в мрежата на Софийския Университет "Св. Климент Охридски" е използван отделен демон named за нуждите на AS112. Той отговаря само за зоните на домейните непосредствено свързани с AS112 и не подава никаква информация за каквито и да са други зони на домейни.

Ходът на разсъжденията, който води до извода, че за DNS услугата в рамките на AS112 трябва да се използва самостоятелен демон named, ако върху системата има друг демон, който извършва обслужване на рекурсивни заявки от страна на клиенти, е следния. Ако схемата на работа на named се разгледа в най-опростен (но достатъчно ясен) вид, то прави впечатление, че в нея има два фактора, които влияят на скоростта на обслужване на заявки. Първият е състоянието на своеобразния "буфер" или опашка, в която постъпват паралелните запитвания преди да се обработят от съответните процедури с цел получаване на отговор. Възможно е да се получи така, че дори при ненатоварена система, демонът named да започне да обслужва бавно заявките поради това, че е "залят" с твърде много такива и процесът на подреждането им изисква време за изпълнение на съответния алгоритъм, пренареждане в страниците на паметта, заети от демона и т.н. Вторият фактор е съвкупоността от административно задаваеми параметри, който да ограничават едновременния брой обработваеми заявки с цел предпазване от претоварване на демона named. Тогава може да се стигне до там, че при огромен брой рекурсивни заявки, да не се обслужват някои от заявките за DNS услугата, която се намира в рамките на проекта AS112 (т.е. част от заявките да бъдат отхвърляни) или обратното - заради обслужване на тези за AS112, да се отвърлят тези за останалите домейни. Нека се върнем на конкретната реализация на AS112 в мрежата на Софийския Университет "Св. Климент Охридски". Там имаме случай, при който в системата има вече работещ демон named, който обслужва както рекурсивните заявки, така и заявки за извличане на записи от зоната на домейна uni-sofia.bg и неговите поддомейни. Би било особенo лоша идея да се позволи конкуренция между заявките за рекурси, заявките за извличане на ресурсни записи от зоната на домейна uni-sofia.bg и неговите поддомейни, и тези към зоните на домейни, чиято обслужваща DNS услуга се намира в AS112. Именно за това, в системата има стартиран втори демон named, който служи изцяло на целите на проекта AS112. Не на последно място трябва да се спомене, че при разделяне на демоните по задачи, може да се използва наличния инструментариум за приоритизация на процесите по заемано натоварване на процесора, заета памет и т.н. Това няма как да се постигне само с един работен демон.

Към настоящия момент върху двата възела на AS112 в мрежата на СУ има инсталиран пакета bind, който е в актуална версия в рамките на пакетната колекция на дистрибуцията Red Hat Enterprise Linux. В рамките на тази дистрибуция управлението на зареждането, спирането и състоянието на услугите се извършва чрез скрипт система по модела "System V". Пренесено към структурата на дистрибуцията, това значи, че демона named се стартира чрез използването на init скрипт, който в конкретния случай е файла /etc/rc.d/init.d/named. Този скрипт обаче управлява само един демон named. Задачата е да се построи нов скрипт или серия от скриптове, който да управляват демона, който ще осъществява DNS услугата по проекта AS112 успоредно с управлението на други демони named. Решението е да се клонира скрипта /etc/rc.d/init.d/named в отделен скрипт за всяка отделна DNS услуга. По пътя на тази логика са създадени два сктипта:

Скриптът /etc/rc.d/init.d/named-as5421 се използва за обслужване на заявките, свързани с домейните на Софийския Университет "Св. Климент Охридски", докато /etc/rc.d/init.d/named-as112 се използва за обслужване на DNS заявките към проекта AS112.

Всеки един от тези скриптове чете нужните за работата на named променливи (в случая чете променливата указваща работната директория) от специално приготвен за целта файл, който се намира в директория /etc/sysconfig. Скриптът /etc/rc.d/init.d/named-as112 чете променливите от файла /etc/sysconfig/named-as112, докато /etc/rc.d/init.d/named-as5421 ги чете от /etc/sysconfig/named-as5421. Директориите, които са указани като променливи в тези файлове, имат структурата, която named използва за да се заключи в тях след стартирането си. Вътрешнодиректорийната структура следва схемата, която е налична в пакета bind-chroot в дистрибуцията Red Hat Enterprise Linux.

За нуждите на двата демона, са създадени два непривилигеровани потребителя. Ето тяхната дефиниция във файла /etc/passwd:

Групата с идентификатор 602 също се нарича named-as112 и има за единствен член потребителя named-as112 (за когото тя е главна група). Задаването на групата става без указване на парола за членство в нея, така че само root може да прибавя или премахва нови членове.

Тук е мястото за малка дискусия. На пръв поглед може да се стори нерационално решението за дефиниране на нов потребител и група за демон, който и без това има назначен непривилигерован потребител за собственик на процесите на демона. Обикновено във Fedora Core това е потребителят named. Той бива дефиниран в система от постинсталационния скрипт на пакета named. Нужно е да се отбележи, че при клонирането на демоните (виж по-долу), се налага да има повече от един демон named в системата. От гледната точка на добрата администрация на системата, е добре процесите на двата демона да са собственост на различни потребители за да няма възможност процес на единия демон да засяга процеси на другия, което щеше да е възможно, ако и двата демона стартират процесите си с правата на един и същ непривилигерован потребител.

За да бъдат решени проблемите около имената на процесите на демона named, стартиращи се от описаните по-горе инициращи скриптове, е направено клониране на изпълнимия файла на демона, чрез симетрични връзки към изпълнимия файл /usr/sbin/named имащи различни имена:

Нужно е да се отбележи, че при този начин, безпроблемно се решава проблема с актуализиране на версията на пакета bind от пакетната колекция на дистрибуцията. Т.е. при смяната на бинарния файл /usr/sbin/named с нов, автоматично се актуализират клонираните демони named-as5421 и named-as112 доколкото те се стартират от изпълнимите символни връзки към него.

7. Програмни настройки на алтернативния демон named-as112 за нуждите на AS112

Конфигурирането на BIND9 за нуждите на проекта AS112 в мрежата на Софийския Университет "Св. Климент Охридски", следва от описаната по-горе схема на оперативни настройки на демона named. Конфигурационният файл named.conf се намира в поддиректория etc/ на директорията, която е зададена във файла с променливите /etc/sysconfig/named-as112. В конкретния случай това е /home/chroots/named-as112. Съдържанието на директорията /home/chroots/named-as112 е слендото:

Доколкото демонът named работи в chroot схема, то показаната по-горе директорийна структура, донякъде наподобява реално съществуваща такава в директорията "/". Ето и детайлно обяснение за използването на всяка една директория и файл в нея.

Поддиректория dev/ служи за аналог на директория /dev от "/" файловата система. В нея са поставени необходимите за работата на named сокети и символни устройства. Създаването на тази директория и установяване на правата върху нея следва последоватеността:

Това е сокет, отворен от демона syslogd. "Отварянето" на този сокет в тази директория става чрез указването на пълния път до сокета във файла /etc/sysconfig/syslog. При указването в този файла се използва опция "-a":

След указването на пълния път, е нужно да се рестартира демона syslogd:

и сокета log ще се "отвори" в директория /home/chroots/named-as112/dev.

Това е символно устройство, аналог на /dev/null и има същото предназначение. За да бъде напрвено това устройство се изпълняват следните команди:

Това символно устройство се използва за генератор на случайни числа, аналог на /dev/random. Създава се чрез команден ред подобен на следния:

Това символно устройство е аналог на /dev/urandom. Създава се по следния начин:

Символното устройство dev/zero е аналог на /dev/zero и може да бъде изградено така:

Тази директория е аналог на /etc. Създаването й може да се опише така:

Това е копие на файла /etc/localtime, който съдържа дефинициите на часовите зони. При наличие на актуализация (update) на пакета tzdata, след привършване на процеса на актуализиране, е наложително да се извърши копиране на актуалната версия на /etc/localtime в /home/chroots/named-as112/etc.

В този файл се съдържа конфигурацията на демона named-as112. Тя ще бъде дискутирана по-долу. Установяване на правата върху този файл следва схемата:

Необходимо е да се обоснове това отдаване на права за четене на файла named.conf от страна на всеки потребител на системата, за да бъдат пресечени спекулативни дискусии по темата в самия им зародиш. Този файл не съдържа поверителна информация, която би могла да бъде използвана по някакъв начин за смущаване на работата на демона. Единствените сензитивни данни са тези за ключа за управление на демона от страна на инструмента rndc. За да не се съдържа стойността на ключа във файла named.conf, той се указва за влагане в паметта при прочит от демона named-as112 чрез дефиниция "include /path/to/rndc.key_file". Правата върху файла с ключа са такива, че не позволяват прочита на съдържанието му от всеки, а само от root и потребителя, с чиито права работи демона named-as112 (както бе указано по-горе, това е потребителя named-as112). Така съдържанието на файла named.conf може да е публична информация, без това да застрашава работата на демона.

Това е ключът, който инструмента rndc използва в рамките на TSIG схема за да подписва заявките към демона. Ключът трябва да може да бъде читаем само от страна на непривилигерования потребител, който е собственик на процесите на демона named-as112. Правата върху този файл се дефинират чрез следната схема:

Един интересен въпрос е защо непривилигерования потребител, който е собственик на процесите на демона named-as112 може само да чете файла с ключа, но не може да пише (да пише там може единствено потребителя root). Това се прави с цел предпазване на ключа от промяна, ако демона named-as112 бъде "пробит" без да може атакуващия да придобие права на root (това може да бъде направено с цел съботаж или трайно придобиване на достъп след актуализиране на "пробиваемата" версия на пакета bind). Така при актуализация на пакета bind и рестартиране на демона named-as112, ще бъде прочетен актуалния ключ (променения от атакуващия може да остане само в паметта и при презареждане да бъде изтрит).

Тази директория е аналог на директорията /var. В нея се съдържат журналните файлове, водени от демона named-as112, а също така копия на зоните на нужните за функционирането на DNS услугата на AS112 домейни. Създаването на var/ следва следната схема:

Създаването на поддиректорийната структура се извършва по следния примерен начин:

В тази директория демонът named-as112 описва събитията относно обслужването на заявки, трансфера на зони и др. събития. Характерът и наименованието на журнала се указва в конфигурационния файл named.conf. Права за писане в тази директория имат root и потребителят, с чиито права се изпълняват процесите на демона named-as112. Права за четене на информация от тази директория имат само и единствено тези потребители, които могат да пишат в нея и тези от прилежащата им главна група. Свободното четене от тази директория е забранено по чисто политически причини. Софийския Университет "Св. Климент Охридски" не иска да изнася по никакъв начин публично данни за това кои публични IP адресни пространства излъчват заявки към AS112. Това се прави с цел да се избегнат спекулативни тълкувания на тези данни на фона на твърде сложните и доста честно некоретктни отношения между доставчиците на интернет свързаност, и да се затрудни събирането на информация за това кой какви частни адресни сегменти използва. Българското интернет пространство, от гледна точка на манталитета на участниците в него, все още не е узряло за свободното предоставяне на подобна информация.

Поддиректорията var/named/master съдържа файлове с описанията на "master" зоните на домейни, които локално се обслужват от демона named-as112. Самата директория, както и файловете в нея не са писаеми от страна на никой друг, освен root. Доколкото това са "master" зони и не са в режим на динамично обновяване на ресурсните запси в тях, то не е наложително непривилигерования потребител, с чиито права се стартират процесите на демона named-as112, да има права за писане там. От друга страна съдържанието на зоните е публична информация и всеки потребител на системата може да я чете (т.е. тази информация не може да бъде използвана за причиняване на вреди върху системата).

Що се касае до поддиректорията var/named/slave, то при нея положението е малко по-различно. Там се съхраняват зони, спрямо които демонът named-as112 реализира локално тяхно копие ("slave" зони), а оригиналното копие е върху отдалечен сървър за имена. В тази директория се съхранява копие на зоната iana.org. Това е наложително (както ще стане ясно по-долу) за да може сървърът да прибавя към отговорите допълнителна достоверна информация за A ресурсните записи на сървърите за имена. В директория права за писане имат root и непривилигерования потребител, с чиито права се стартират процесите на демона named-as112. Всички потребители на системата могат да четат съдържанието на директорията, доколкото то е публична информация (наличната информация не може да бъде използвана за причиняване на вреди върху системата).

В директорията var/named/stats се съхраняват резултатите от изпълнението на "rndc stats". Това са данни, които могат да се сумират при анализ броят заявки (по вид и по характер на отговора) към дадена зона за периода между две изпълнения на "rndc stats". Тази информаци е публична и за това няма ограничения върху четенето й от страна на всички потребители на системата. Права за писане имат само root и непривилигерования потребител на системата, с чиито права се изпълняват процесите на демона named-as112.

8. Обслужвани зони на домейни от демона named-as112

Една особеност на зоните на in-addr.arpa домейни в състава на проекта AS112 е това, че те имат еднакво съдържание. Това означава, че всички дефиниции на зони във файла named.conf могат да сочат към един единствен файл, който има следното съдържание:

Тази дефиция на зонален файл е определена от IANA и не бива да бъде модифицирана по никакъв начин. Всяко нейно модифициране от гледна точка на промяна, прибавяне или отстраняване на ресурсни запис е грубо нарушение над функционалността на AS112 и трябва да бъде санкционирано. Копие на зоната (за сравнение), може да се получи от някои от unicast адресите на AS112 из Интернет или от интернет страницата на проекта. С цел обществен контрол, зоните на всички домейни, които се обслужват върху този сървър за имена трябва да са свободно изтегляеми. Само така може да се установи доверие от страна на потребителите към доставчика на решението. Затварането за трансфер на тези зони е некоректно спрямо ползвателите на съответния възел на AS112 и няма нищо общо с така желаната от всички "мрежова етика". Някак не се връзва предоставянето на обществена услуга, на която всички да се доверяват под формата на "черна кутия", чието съдържание е неизвестно.

Зоните на домейни, които се обслужват в рамките на сървърите за имена в AS112 са следните:

Всички от посочените in-addr.arpa зони, използват за зонален файл такъв, с универсалното съдържание, посочено по-горе и дефинирано от IANA. Зоната prisoner.iana.org има указателна функция. Нейната цел е да посочи unicast IP адреса на използвания възел и организацията, която е отговорна за неговото поддържане. Конкретно за единият от възлите на AS112 в мрежата на Софийския Университет "Св. Климент Охридски", нейното съдържание е следното:

Именно чрез наличието на въпросната зона, всеки участник в Интернет може да провери кой точно възел на AS112 използва, като изпълни команден ред от типа:

Доколкото при прочита биха възникнали въпроси от типа на "а защо TTL по подразбиране за всички записи в зоната hostname.as112.net е нула секунди", е необходим съответния анализ. В настоящия момент Интернет е преносна среда с динамична маршрутизация. Това означава, че в даден момент вследствие на динамиката на маршрутизацията, може да се използва един възел, а в друг момент друг, различен от първия. Този процес може да бъде достатъчно динамичен, особено при по-добра алтернативна свързаност (BGP процеса върху маршрутизаторите е арбитърът, който решава кой от наличните в момента пътища до AS112 е актуален). Нека си представим какво би станало, ако обявим време на живот на записите за hostname.as112.net, по-голямо от нула (прмерно 300 секунди) и тези записи попаднат в даден кеширащ сървър за имена. В продължение на 300 секунди той ще ги връща като отговор на евентуално запитване от страна на клиент. През тези 300 секунди може BGP процеса на маршрутизатора да избере друг маршрут (и следователно да се използва и друг възел на AS112) и това да направи кешираните записи неактуални (да не кажем неверни). Ако обаче времето на живот на записите е нула секунди, те няма да се кешират и винаги информацията за тях ще бъде актуална (некеширана). Веднага може да се зададе контрааргумент от типа на "да, но всеки клиент може да подаде директна заявка към prisoner.iana.org (виж примерите по-горе) и така да получи актуален отговор без да се налага да се използва кеширащ сървър за имена и тогава е все едно какво е времето на живот на записие за hostname.as112.net в нечии кеш". До някъде е вярно, но нека не забравяме, че има мрежи в Интернет, на хостовете на които е забранено да излъчват заявки (съответно приемат отговори на заявките си) към порт 53/udp/tcp на сървъри за имена извън локалната им мрежа. Тогава те винаги трябва да използват локалните кеширащи сървъри за имена, защото нямат друга възможност.

9. Конфигурационен файл named.conf на демона named-as112

Няма обща схема за изграждане на съдържанието на файла named.conf, който се използва от демона named-as112. Но все пак, общото във всички негови реализации е обслужването на заявки за зоните на домейни описани по-горе. Всички те се обявяват като "master" чрез използване на следния шаблон:

където "XYX" замества октетното описание на зоната на in-addr.arpa домейна. Всички дефиции на in-addr.arpa домейни са асоциирани към съдържанието, налично във файла /home/chroots/named-as112/var/named/master/as112. Това улеснение в възможно благодарение на универсалната дефиниция на зона за всички тези домейни (всички те имат едно и също съдържание). Зоните са свободни за трансфер с цел проверка на съдържанието им от заинтересованите от това интернет потребители. Целта е пълна прозрачност, което означава, че операторът на AS112 не поставя в зоните каквито и да са специфични записи, които биха били в ущърб някому.

Зоната на домейна hostname.as112.net се дефинира за обслужване по следния начин:

И тук, трансферът е разрешен - това е публична услуга и всички данни, които не застрашават по някакъв начин услугата, са разрешени за публичен достъп.

С цел откритост към потребителите на AS112, по-долу е публикувано пълното съдътржание на файла named.conf, който демона named-as112 използва:

Интересно би било да се направи коментар отновно обявяването на разрешенията за комуникация от страна на rndc. Съгласно описанието (декларацията controls), заявки могат да се изпращат до всички използвани адреси от състава на AS112 от rndc процес. Такива обаче се приемат за изпълнение само, ако от гледна точка на демона named-as112 се изпращат от localhost. Това означава, че порта за приемане на rndc заявки е достъпен само от локалния хост и от никъде другаде.

Друг интересен момент е използването на процес на named-as112 без PID файл (pid-file none;). Това е възможно, защото спирането на демона може да става с команда от страна на rndc, а не чрез изпращане на стандартен сигнал (kill) до процеса. Това силно отличава демонът на BIND9 от останалите популярни демони в UNIX.

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

10. Особености на използването на rndc

Комуникацията между инстумента rndc и съответния сървърски процес на named се реализира по подразбиране на порт 953/tcp, отворен от демона.

Ако се следват описанията в named.conf от по-горе, би следвало подаване на команди чрез rndc към демона named-as112 да може да става само от локалния за възела хост. Погледнато по-подробно обаче, редовете за контрол в named.conf указват само, че няма да бъдат приемани за обслужване заявки от хостове извън списъка. Това не значи обаче, че заявките няма да достигат до диалогов режим и инициране на TCP сесия. Този факт може да се разглежда, като вероятна възможност за атака към демона named-as112 с цел инициране на високо натоварване. За да бъде предпазен той, е добре да бъде изградена схема за филтрация на заявките към порта за комнукация с rndc. Следва да бъде споменато, че при реализацията на пакетен филтър с netfilter, е изключително лоша практика използването на политика DROP за отхвърляне на пакетите, съдържащи заявки за сесия към порта за комуникация с rndc. Правилният подход изисква системата да показва, че просто портът не е отворен така, както тя би показала това за произволен нейн порт, на който не "слуша" приложение. Това става като се използва отхвърляне на пакета към порта с ICMP протоколно съобщение за недостижимост на порта (ICMP - port unreachable).

Тук се представя реализация, при която адресите от сегмента на AS112 са върху виртуален интерфейс (dummy0) и контрола на достъпа до тях позволява подаване на rndc команди само от страна на адрес 127.0.0.1. Върху сървърите е активирана защитна схема (чрез netfilter), която защитава порта на демона named-as112 за комнукация с rndc, от "заливането" му със заявки. Освен това има защита спрямо IP измама, чрез която пакет с излъчвател 127.0.0.1 или с някой от трите използвани IP адреса от AS112, не може да влезе в системата през публичния интерфейс. Самата IP измама се предотвратява като се използва свойството на Linux ядрата да не допускат влизане на пакет с източник локален за системата адрес, през интерфейс, който не е обвързан с адреса.

Ключът на демона (използва се в рамките на TSIG), се намира във файла /etc/as112.key, който е симетрична връзка към /home/chroots/named-as112/etc/as112.key върху локалната файлова система.

В конкретният случай на реализация на DNS услугите в рамките на проекта AS112, трябва с един инструмент rndc да бъдат управлявани 2 демона. За да се обясни как става това, ето съдържанието на файла /etc/rndc.conf (конкретно за възела с unicast IP адрес 62.44.96.1):

Когато се извършва подаване на команда чрез rndc към демона named-as112, то се указва IP адреса, до който се адресира заявката с командата. За да достигне тя до named-as112, трябва да се изпрати към някой от адресите 192.175.48.1, 192.175.48.6 или 192.175.48.42. Изпращането до конкретен IP адрес става чрез опция "-s" придружена от адреса, на който приема заявки демона. Например:

ще изпрати команда за проверка на статуса на демона named-as112 като я адресира до IP адрес 192.175.48.1. Трябва да се отбележи обаче, че ако командния ред се изпълни така:

то командата за проверка на статуса ще отиде към демона named-as5421, който слуша на IP адрес 62.44.96.1. Причината за това е, че ако не бъде указан IP адрес на сървъра чрез опцията "-s", то командата ще бъде изпратена до този сървър, който е обявен като "default-server" в /etc/rndc.conf.

11. Неприложимост на TSIG в рамките на проекта AS112

Ако се следва хода на подобно изложение и добрата практика по администриране на DNS услуги, възниква един въпрос, който може да се формулира като "а защо да не се използва TSIG за подписване на DNS заявките/отговорите от и към AS112, с цел по-добра идентификация на субекта, който предоставя услугата".

Отговорът на този въпрос е "това е невъзможно в условия на динамична маршрутизация на заявките". Причината е, че се работи с anycast базирани системи и сървъри за имена, които в общия случай са неизвестен брой и в тях и няма как да се използва един единствен идентификатор базиран към IP адрес, какъвто е именно HMAC-MD5 ключа при TSIG подписването на заявки/отговори. Няма как да се направи така, че всички anycast възли и всички клиенти, които ги използват да знаят ключа за подписване (който се използва и за проверка на електронния подпис) на заявките/отговорите, защото подобно публично ознаване на ключа обезмисля TSIG схемата, тък като всеки ще знае този ключ и ще може да подписва с него отговорите на заявките. TSIG все още използва HMAC-MD5 със споделен секретен ключ.

Да си представим следния случай. С оператора на най-близкия възел на AS112 е обменен секретен ключ за подписване на заявките и отговорите им в рамките на алгоритъма HMAC-MD5. Сървърът за имена на възела на AS112 приема заявките, проверява електронния подпис върху тях, изпълнява ги и връща отговорите подписани със споделения секретен ключ. Отговора е подписан и проверката върху него се извършва от страна на клиента, чрез локалното копие на обменения секретен ключ. Схемата ще работи до момента, в който динамичната маршрутизация не направи така, че излъчена заявка да попадне върху възел на AS112, който е различен от този, който е споделил секретния ключ с клиента. Заявката, попадайки на този друг възел, или се подписва с друг ключ или въобще не се подписва. Така се получава проблем с проверката на идентичността при подписването и заявката и отговора й пропадат.