Уважаеми господин Ганчев,
Знам, че Вие сте най-добрият интернет специалист в България. Поне така Ви титулова г-н Вени Марковски. Интересно как един мениджър е успял така добре да Ви опознае като специалист. Сигурно Вие сте му казали това.

Накратко, lame delegation, уважаеми г-н Ганчев изобщо няма нищо общо с начина на хостване. Много съм изненадан, че вие не знаете такива елементатни неща (справка: Google, keywords: DNS +lame delegation). Lame делегирането е състояние на зоната на даден домейн и се изразява в това, че сървър, който е посочен за достоверен (ауторитативен) за даденият домейн не връща достоверни (ауторитативни отговори) за ресурсните записи от зоната на домейна. Казано по технически, в DNS пакета, който е отговор на заявката не е вдигнат aa бита. Причините, поради които може да се получи lame делегиране, уважаеми г-н Ганчев, са главно две. Едната е, че въпросният сървър за имена е прекратил трансфера на зоната за домейна bol.bg (и например тя е остаряла спрямо посочените в SOA записи времена за това). Тогава този сървър ще продължава да дава отговори на заявките за извличане на ресурсни записи от зоната за домейна само (забележете това), ако този сървър за имена е вкаран в режим на всеобща публична рекурсия. Т.е. всеки IP адрес от Интернет може да изпрати за изпълнение рекурсивна заявка върху този сървър за извличане на RR запис от зоната на BOL.BG и той да даде отговор като попита не себе си, а един от нормално работещите сървъри за имена за домейна bol.bg. Все едно всеки клиент може да ползва този сървър като forward.

Втората причина, поради която един сървър за имена може да е делгирал върху себе си lame една зона на домейн, е ако той въобще не е изтеглял зоната. Например, направена е прясна инсталация на OS и някой е забравил да направи правилната конфигурация във файла /etc/named.conf (знам, че използвате ISC BIND и затова споменавам този файл). След това ефекта е същия както описания по-горе. Пак да повторя, ако този сървър за имена е указан като достоверен за даден домейн, той ще дава отговори за записи от зоната на домейна само, ако е въведен в режим на публична рекурсия.

За да хване човек една подобна издънка е необходимо да направи малко по-усъвършенствани настройки в своя BIND). Първо се дефинира канал в секцията logging на файла /etc/named.conf:

channel LAMER_log {
file "/var/log/named/dns-lamer.log" versions 3 size 10m;
severity info; # only send priority info and higher
print-severity yes; print-time yes;
};

а след това се описва и категория:

category lame-servers { LAMER_log; };

След едно свежо rndc reconfig, BIND ще започне да описва lame делегираните домейни във файла /var/log/named/dns-lame.log. Разбира се, това описание ще бъде правено само за домейните, записи за който BIND е обработвал.

Та какво показва този журнален файл /var/log/named/dns-lame.log за домейна BOL.BG:

Aug 16 14:27:10.130 info: lame server resolving 'free2.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Aug 16 14:27:10.139 info: lame server resolving 'free2.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Aug 25 16:57:31.538 info: lame server resolving 'virtual-mail.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Aug 25 16:57:31.552 info: lame server resolving 'virtual-mail.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Sep 04 12:49:57.539 info: lame server resolving 'free1.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Sep 04 12:49:57.596 info: lame server resolving 'free1.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Sep 09 13:39:16.942 info: lame server resolving 'spider.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Sep 09 13:39:16.992 info: lame server resolving 'spider.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Sep 09 21:20:05.766 info: lame server resolving 'irc.bol.bg' (in 'bol.bg'?): 193.200.15.133#53
Sep 09 21:20:05.788 info: lame server resolving 'irc.bol.bg' (in 'bol.bg'?): 193.200.15.133#53


След проверка с инструмента dig (ако не знаете г-н Ганчев, nslookup не се препоръчва за използване и следва употребата му да отпадне за сметка на използването на host и dig) се оказа, че ns.isoc.bg и ns.cit.net не дават достоверни отговори за домейна BOL.BG. Явлението бе дискутирано по доста linux и net форуми по това време. Просто явно Вие не следите тези неща, защото сигурно сте много зает. За това бяха предупредени и някои членове на ICANN в чужбина. Когато започнете да говорите за процедура за ределегиране на TLD BG, тези неща ще Ви бъдат припомнени и то съвсем не от българи.

Понеже имате претенции да сте достатъчно квалифициран, сега ще Ви покажа нещо, което бе давано за пример в различни форуми за пълно неразбиране по въпросите на DNS. Нека да покажем указаните в зоналния файл на домейна BOL.BG направените за него NS ресурсни записи:

;; ANSWER SECTION:
bol.bg. 3600 IN NS ns.isoc.bg.
bol.bg. 3600 IN NS ns.bol.bg.
bol.bg. 3600 IN NS ns.cit.net.

;; ADDITIONAL SECTION:
ns.isoc.bg. 3600 IN A 193.200.15.133
ns.bol.bg. 3600 IN A 193.200.15.129
ns.cit.net. 3600 IN A 193.200.15.133

Да ме прощавате г-н Ганчев, но това, което се вижда, по административно му се нарича "раздуване на щата". Както лесно се забелязва, ns.isoc.bg и ns.cit.net са един и същи сървър за имена, даже със 100% сигурност може да се каже, че имат и един и същ файл /etc/named.conf. (Все още г-н Ганчев, няма създаден виртуален хостинг, при който един сървър за имена да се представя за повече от един (както е при Web) и това е заради протокола използван за DNS. Причината е структурата на запитването. В нея никъде няма хедър, който да изисква отговора да бъде върнат точно от определено име на хост, както става например в рамките на HTTP заявките при Apache). Хайде сега да обясним, че ако по някаква причина достъпа до 193.200.15.133 бъде прекратен, едновременно ще отпаднат два от сървърите за имена за домейна BOL.BG. Това значи, че със същия успех можете да махнете един от повтарящите се сървъри за имена и това нищо няма да промени. Пита се, защо това е така?

И накрая, никак не мисля, че Вие сте този, който може да има въобще някакви претенции към управлението на TLD BG. Защото при така блянуваната от страна на лицето Марковски ределегация, със сигурност Вие ще бъдете натоварен да обслужвате технически TLD. Разбира се, отново по линия на поредна фондация, организация, мисловен кръг (Вие броите ли ги изобщо колко са станали тези креатури?). Ако направите подобен повтарящ се NS RR, ще Ви се смее целия Интернет! А след едномесечна lame делегация ще се започне нова процедура по ределегиране.


Що се касае до подадена молба или заявка в Регистъра за смяна на записи в зоната .bg за домейна BOL.BG. Е как може на всички други молбите да се изпълняват до 72 часа (най-много), а вашите не?

И накрая, хайде недейте да се самотитуловате. Защото аз, който съм пълен лаик в състемната администрация, успявам да видя Ваши грешки, които и лаик не би допуснал.

Желая Ви приатен ден, г-н Ганчев и най-големи творчески успехи!