Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: restricting AXFR [was: ISC BIND Wildcard filter (Anti VeriSign)]


  • Subject: Re: lug-bg: restricting AXFR [was: ISC BIND Wildcard filter (Anti VeriSign)]
  • From: Hristo Erinin <erinin@xxxxxxxxx>
  • Date: Tue, 21 Oct 2003 17:28:22 +0300
  • Organization: Spectrum NET

Здравей,

Ще се опитам да отговоря само на тези части от писмото ти, които са поне 
малко технически. Надявам се все още да четеш писмата от мен. Ако не 
ги четеш, здраве да е, това е последното ми писмо по темата.

On Mon, 20 Oct 2003 20:16:53 +0300
Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx> wrote:
>
>Никой никъде не е забранявал "wildcard" записи, но направата на "wildcard"

Точно това беше причината да ти пиша първия път. От отговора ти някой 
който не е наясно с подробностите би останал с впечатлението, че wildcard NS
е технически невъзможно да се изпълни. Исках да покажа, че това не е така, 
и причината поради която VeriSign не са го направили все още e политическа.

>Просто не приемам затварянето на зони. По принцип DNS е
>публична услуга. Това не е нещо дето се крие в бункер и до него се дава

AXFR по дефиниция е протокол за обмен на "зонова" информация между два 
сървъра отговорни (authoritative) за дадената "зона". Забраната на AXFR 
не означава, че информацията за тази зона се крие в бункер, тъй като 
крайните клиенти все още имат достъп до нея.

>достъп срещу пропуск. Доколкото това е публична информация, тя не бива 
>да бъде крита. Аз не разбирам какво толкова крият хората по зоналните си
>файлове. Номера на банкови сметки? Пароли? Телефони на любовници?

Мда, паролите отдавна вече не седят в "зоната". Както се изрази навремето 
един мой приятел за изпълнението на горепосочената система -  "distributed 
решение, изпълнено с мисъл, пред което немееш със сълзи на очи" :-))

>избегне изтеглянето на зоната по записи, то за in-addr.arpa всяка зона 
>може да се изтегли запис по запис. Това не само, че е лесно, но и опасно, 
>защото ако един ентусиаст реши да ти тегли in-addr.arpa запис по запис може
>да ти прати такъв порой от заявки, че да ти удари лимита на заявки на DNS
>сървър и той да дава "на заето" от няколко минути до часове. Докато ако
>изтегли зоната като файл по TCP можеш и по-добре да го лимитираш и по-
>добре да менажираш трафика си без ущърб в натоварването на
>UDP канала, който е далеч по-ценен за теб като оператор. Тези неща за
>съжеление малко се разбират, да не кажа не се разбират никак. 

Не виждам как, чрез разрешаване на TCP AXFR, ще спасиш сървъра си от 
DoS. Ако някой реши да прави DoS по UDP, това че има разрешен TCP 
AXFR, няма да го накара да се откаже.

>
>Това, че ти не си чувал за мерките, които взимат IANA и RIPE по въпроса
>е първо твой проблем и после факт достоен за съжеление. Не мисля да си
>губя половин час да обяснявам. Взе да ми писва, честно казано. Само ще

Никой не те кара да губиш каквото и да е време да обясняваш. Много 
съжалявам, че незаинтересуваността ми относно решенията на IANA 
и RIPE те натъжава толкова много. Аз не го намирам за особено голям 
пропуск особено имайки предвид естеството на отговорностите ми. 

>ти обясня, че IANA дадоха благословията си за отваряне на root зоната и
>другите "първи" зони. Това, че само ISC го направиха на своя
>f.root-servers.net е показател за пълния мрак и безпросветност царящ по
>темата "зонови трансфери". От това те само спечелиха. Организацията,
>която практически доведе DNS до днешния му вид по-добре знае кое е
>и кое не е безмислено, си мисля аз. 

IMO ISC са имали някакви основателни съображения да разрешат AXFR на 
зоните обслужвани от f.root-servers.net, но това въобще не означава, че 
е необходимо или задължително да се разреши AXFR на всички NS по 
света.

>Що се касае до RIPE, те направиха така, че всеки регистър, който трансферира
>зоната на своя домейн от първо ниво върху този сървър за обслужване, да
>може да позволи ако иска трансфериране на зоналния файл. Това е факт за

Значи все пак не всички TLD дават AXFR достъп до зоните които се намират 
на сървъри под техен контрол. 

>TLD BG например. За другите зони, собственици на които са RIPE има пълен

Това е интересен пример. ns.ripe.net позволяват AXFR на bg зоната, но за сметка 
на това {ns,ns2}.digsys.bg не го позволяват. Явно Данбо не може да реши какво 
да прави. 

>и безпрепятствен достъп за трансфер. Това са всички in-addr.arpa зони. Можеш
>да си дръпнеш някои от тях:
>
>dig @ns.ripe.net ripe.net AXFR
>dig @ns.ripe.net 62.in-addr.arpa AXFR
>
>и т.н. Сигурно си ужасен?

Грубо. А трябваше ли? Ужасен от командата dig ли?

>Сега стигаме и до SpNet. Както ти предполагам не знаеш има т.нар.
>"domain survey", което се иницира от IANA, ISC, RIPE, ARIN, APNIC и служи
>за броенето на хостовете в домейните на съответните TLD. Това е нещо
>като мярка за броя активни хостове в Интернет. Познай как се отразява
>затвярянето на зоните на броенето. Ти например знаеш ли колко зони на
>домейни има върху ns.spnet.net, хостовете от които не могат да бъдат броени?

Да, знам точния брой: 0. Internet Domain Survey (IDS) не работи с 
AXFR от юли 1997 г. От януари 1998 г. за IDS се ползва PTR RR които не се 
пращат с AXFR. 
А отгоре на всичко, този метод за провеждане на изледването 
е доста по-точен, отколкото стария, пък макар и по-бавен.

>Момент. Ролята на един регистър не е само да следи дали някой си плаща
>за домейна. Ролята на регистъра е все пак да може да преглежда зоните на
>клиентите и при проблеми да ги съветва. Ти може би не си наясно с възможността
>за CNAME рекурсии, която ако възникне (BIND

С тази възможност съм запознат, но не съм запознат със случай в който TLD 
да преглежда, да се грижи за зоните и да съветва клиентите си. Ако беше 
така количеството на Lame Delegations, CNAME "рекурсии" и т.н. щяха да са 
доста по-малко и високата такса за регистриране на .bg домейн щеше да бъде
оправдана.
 
>Ако това се прави ще могат да бъдат избегнати над 40% от lame делегиранията.

Напълно съм съгласен с теб.

>
>Хайде пък сега да не сме били забравяли:) Смешни работи. В зоните на
>накой домейни от първо ниво има и A RR, които не са glue, но не са и
>wildcard. Нали за такива е предвидена exclude опцията при указване на
>root-delegation-only. Хайде да седнем да почетем преди да пишем, а?
>

Нямам нищо напротив. Забравих да напиша "в повечето случаи".

>> >домейни в зоната, в която записа е извършен и тази зона се "изчерпва".
>> >Т.е.
>Ех... Обяснявам подробно и жалко, че не мога да показвам слайдчета за
>да видите това.
>
>Ако направиш "wildcard" NS ресурсен запис това означава, че делегираш
>всички възможни домейни. От тук идва понятието "затворен домейн". Сиреч
>става следното нещо. За който и домейн да попиташ чрез DNS, ти ще
>получаваш отговор, че той е делегиран, защото ще имаш отговор включващ
>неговите DNS записи. Това е тотален spoofing. Изглежда така, че не може
>да се прибави нито един нов домейн, защото той вече ще е делегиран от
>"wildcard" NS RR.
>
>Вярно, в whois базата няма да има тези делегации и регистъра ще може да
>регистрира нов домейн. Мисля, че ако VeriSign направят това обаче, те
>нарушават един основен принцип, а именно whois базата да има пълно
>съответствие с делегациите направени в зоната на TLD домейна. Ако това
>не е така, ICANN имат пълното основание да наредят на IANA, сървърите за
>имена на този регистър да бъдат изтрити от зоната на домена ".". Тогава се
>назначава нов регистър и стария е длъжен да предаде на новия цялата база
>данни за домейна от първо ниво. Това се нарича ре-делегиране на домейн
>от първо ниво.

До тук с нищо не доказа, че "зоната" се изчерпва на практика, а не само на 
теория или политически. Според мен изчерпване означава дали можеш да 
си закупиш домейн и той да бъде делегиран към твой DNS. Нали знаеш, че 
има доста домейни вече делегирани към някого, които всъщност са за 
(пре)продаване.

>Господи:) Всеки ден виждам страшни неща.. и днешния ден не ме подмина без
>страхотии. Би ли ми обаснил как квантовата физика обяснява "черната
>дупка". 

Никога не съм казвал, че го прави. Не обяснява самата черна дупка, а някои 
теории около нея и свойствата 'и. Като например излъчването на 
Хоукинг, което се обяснява с квантовата механика, което пък подкрепя 
теорията, че черните дупки (могат да) изчезват.

>Предоставяш ли си как я пренасям:)))) Просто спирам да ти отговарям и следвам
>политика "DROP"... Пък и никой не те насилва да ползваш нито ISC BIND, нито
>root-delegation-only, нито е нужно да си съгласен с мен, нито е нужно и да
> знаеш що е квантова физика.. 

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

-- 
Best Regards,
Hristo Erinin
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.