Версия 1.2, 14 октомври 2007
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Този документ има смисъла на техническо ръководство, по което е изграден локалния възел на проекта "AS112 в мрежата на Софийския Университет "Св. Климент Охридски". Оператор на проекта е Университетския изчислителен център (УИЦ) на СУ "Св. Климент Охридски". Тази документация се публикува публично с цел пълна прозрачност на решението и в стила на добрата практика по администрация на отворени системи и проекти. Проектът AS112 е разработка на Paul Vixie от Internet Systems Consortium. AS112 е автономна система, включваща алокация на anycast адресно простраство 192.175.48.0/24. Интернет страницата на проекта е на адрес http://www.as112.net.
В рамките на IP адресното пространство версия 4 (IPv4), има адресни сегменти, които са отделени за частно (локално) използване. Това ще рече, че те не се маршрутизират глобално, а само локално, за локални (частни) цели. RFC3330 (първото указване е в RFC1918, а RFC3330 е по-обобщаващ документ, който прави "карта" на адресните сегменти за специално използване в рамките на IPv4 адресното пространство), указва кои от адресните пространства в рамките на IPv4 могат да бъдат използвани за частни цели. Такива са:
10.0.0.0/8 172.16.0.0/12 169.254.0.0/16 192.168.0.0/16
Уместен е въпросът "а след като всеки може да използва тези адресни пространства или част от тях, кой тогава извършва записите в съответната 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 домайните за адресните пространства за частно ползване. Тези сървъри за имена са:
prisoner.iana.org (192.175.48.1) blackhole-1.iana.org (192.175.48.6) blackhole-2.iana.org (192.175.48.42)
Ако всички масово използват глобалните сървъри за имена, отговорни тези домейни, то те ще бъдат затрупани със заявки, поради това, че използването на частни адресни пространства е много полулярно.
Както бе споменато по-горе, адресното пространство, алокирано към AS112 има само една единствена сегментна адресна алокация - 192.175.48.0/24. Именно този маршрутен обект е обявен в в режим на anycast. От него за нуждите на сървърите за имена за in-addr.arpa домейните на мрежовите адресни пространства за частно ползване, се използват следните три IP адреса:
192.175.48.1 (prisoner.iana.org) 192.175.48.6 (blackhole-1.iana.org) 192.175.48.42 (blackhole-2.iana.org)
Останалите адреси от сегмента нямат целево назначение. Основателно възниква въпроса "защо за нуждите на anycast е заделено адресно пространство с дължината на мрежовата маска 24 бита, след като в него се използват реално само три IP адреса"? Причината е в глобалната система за маршрутизация в Интернет. Транзитните доставчици осъществяват транзит (съгласно информацията в динамичните протоколи за маршрутизация), само на мрежови сегменти, които са декларирани като маршрутни обекти в наличните за целта бази от данни (виж http://www.radb.net за повече подробности). Към настоящия момент BGP филтрите на транзитните доставчици отхвърлят анонси за IPv4 маршрутни обекти с дължина на мрежовата маска по-голяма от 24 бита.
Проектът "AS112 в мрежата на Софийския Университет "Св. Климент Охридски" използва два физически отделни DNS процеса, локирани върху два различни сървъра. Първият процес се намира върху сървъра ns.uni-sofia.bg (unicast IP адрес 62.44.96.1), а втория върху сървъра ady.uni-sofia.bg (unicast IP адрес 62.44.96.7). Двата сървъра имат идентична конфигурация на DNS демоните (ще бъде дискутирана в подробности по-долу). Подобно локиране на процесите върху два сървъра определя решението като "двувъзлово" ("двунодово").
Използваемите 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:
# Съдържание на конфигурационния файл ifcfg-dummy0 # за управление на виртуалния интерфейс dummy0 DEVICE=dummy0 TYPE=ethernet ONBOOT=yes NETWORK=192.175.48.0 IPADDR=192.175.48.1 NETMASK=255.255.255.0
Псевдонимът dummy0:0 на виртуалния мрежови интерфейс dummy0 е дефиниран във файла ifcfg-dummy0:0, който също, както и съответния конфигурационен файл за интерфейса dummy0, се намира в директория /etc/sysconfig/network-scripts:
# Съдържание на конфигурационния файл ifcfg-dummy0:0 # за управление на псевдонима dummy0:0 NETWORK=192.175.48.0 IPADDR=192.175.48.6 NETMASK=255.255.255.0
Аналогично е положението и при дефинирането и управлението на псевдонима dummy0:1:
# Съдържание на конфигурационния файл ifcfg-dummy0:1 # за управление на псевдонима dummy0:1 NETWORK=192.175.48.0 IPADDR=192.175.48.42 NETMASK=255.255.255.0
Точно на това място трябва да бъде обсъден един дискусионен момент, а именно защо е нужно да се използва виртуален интерфейс вместо да се дефинират всички нужни адреси върху псевдоними на някой от реалните физически интерфейси на машината (например eth0). Трябва да се каже, че чрез използването на виртуален мрежови интерфейс и поставяне на псевдонимите върху него, се избягва излагането на сегмента 192.175.48.0/24 директно в етернет средата. За да се поясни значението на това изолиране на сегмента от етернет средата, трябва да се каже, че подобна изолация не позволява arp запитвания към адрес от сегмента и така се предотвратява евентуална колизия на IP адреси, която е винаги вероятна в една етернет среда. Също така, по този начин в един етернет сегмент може да има два или повече възела на AS112, без те да си пречат - нека си представим какво би станало, ако двата възела са в един мрежов сегмент и адресите от 192.175.48.0/24 са дефинирани върху псевдоними на мрежовите интерфейси, с които машините на възлите членуват в един и същи етернет сегмент.
Двата възела на AS112 в мрежата на Софийския Университет "Св. Климент Охридски" "съобщават" на участниците в Интернет за маршрута до себе си, чрез използването на протоколи за динамична маршрутизация OSPF и BGPv4. Нодовете на AS112 са свързани чрез граничния маршрутизатор на AS5421 по следната схема. Всеки един от възлите участва в OSPF area 0.0.0.0 чрез публичните си unicast IP адреси, които са в мрежовия сегмент 62.44.96.0/26. В тази area 0.0.0.0 се намира маршртутизаторът 62.44.96.3, който "общува" чрез протокола OSPF с двата възела на AS112. В същото време маршрутизаторът 62.44.96.3 е в една и съща OSPF area 62.44.127.0 с граничния маршрутизатор на AS5421. Всеки един от възлите на AS112 осъществява с граничния маршрутизатор на AS5421 по една BGPv4 сесия, като се използва динамичния протокол OSPF за "вътрешен" маршрутизиращ протокол, който да укаже на всяка една от участващите в BGPv4 сесията страни, през кой междинен маршрутизатор се достъпва BGP съседа. Самата конструкция на BGPv4 изиксва да има такъв вътрешен динамичен протокол, в случаите, в който осъществяващите BGPv4 сесия хостове не са в един и същ етернет сегмент (строго погледнато може да се използва и статична вътрешна маршрутизация, но в общия случай това е тромава схема, която може да доведе до проблеми; може да се използва и протокол за динамична маршрутизация RIPv2, който обаче е по-бавен от OSPF).
Ето конфигурационните файлове /etc/quagga/ospfd.conf на двата възела на AS112 в мрежата на Софийския Университет "Св. Климент Охридски":
! ! Zebra configuration saved from vty ! 2005/03/19 21:05:03 ! hostname su.uni-sofia.bg password xxxxxxxxxxxxxxx log file /var/log/quagga/ospfd.log ! interface eth0 description default ! interface lo ! interface sit0 ! router ospf ospf router-id 62.44.96.1 redistribute connected metric 3 network 62.44.96.0/26 area 0.0.0.0 distribute-list anon-out out connected ! access-list anon-out permit 192.175.48.0/24 access-list anon-out deny any access-list vty-access permit 127.0.0.1/32 access-list vty-access deny any ! line vty access-class vty-access !
! ! Zebra configuration saved from vty ! 2005/03/19 21:08:03 ! hostname ady.uni-sofia.bg password xxxxxxxxxxxxxxx log file /var/log/quagga/ospfd.log ! interface eth0 description default ! interface lo ! interface sit0 ! router ospf ospf router-id 62.44.96.7 redistribute connected metric 3 network 62.44.96.0/26 area 0.0.0.0 distribute-list anon-out out connected ! access-list anon-out permit 192.175.48.0/24 access-list anon-out deny any access-list vty-access permit 127.0.0.1/32 access-list vty-access deny any ! line vty access-class vty-access !
Съответните BGPv4 конфигурационни файлове /etc/quagga/bgpd.conf за двата възела изглеждат по следния начин:
! ! Zebra configuration saved from vty ! 2005/10/24 15:15:28 ! hostname su.uni-sofia.bg password xxxxxxxxxxxxxxx log file /var/log/quagga/bgpd.log ! debug bgp events ! router bgp 112 bgp router-id 62.44.96.1 bgp log-neighbor-changes network 192.175.48.0/24 neighbor 62.44.127.1 remote-as 5421 neighbor 62.44.127.1 description Sofia University Border neighbor 62.44.127.1 ebgp-multihop 5 neighbor 62.44.127.1 soft-reconfiguration inbound neighbor 62.44.127.1 distribute-list anon-in in neighbor 62.44.127.1 distribute-list anon-out out ! access-list anon-in deny any access-list anon-out permit 192.175.48.0/24 access-list anon-out deny any access-list vty-access permit 127.0.0.1/32 access-list vty-access deny any ! line vty access-class vty-access !
! ! Zebra configuration saved from vty ! 2005/10/24 15:19:05 ! hostname su.uni-sofia.bg password xxxxxxxxxxxxxxx log file /var/log/quagga/bgpd.log ! debug bgp events ! router bgp 112 bgp router-id 62.44.96.7 bgp log-neighbor-changes network 192.175.48.0/24 neighbor 62.44.127.1 remote-as 5421 neighbor 62.44.127.1 description Sofia University Border neighbor 62.44.127.1 ebgp-multihop 5 neighbor 62.44.127.1 soft-reconfiguration inbound neighbor 62.44.127.1 distribute-list anon-in in neighbor 62.44.127.1 distribute-list anon-out out ! access-list anon-in deny any access-list anon-out permit 192.175.48.0/24 access-list anon-out deny any access-list vty-access permit 127.0.0.1/32 access-list vty-access deny any ! line vty access-class vty-access !
Особеност на реализацията на 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
Скриптът /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:
named-as5421:x:10001:10001:Named user for AS5421:/home/chroot/named-as5421:/sbin/nologin named-as112:x:602:602:Named user for AS112:/home/chroot/named-as5421:/sbin/nologin
Групата с идентификатор 602 също се нарича named-as112 и има за единствен член потребителя named-as112 (за когото тя е главна група). Задаването на групата става без указване на парола за членство в нея, така че само root може да прибавя или премахва нови членове.
Тук е мястото за малка дискусия. На пръв поглед може да се стори нерационално решението за дефиниране на нов потребител и група за демон, който и без това има назначен непривилигерован потребител за собственик на процесите на демона. Обикновено във Fedora Core това е потребителят named. Той бива дефиниран в система от постинсталационния скрипт на пакета named. Нужно е да се отбележи, че при клонирането на демоните (виж по-долу), се налага да има повече от един демон named в системата. От гледната точка на добрата администрация на системата, е добре процесите на двата демона да са собственост на различни потребители за да няма възможност процес на единия демон да засяга процеси на другия, което щеше да е възможно, ако и двата демона стартират процесите си с правата на един и същ непривилигерован потребител.
За да бъдат решени проблемите около имената на процесите на демона named, стартиращи се от описаните по-горе инициращи скриптове, е направено клониране на изпълнимия файла на демона, чрез симетрични връзки към изпълнимия файл /usr/sbin/named имащи различни имена:
# ln -s /usr/sbin/named /usr/sbin/named-as5421 # ln -s /usr/sbin/named /usr/sbin/named-as112
Нужно е да се отбележи, че при този начин, безпроблемно се решава проблема с актуализиране на версията на пакета bind от пакетната колекция на дистрибуцията. Т.е. при смяната на бинарния файл /usr/sbin/named с нов, автоматично се актуализират клонираните демони named-as5421 и named-as112 доколкото те се стартират от изпълнимите символни връзки към него.
Конфигурирането на BIND9 за нуждите на проекта AS112 в мрежата на Софийския Университет "Св. Климент Охридски", следва от описаната по-горе схема на оперативни настройки на демона named. Конфигурационният файл named.conf се намира в поддиректория etc/ на директорията, която е зададена във файла с променливите /etc/sysconfig/named-as112. В конкретния случай това е /home/chroots/named-as112. Съдържанието на директорията /home/chroots/named-as112 е слендото:
dev/
log
null
random
urandom
zero
etc/
localtime
named.conf
as112.key
var/
log/
named/
general.log
notify.log
queries.log
security.log
zonetransfer.log
named/
master/
as112
hostname.as112.net
slave/
iana.org
stats/
named-as112.stats
Доколкото демонът named работи в chroot схема, то показаната по-горе директорийна структура, донякъде наподобява реално съществуваща такава в директорията "/". Ето и детайлно обяснение за използването на всяка една директория и файл в нея.
dev/
Поддиректория dev/ служи за аналог на директория /dev от "/" файловата система. В нея са поставени необходимите за работата на named сокети и символни устройства. Създаването на тази директория и установяване на правата върху нея следва последоватеността:
# cd /home/chroot/named-as112/ # mkdir dev # chmod 750 dev/ # chown root:named-as112 dev/
dev/log
Това е сокет, отворен от демона syslogd. "Отварянето" на този сокет в тази директория става чрез указването на пълния път до сокета във файла /etc/sysconfig/syslog. При указването в този файла се използва опция "-a":
SYSLOGD_OPTIONS="-m 0 -a /home/chroot/named-as112/dev/log"
След указването на пълния път, е нужно да се рестартира демона syslogd:
# service syslog restart
и сокета log ще се "отвори" в директория /home/chroots/named-as112/dev.
dev/null
Това е символно устройство, аналог на /dev/null и има същото предназначение. За да бъде напрвено това устройство се изпълняват следните команди:
# MAKEDEV -d /home/chroots/named-as112/dev null
dev/random
Това символно устройство се използва за генератор на случайни числа, аналог на /dev/random. Създава се чрез команден ред подобен на следния:
# MAKEDEV -d /home/chroots/named-as112/dev random
dev/urandom
Това символно устройство е аналог на /dev/urandom. Създава се по следния начин:
# MAKEDEV -d /home/chroots/named-as112/dev urandom
dev/zero
Символното устройство dev/zero е аналог на /dev/zero и може да бъде изградено така:
# MAKEDEV -d /home/chroots/named-as112/dev zero
etc/
Тази директория е аналог на /etc. Създаването й може да се опише така:
# cd /home/chroots/named-as112/ # mkdir etc # chmod 750 etc/ # chown root:named-as112 etc/
etc/localtime
Това е копие на файла /etc/localtime, който съдържа дефинициите на часовите зони. При наличие на актуализация (update) на пакета tzdata, след привършване на процеса на актуализиране, е наложително да се извърши копиране на актуалната версия на /etc/localtime в /home/chroots/named-as112/etc.
etc/named.conf
В този файл се съдържа конфигурацията на демона named-as112. Тя ще бъде дискутирана по-долу. Установяване на правата върху този файл следва схемата:
# cd /home/chroots/named-as112/etc # chmod 644 named.conf
Необходимо е да се обоснове това отдаване на права за четене на файла named.conf от страна на всеки потребител на системата, за да бъдат пресечени спекулативни дискусии по темата в самия им зародиш. Този файл не съдържа поверителна информация, която би могла да бъде използвана по някакъв начин за смущаване на работата на демона. Единствените сензитивни данни са тези за ключа за управление на демона от страна на инструмента rndc. За да не се съдържа стойността на ключа във файла named.conf, той се указва за влагане в паметта при прочит от демона named-as112 чрез дефиниция "include /path/to/rndc.key_file". Правата върху файла с ключа са такива, че не позволяват прочита на съдържанието му от всеки, а само от root и потребителя, с чиито права работи демона named-as112 (както бе указано по-горе, това е потребителя named-as112). Така съдържанието на файла named.conf може да е публична информация, без това да застрашава работата на демона.
etc/as112.key
Това е ключът, който инструмента rndc използва в рамките на TSIG схема за да подписва заявките към демона. Ключът трябва да може да бъде читаем само от страна на непривилигерования потребител, който е собственик на процесите на демона named-as112. Правата върху този файл се дефинират чрез следната схема:
# cd /home/chroots/named-as112/etc # chmod 640 as112.key # chown root:named-as112 as112.key
Един интересен въпрос е защо непривилигерования потребител, който е собственик на процесите на демона named-as112 може само да чете файла с ключа, но не може да пише (да пише там може единствено потребителя root). Това се прави с цел предпазване на ключа от промяна, ако демона named-as112 бъде "пробит" без да може атакуващия да придобие права на root (това може да бъде направено с цел съботаж или трайно придобиване на достъп след актуализиране на "пробиваемата" версия на пакета bind). Така при актуализация на пакета bind и рестартиране на демона named-as112, ще бъде прочетен актуалния ключ (променения от атакуващия може да остане само в паметта и при презареждане да бъде изтрит).
var/
Тази директория е аналог на директорията /var. В нея се съдържат журналните файлове, водени от демона named-as112, а също така копия на зоните на нужните за функционирането на DNS услугата на AS112 домейни. Създаването на var/ следва следната схема:
# cd /home/chroots/named-as112/ # mkdir var # chown root:named-as112 var/ # chmod 750 var/
Създаването на поддиректорийната структура се извършва по следния примерен начин:
# cd /home/chroots/named-as112/var/ # mkdir -p named log/named # chmod 750 log/named # chown named-as112 log/named # mkdir var/named/master var/named/slave var/named/stats # chmod 755 var/named/master # chown root:root var/named/master # chmod 755 var/named/slave # chown named-as112:named-as112 var/named/slave # chmod 755 var/named/stats # chown named-as112:named-as112 var/named/stats
var/log/named
В тази директория демонът named-as112 описва събитията относно обслужването на заявки, трансфера на зони и др. събития. Характерът и наименованието на журнала се указва в конфигурационния файл named.conf. Права за писане в тази директория имат root и потребителят, с чиито права се изпълняват процесите на демона named-as112. Права за четене на информация от тази директория имат само и единствено тези потребители, които могат да пишат в нея и тези от прилежащата им главна група. Свободното четене от тази директория е забранено по чисто политически причини. Софийския Университет "Св. Климент Охридски" не иска да изнася по никакъв начин публично данни за това кои публични IP адресни пространства излъчват заявки към AS112. Това се прави с цел да се избегнат спекулативни тълкувания на тези данни на фона на твърде сложните и доста честно некоретктни отношения между доставчиците на интернет свързаност, и да се затрудни събирането на информация за това кой какви частни адресни сегменти използва. Българското интернет пространство, от гледна точка на манталитета на участниците в него, все още не е узряло за свободното предоставяне на подобна информация.
var/named/master
Поддиректорията var/named/master съдържа файлове с описанията на "master" зоните на домейни, които локално се обслужват от демона named-as112. Самата директория, както и файловете в нея не са писаеми от страна на никой друг, освен root. Доколкото това са "master" зони и не са в режим на динамично обновяване на ресурсните запси в тях, то не е наложително непривилигерования потребител, с чиито права се стартират процесите на демона named-as112, да има права за писане там. От друга страна съдържанието на зоните е публична информация и всеки потребител на системата може да я чете (т.е. тази информация не може да бъде използвана за причиняване на вреди върху системата).
var/named/slave
Що се касае до поддиректорията var/named/slave, то при нея положението е малко по-различно. Там се съхраняват зони, спрямо които демонът named-as112 реализира локално тяхно копие ("slave" зони), а оригиналното копие е върху отдалечен сървър за имена. В тази директория се съхранява копие на зоната iana.org. Това е наложително (както ще стане ясно по-долу) за да може сървърът да прибавя към отговорите допълнителна достоверна информация за A ресурсните записи на сървърите за имена. В директория права за писане имат root и непривилигерования потребител, с чиито права се стартират процесите на демона named-as112. Всички потребители на системата могат да четат съдържанието на директорията, доколкото то е публична информация (наличната информация не може да бъде използвана за причиняване на вреди върху системата).
var/named/stats
В директорията var/named/stats се съхраняват резултатите от изпълнението на "rndc stats". Това са данни, които могат да се сумират при анализ броят заявки (по вид и по характер на отговора) към дадена зона за периода между две изпълнения на "rndc stats". Тази информаци е публична и за това няма ограничения върху четенето й от страна на всички потребители на системата. Права за писане имат само root и непривилигерования потребител на системата, с чиито права се изпълняват процесите на демона named-as112.
Една особеност на зоните на in-addr.arpa домейни в състава на проекта AS112 е това, че те имат еднакво съдържание. Това означава, че всички дефиниции на зони във файла named.conf могат да сочат към един единствен файл, който има следното съдържание:
$TTL 604800 @ SOA prisoner.iana.org. hostmaster.root-servers.org. ( 2002061700 1800 900 604800 604800 ) NS blackhole-1.iana.org. NS blackhole-2.iana.org.
Тази дефиция на зонален файл е определена от IANA и не бива да бъде модифицирана по никакъв начин. Всяко нейно модифициране от гледна точка на промяна, прибавяне или отстраняване на ресурсни запис е грубо нарушение над функционалността на AS112 и трябва да бъде санкционирано. Копие на зоната (за сравнение), може да се получи от някои от unicast адресите на AS112 из Интернет или от интернет страницата на проекта. С цел обществен контрол, зоните на всички домейни, които се обслужват върху този сървър за имена трябва да са свободно изтегляеми. Само така може да се установи доверие от страна на потребителите към доставчика на решението. Затварането за трансфер на тези зони е некоректно спрямо ползвателите на съответния възел на AS112 и няма нищо общо с така желаната от всички "мрежова етика". Някак не се връзва предоставянето на обществена услуга, на която всички да се доверяват под формата на "черна кутия", чието съдържание е неизвестно.
Зоните на домейни, които се обслужват в рамките на сървърите за имена в AS112 са следните:
10.in-addr.arpa 254.169.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa hostname.as112.net
Всички от посочените in-addr.arpa зони, използват за зонален файл такъв, с универсалното съдържание, посочено по-горе и дефинирано от IANA. Зоната prisoner.iana.org има указателна функция. Нейната цел е да посочи unicast IP адреса на използвания възел и организацията, която е отговорна за неговото поддържане. Конкретно за единият от възлите на AS112 в мрежата на Софийския Университет "Св. Климент Охридски", нейното съдържание е следното:
$TTL 0 @ SOA su.uni-sofia.bg. root.uni-sofia.bg. ( 2005013100 3600 600 2592000 15 ) NS blackhole-1.iana.org. NS blackhole-2.iana.org. TXT "University of Sofia, Bulgaria" TXT "NODE 1: via 62.44.96.1 (AS5421)" TXT "See http://as112.net/ for more information."
Именно чрез наличието на въпросната зона, всеки участник в Интернет може да провери кой точно възел на AS112 използва, като изпълни команден ред от типа:
чрез инструмента dig:
$ dig @prisoner.iana.org -t any hostname.as112.net
чрез инструмента host:
$ host -t any hostname.as112.net prisoner.iana.org
чрез инструмента nslookup:
$ nslookup > server prisoner.iana.org Default server: prisoner.iana.org Address: 192.175.48.1#53 > set type=any > hostname.as112.net
Доколкото при прочита биха възникнали въпроси от типа на "а защо TTL по подразбиране за всички записи в зоната hostname.as112.net е нула секунди", е необходим съответния анализ. В настоящия момент Интернет е преносна среда с динамична маршрутизация. Това означава, че в даден момент вследствие на динамиката на маршрутизацията, може да се използва един възел, а в друг момент друг, различен от първия. Този процес може да бъде достатъчно динамичен, особено при по-добра алтернативна свързаност (BGP процеса върху маршрутизаторите е арбитърът, който решава кой от наличните в момента пътища до AS112 е актуален). Нека си представим какво би станало, ако обявим време на живот на записите за hostname.as112.net, по-голямо от нула (прмерно 300 секунди) и тези записи попаднат в даден кеширащ сървър за имена. В продължение на 300 секунди той ще ги връща като отговор на евентуално запитване от страна на клиент. През тези 300 секунди може BGP процеса на маршрутизатора да избере друг маршрут (и следователно да се използва и друг възел на AS112) и това да направи кешираните записи неактуални (да не кажем неверни). Ако обаче времето на живот на записите е нула секунди, те няма да се кешират и винаги информацията за тях ще бъде актуална (некеширана). Веднага може да се зададе контрааргумент от типа на "да, но всеки клиент може да подаде директна заявка към prisoner.iana.org (виж примерите по-горе) и така да получи актуален отговор без да се налага да се използва кеширащ сървър за имена и тогава е все едно какво е времето на живот на записие за hostname.as112.net в нечии кеш". До някъде е вярно, но нека не забравяме, че има мрежи в Интернет, на хостовете на които е забранено да излъчват заявки (съответно приемат отговори на заявките си) към порт 53/udp/tcp на сървъри за имена извън локалната им мрежа. Тогава те винаги трябва да използват локалните кеширащи сървъри за имена, защото нямат друга възможност.
iana.org
Тази зона е свободно изтегляема от сървърите за имена, достоверни за нея. Свободното изтегляне на зоната е в съгласие с обществената мисия на IANA. Зоната iana.org, съгласно указанията по изграждането на сървърите за имена в рамките на проекта AS112, трябва да присъства върху тях. Това се прави със следната цел. Както се вижда по-горе, в универсалната дефиниция за зонален файл за in-addr.arpa домейните, има подаване в отговора на заявките на съвърите за имена за съответния in-addr.arpa домейн. Тези сървъри за имена са винаги едни и същи: blackhole-1.iana.org и blackhole-2.iana.org. Нека проследим заявката и получения за нея отговор. Всички успешни заявки (успешна заявка е такава, в отговора за която се съдържа флаг за статус "NOERROR"), към някоя от in-addr.arpa зоните обслужвани в рамките на проекта AS112, съдържат в себе си сървърите за имена, които са указани в универсалната зона, формулирана от IANA. Това са обаче сървъри за имена, които са в състава на зоната iana.org. Т.е. след като получи отговора на своята заявка, сървърът за имена трябва да направи още поне една допълнителна заявка, за да получи IP адреса на един от сървърите за имена blackhole-1.iana.org или blackhole-2.iana.org. За да го получи обаче, той трябва да направи заявка към един от достоверните сървъри за имена на домейна iana.org. Тук обаче се получава едно привидно противоречие. Нали целта на проекта AS112 е да избави именно сървърите на IANA от претоварване, а се получава точно обратното - пак сървърите на IANA се обсипват със заявки. Противоречието се снема обаче, ако се отчете наличието на зоната iana.org върху сървърите за имена от проекта AS112. В рамките на протокола, по който работи системата за имена в Интернет, е възможно в отговора на заявката на има т.нар. "прибавени" ("additional") записи. Такива записи могат да бъдат прибавяни само, ако са налични в локална за прибавилия ги сървър за имена зона на домейн, или в неговия кеш. Точно такъв е случая при сървърите за имена в рамките на проекта AS112. Имайки върху себе си зоната iana.org, те могат да прибавят записи от нея, когато това се налага, в отговорите на обслужваните от тях заявки. В конкретния случай, те ще добавят в отговора на заявките IP адресите на сървърите за имена blackhole-1.iana.org и blackhole-2.iana.org. Освен това ще ги подадат с времето за живот, което тези записи имат в зоната на домейна iana.org (3600 секунди към момента на написване на тази документация). Следователно тези записи ще бъдат кеширани от сървъра получател на отговора на заявката. Ето как изглежда прибавянето, илюстрирано със заявка подадена с инструмента dig:
$ dig @blackhole-1.iana.org -t ns 10.in-addr.arpa ; <<>> DiG 9.3.1 <<>> @blackhole-1.iana.org -t ns 10.in-addr.arpa ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61947 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;10.in-addr.arpa. IN NS ;; ANSWER SECTION: 10.in-addr.arpa. 604800 IN NS blackhole-1.iana.org. 10.in-addr.arpa. 604800 IN NS blackhole-2.iana.org. ;; ADDITIONAL SECTION: blackhole-1.iana.org. 3600 IN A 192.175.48.6 blackhole-2.iana.org. 3600 IN A 192.175.48.42 ;; Query time: 1 msec ;; SERVER: 192.175.48.6#53(192.175.48.6) ;; WHEN: Wed Dec 28 22:06:14 2005 ;; MSG SIZE rcvd: 125
Това облекчение обаче не работи във всички случаи, а само ако кеширащия сървър, който подава заявката и получава нейния отговор е във "forward" режим, т.е. не тръгва от началото на йерархията в DNS (от някой от кореновите (root) сървъри за имена). Тук веднага може да бъде изразена по невнимание една критика към решението, която може да се формулира по следния начин "добре, вие не предлагате кеш услуга, а как тогава искате ние да обявим вашия сървър като приемащ винаги заявките, при насочване на заявките от нас чрез опция "forward" към вас, че да спестим натоварване на сървърите на IANA". Този отговор би могъл да бъде заден само от много невнимателен или некомпетентен администратор на сървъри за имена, който не знае за наличието на зона от тип "forward".
Ето и една подробна дискусия по темата, която да внесе окончателна яснота за това какво всъщност оправдава използването на anycast копия на AS112 из Интернет.
Нека да проследим пътят на заявките за извличане на ресурсни записи от зоните на in-addr.arpa домейните отговорни за адресните пространства за частно ползване без наличие на anycast възли на AS112 в Интернет. Клиентът запитва локалния кеш сървър за извличане (примерно) на PTR ресурсен запис от зоната 10.in-addr.arpa. Нека това е записа 1.2.3.10.in-addr.arpa. Какво ще направи кеш сървъра (приемаме, че той не работи в режим "forward", а е напълно рекурсивен и няма в кеша никаква касаеща извличането на заявката информация). Първоначално ще има запитване към един от кореновите сървъри за имена. Доколкото този сървър няма да знае нищо за 1.2.3.10.in-addr.arpa той ще върне най-близкия в йерархията на системата за имена запис, който се съдържа в зоната на домейна "." (т.нар. "root" зона). Най-близките, от гледна точка на кореновите сървъри за имена, ресурсни записи до PTR записа за 1.2.3.10.in-addr.arpa, са NS ресурсните записи, в които е делегиран домейна 10.in-addr.arpa. Следователно кореновият сървър за имена ще върне недостоверни NS ресурсни записи за домейна 10.in-addr.arpa в следния вид:
;; AUTHORITY SECTION: 10.in-addr.arpa. 86400 IN NS BLACKHOLE-1.IANA.ORG. 10.in-addr.arpa. 86400 IN NS BLACKHOLE-2.IANA.ORG.
Този запис ще живее в кеша на подалия заявката сървър за имена 86400 секунди. Това са обаче недостоверни записи (в пакета с отговор на заявката няма достоверния флаг "AA"). Следователно заявката ще продължи след като бъде намерен достоверен отговор за IP адресите на върнатите сървъри за имена (BLACKHOLE-1.IANA.ORG и BLACKHOLE-2.IANA.ORG). За целта обаче трябва да се направи запитване за извличане на A ресурсен запис от зоната iana.org. За целта обаче отново се преминава през йерархията на системата за имена и последователно през домейна org и iana.org, докато не бъдат намерени A ресурсните записи за BLACKHOLE-1.IANA.ORG и BLACKHOLE-2.IANA.ORG (те са с време на живот 36оо секунди). Чак след това отново се връщаме на доизпълнението на заявката за извличане на PTR записа за 1.2.3.10.in-addr.arpa. Тя вече се адресира към един от двата посочени току що сървъра за имена (по случаен начин се избира единия и към него се изпраща заявката). Той връща отговора на заявката. Но върху тези сървъри за имена единствено зоната 10.in-addr.arpa, в която няма никакви PTR ресурсни записи или субдомейнни делегирания. Следователно ще се върне отрицателен отговор - т.е. няма наличен PTR запис за 1.2.3.10.in-addr.arpa. Заедно с този отговор обаче вече в кеша е натрупана информация както за A записите за BLACKHOLE-1.IANA.ORG и BLACKHOLE-2.IANA.ORG, така и информация за зоната 10.in-addr.arpa. И докато не изтече времето на живот на най-краткоживущия от кешираните записи няма да има нова заявка за тях към кореновите сървъри за имена към сървърите за имена на домейна iana.org. Винаги ще има заявки към домейна iana.org, но в повечето случаи те ще се обслужват от локалния кеш и няма да се следва пътят през йерархията на системата за имена. Т.е. дори заявките към кореновите сървъри да не са много, то тези към домейна iana.org и към BLACKHOLE-1.IANA.ORG и BLACKHOLE-2.IANA.ORG ще са доста и въпреки наличието на кеширане се създава голямо натоварване по направление на споменатите два сървъра за имена. Това натоварване е от гледна точка на глобалната маршрутизация, ако приемем, че няма локални anycast възли на AS112.
Нека сега видим с какво точно облекчава натоварването наличието на локален anycast възел на AS112. Този възел няма как да премахне напълно трафика към сървърите за имена на домейна iana.org. Той обаче може да го намали осезаемо. Наличието му не изменя по никакъв начин схемата на обслужване на заявките, а изменя единствено маршутизацията на пакетите, което е извън обсега на системата за имена в Интернет. Един от механизмите за намаляване на трафика към сървърите за имена на домейна iana.org се основана на една малка хитрина. Нека се върнем малко по-горе, в момента, в който кеш сървъра получи от кореновия сървър за имена ето този недостоверен отговор:
;; AUTHORITY SECTION: 10.in-addr.arpa. 86400 IN NS BLACKHOLE-1.IANA.ORG. 10.in-addr.arpa. 86400 IN NS BLACKHOLE-2.IANA.ORG.
Кеш сървърът ще трябва да намери IP адреса поне на един от сървърите за имена BLACKHOLE-1.IANA.ORG или BLACKHOLE-2.IANA.ORG, за да може от него да получи достоверен отговор. Достоверният отговор изглежда така:
;; ANSWER SECTION: 10.in-addr.arpa. 604800 IN NS blackhole-2.iana.org. 10.in-addr.arpa. 604800 IN NS blackhole-1.iana.org. ;; ADDITIONAL SECTION: blackhole-1.iana.org. 3600 IN A 192.175.48.6 blackhole-2.iana.org. 3600 IN A 192.175.48.42
Следва да се отдели специално внимание на секцията "ADDITIONAL SECTION". По-горе бе указано, че върху anycast възела на AS112 задължително се копира зоната iana.org. От информацията за изпълнението на заявката се вижда с каква цел се извършва това копиране на зоната. При обслужване на заявка от нея се извличат A ресурните записи за blackhole-1.iana.org и blackhole-2.iana.org, и се подават като "прибавени" към отговора на заявката. Какво става когато отговорът се получи в кеш сървъра изпратил заявката? В него има (в общия случай) задължително само единия A ресурсен запис (или този за blackhole-1.iana.org или този за blackhole-2.iana.org), но не са налични и двата. С помощта обаче на "прибавката" към отговора, в кеша влизат и двата A ресурсни записа, но (внимание!!!) с различно време на живот, понеже единият поне е бил вече наличен там. Така се получава една рекурсивна схема, която при чести заявки към in-addr.arpa прави така, че не е нужно да се питат изобщо сървърите за имена на домейна iana.org. Ето по-подробно. Единият A ресурсен запис (този за blackhole-1.iana.org или този за blackhole-2.iana.org) е в повечето случай винаги по-дългоживущ от другия (защото по-рано е дошъл в кеша). Ако той изтече, другият продължава да живее известно време. Ако докато и втория A ресурсен запис живее, постъпи запитване за извличане на запис от in-addr.arpa домейн за пространствата за частно ползване, то с отговора на заявката за извличане на NS записите за конкретния домейн ще дойдат "прибавени" и двата A ресурсни записа (този за blackhole-1.iana.org и този за blackhole-2.iana.org) и така липсващия A ресурсен запис ще бъде набавен. Вижда се, че тази схема е устойчива само при много чести запитвания. Ако запитванията са редки, може и двата A записа да умрат в кеша и да се наложи запитване по йерархията на системата за имена в Интернет.
Накрая може да се посочи, че наличието на AS112 само частично сваля натоварването от сървърите за имена на IANA, долкото пълното му сваляне предполага "forward" режим на подаване на заявките към in-addr.arpa зоните за адресните пространства за частно ползване, който много рядко се реализира от системните администратори, доколкото в случая за тях по-рационално би било те да реализират свое локално решение за AS112 или направо да пропускат заявките в йерархичната схема на извличане в DNS.
Няма обща схема за изграждане на съдържанието на файла named.conf, който се използва от демона named-as112. Най-общото във всички негови реализации е обслужването на заявки за зоните на домейни описани по-горе. Всички те се обявяват спрямо своята роля:"master" или "slave". За зоните на in-addr.arpa домейните се използва следния шаблон:
zone "XYZ.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
където "XYX" замества октетното описание на зоната на in-addr.arpa домейна. Всички дефиции на in-addr.arpa домейни са асоциирани към съдържанието, налично във файла /home/chroots/named-as112/var/named/master/as112. Това улеснение се дължи на универсалната дефиниция на зона за всички тези домейни. Всички зони са свободни за трансфер с цел проверка на съдържанието им от заинтересованите от това интернет потребители.
Зоната на домейна hostname.as112.net се дефинира за обслужване по следния начин:
zone "hostname.as112.net" {
type master;
file "master/hostname.as112.net";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
И тук, трансферът е разрешен - това е публична услуга и всички данни, които не застрашават по някакъв начин услугата, са разрешени за публичен достъп.
Както бе споменато по-горе, върху сървърите за имена, в рамките на проекта AS112, трябва да бъде налична зоната iana.org. Тя би могла да се дефинира в named.conf по следния начин:
zone "iana.org" {
type slave;
file "slave/iana.org";
masters { 192.0.34.126; };
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
С цел откритост към потребителите на AS112, по-долу е публикувано пълното съдътржание на файла named.conf, който демона named-as112 използва:
include "/etc/as112.key";
controls {
inet 192.175.48.1 allow { localhost; } keys { as112; };
inet 192.175.48.6 allow { localhost; } keys { as112; };
inet 192.175.48.42 allow { localhost; } keys { as112; };
};
options {
directory "/var/named";
pid-file none;
statistics-file "/var/named/stats/named-as112.su.stats";
listen-on { 192.175.48.1; 192.175.48.6; 192.175.48.42; };
query-source address 62.44.96.1 port * ;
allow-query { none ; };
};
//logging configuration
logging{
channel "security" {
file "/var/log/named/security.log" versions 16 size 256k;
severity info;
print-severity no;
print-time yes;
print-category yes;
}; //end cannel
channel "queries" {
file "/var/log/named/queries.log" versions 32 size 512k;
severity info;
print-severity no;
print-time yes;
print-category yes;
}; //end cannel
channel "notify" {
file "/var/log/named/notify.log" versions 16 size 256k;
severity info;
print-severity no;
print-time yes;
print-category yes;
}; //end cannel
channel "general" {
file "/var/log/named/general.log" versions 16 size 256k;
severity info;
print-severity no;
print-time yes;
print-category yes;
}; //end cannel
channel "zonetransfer" {
file "/var/log/named/zonetransfer.log" versions 16 size 256k;
severity info;
print-severity no;
print-time yes;
print-category yes;
}; //end cannel
// in file zonetransfer
category "xfer-in" { "zonetransfer"; };
category "xfer-out"{ "zonetransfer"; };
category "update" { "zonetransfer"; };
// in file notify
category "notify"{
"notify";
};
// in file general
category "dispatch" { "general"; };
category "config" { "general"; };
category "general" { "general"; };
category "database" { "general"; };
//in file security
category "security" { "security"; };
category "network" { "security"; };
//in file queries
category "queries" { "queries"; };
category "dispatch" { "queries"; };
};
// end logging conf
// AS112 Project
// running a stealth slave of the IANA.ORG zone so that our servers will return appropriate glue in
their responses
zone "iana.org" {
type slave;
file "slave/iana.org";
masters { 192.0.34.126; };
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "hostname.as112.net" {
type master;
file "master/hostname.as112.net";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "10.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "16.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "17.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "18.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "19.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "20.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "21.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "22.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "23.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "24.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "25.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "26.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "27.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "28.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "29.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "30.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "31.172.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "254.169.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
zone "168.192.in-addr.arpa" {
type master;
file "master/as112";
allow-query { any; };
zone-statistics yes;
allow-transfer { any; };
};
Интересно би било да се направи коментар отновно обявяването на разрешенията за комуникация от страна на rndc. Съгласно описанието, заявки могат да се изпращат до всички използвани адреси от състава на AS112 от rndc процес. Такива обаче се приемат за изпълнение само, ако от гледна точка на демона named-as112 се изпращат от localhost. Това означава, че порта за приемане на rndc заявки е достъпен само от локалния хост и от никъде другаде.
Друг интересен момент е използването на процес на named-as112 без PID файл (pid-file none;). Това е възможно, защото спирането на демона може да става с команда от страна на rndc, а не чрез убиване процеса с даден идентификатор. Това силно отличава демонът на BIND9 от останалите популярни демони в UNIX.
В конфигурационния файл изрично трябва да се укаже на кои адреси демона named-as112 приема заявки за обслужване. Това се налага с цел избягване на дублиране на използването на един и същи адрес от двата работещи в системата демона за реализиране на DNS услуги (виж по-горе особеностите на конкретното решение за реализиране на AS112 в мрежата на Софийския Университет "Св. Климент Охридски"). Конкретнто указване на IP адресите, на които демонът named-as112 слуша, се извършва със следния ред от конфигурационния файл:
listen-on { 192.175.48.1; 192.175.48.6; 192.175.48.42; };
Може би интересения момент е в следното описание:
query-source address 62.44.96.1 port * ;
Този ред има за цел да укаже с какъв IP адрес трябва да се представя демонът named-as112, когато извършва запитвания до други сървъри за имена в Интернет. В този случай подобни запитвания се извършват само при инициране на периодичния трансфер на зоната на домейна iana.org. В дефиницията е указан един от unicast адресите на възела на AS112 в мрежата на СУ (и по-конкретно възела с unicast адрес 62.44.96.1).
Ако това не е така може да се получи проблем. Да си представим какво би станало, ако заявката за зонов трансфер на зоната iana.org бъде иницирана не от името на unicast IP адреса на възела (в горния конфигурационен файл посочен като 62.44.96.1), а от името на някой от разположените върху локалния възел на AS112 anycast адреси, например от 192.175.48.1. Да се поставим за момент на мястото на сървъра за имена, който е достоверен за зоната iana.org и който получава заявката за трансфер. Заявката за трансфер идва от страна на адрес 192.175.48.1. В следващият момент сервиращият зоната iana.org сървър (в посочения по-горе конфигурационен файл, като такъв е използван 192.0.34.126), трябва да върне на заявителя отговор за начало на трансфер. Заявителят обаче е anycast адрес. Тогава пакетът с положителния отговор за съгласие за трансфер с голяма вероятност ще отиде не към истинския заявител, а към най-близкия по маршрут локален възел, който притежава адрес 192.175.48.1. Той обаче едва ли ще е заявителя и няма да знае нищо за началото на трансфера, защото той не е инициран от него. И така заявката за трансфер от страна на оригналния заявител ще пропадне.
В останалата част на конфигурационния файл има все стандартни похвати, които няма смисъл да бъдат обяснявани тук и нямат съществена връзка с AS112.
Ако се следва гореизложения конфигурационен файл 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):
options {
default-server 62.44.96.1;
default-key "named-as5421-su.key";
};
server 127.0.0.1 {
key "named-as5421-su.key";
};
server 62.44.96.1 {
key "named-as5421-su.key";
};
server 192.175.48.1 {
key "as112";
};
server 192.175.48.6 {
key "as112";
};
server 192.175.48.42 {
key "as112";
};
include "/etc/named-as5421-su.key";
include "/etc/as112.key";
Когато се извършва подаване на команда чрез rndc към демона named-as112, то се указва IP адреса, до който се адресира заявката с командата. За да достигне тя до named-as112, трябва да се изпрати към някой от адресите 192.175.48.1, 192.175.48.6 или 192.175.48.42. Изпращането до конкретен IP адрес става чрез опция "-s" придружена от адреса, на който приема заявки демона. Например:
$ rndc -s 192.175.48.1 status
ще изпрати команда за проверка на статуса на демона named-as112 като я адресира до IP адрес 192.175.48.1. Трябва да се отбележи обаче, че ако командния ред се изпълни така:
$ rndc status
то командата за проверка на статуса ще отиде към демона named-as5421, който слуша на IP адрес 62.44.96.1. Причината за това е, че ако не бъде указан IP адрес на сървъра чрез опцията "-s", то командата ще бъде изпратена до този сървър, който е обявен като "default-server" в /etc/rndc.conf.
Ако се следва хода на подобно изложение и добрата практика по администриране на DNS услуги, възниква един въпрос, който може да се формулира като "а защо да не се използва TSIG за подписване на DNS заявките/отговорите от и към AS112, с цел по-добра идентификация на субекта, който предоставя услугата".
Отговорът на този въпрос е "това е невъзможно в условия на динамична маршрутизация на заявките". Причината е, че се работи с anycast базирани системи и сървъри за имена, които в общия случай са неизвестен брой и в тях и няма как да се използва един единствен идентификатор базиран към IP адрес, какъвто е именно HMAC-MD5 ключа при TSIG подписването на заявки/отговори. Няма как да се направи така, че всички anycast възли и всички клиенти, които ги използват да знаят ключа за подписване (който се използва и за проверка на електронния подпис) на заявките/отговорите, защото подобно публично ознаване на ключа обезмисля TSIG схемата, тък като всеки ще знае този ключ и ще може да подписва с него отговорите на заявките. TSIG все още използва HMAC-MD5 със споделен секретен ключ.
Да си представим следния случай. С оператора на най-близкия възел на AS112 е обменен секретен ключ за подписване на заявките и отговорите им в рамките на алгоритъма HMAC-MD5. Сървърът за имена на възела на AS112 приема заявките, проверява електронния подпис върху тях, изпълнява ги и връща отговорите подписани със споделения секретен ключ. Отговора е подписан и проверката върху него се извършва от страна на клиента, чрез локалното копие на обменения секретен ключ. Схемата ще работи до момента, в който динамичната маршрутизация не направи така, че излъчена заявка да попадне върху възел на AS112, който е различен от този, който е споделил секретния ключ с клиента. Заявката, попадайки на този друг възел, или се подписва с друг ключ или въобще не се подписва. Така се получава проблем с проверката на идентичността при подписването и заявката и отговора й пропадат.