Re: lug-bg: ISC BIND Wildcard filter (Anti VeriSign)

[Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> Забравяш, че ISC BIND не е единственият DNS софтуер. Доколкото знам няма
> стандарт който да забранява wildcard NS записи. Има още доста
> имплементации, всяка от които може да са решили въпроса с wildcard
> записите по различен начин. От оригиналното ти писмо човек остава с
> впечатлението, че е технически невъзможно да се създаде wildcard NS
> запис.
> На какво дължа хапливия тон на отговора ти? Целта на писмото ми
> беше да покажа някои грешки в твоето, не да се заяждаме.
>

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

Никой никъде не е забранявал "wildcard" записи, но направата на "wildcard"
 записи в зона, в която трябва по дефиниция да има само делегиращи записи 
се нарича "spoofing". Именно за това беше и толкова гневна реакцията на
всички по темата VeriSign. Всички регистри са наясно с това защо не бива да
се правят подобни неща. Мисля, че се изписаха магабайти по въпроса защо
подобни записи са опасни. Не мисля пак да давам обяснения.

Друго нещо. Не мисля, че съм се заяждал. Когато го правя съм далеч по хаплив.

> >другаде едва ли ще мине. SpNet имат дългогодишен опит в криене на зони
> >чрез забрана на трансфер, между впрочем.
>
> А това от къде изскочи? Имаш непоносимост към някои интернет доставчици,
> или просто в момента се сети за този факт? Доколкото знам няма изискване
> AXFR да е разрешен за клиенти които не са отговорни за даден домайн.
> Това е избор който се прави от човека отговорен за даден DNS сървър.
>

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

Единствените зони, за които досега има доказана необходимост да не бъдат
изтегляни свободно, са зоните на DNS базираните спам листи. Съсвем ясно е, 
че ако може да бъде изтеглена зона, която съдържа лист с хостове или IP 
адреси на "open relay" SMTP сървъри и т.н., това би било безценен подарък за 
всеки спамър. За другите зони още никой не е доказал подобно нещо. Докато за
домейните в gTLD и ccTLD и техните поддомейни, донякъде може да се 
избегне изтеглянето на зоната по записи, то за in-addr.arpa всяка зона 
може да се изтегли запис по запис. Това не само, че е лесно, но и опасно, 
защото ако един ентусиаст реши да ти тегли in-addr.arpa запис по запис може
да ти прати такъв порой от заявки, че да ти удари лимита на заявки на DNS
сървър и той да дава "на заето" от няколко минути до часове. Докато ако
изтегли зоната като файл по TCP можеш и по-добре да го лимитираш и по-
добре да менажираш трафика си без ущърб в натоварването на
UDP канала, който е далеч по-ценен за теб като оператор. Тези неща за
съжеление малко се разбират, да не кажа не се разбират никак. 

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

> >Освен това IANA и RIPE отдавна тръбят да се разреши зоналния трансфер,
> >че да може да се следи синтаксиса на зоналните файлове и да се следят
> >подобни"бози". VeriSign и досега не разрешават трансфер на зоните на
> >COM и NET. То и как ще разрешат, като зона на съществува. Никой никъде
> >не е виждал сорса на техните TLD.
>
> И продължаваме по темата... Не съм чувал за тръбенето на IANA и RIPE
> досега и съответно не съм запознат със съображенията им, но ако са
> описаните по-горе от теб, то те са напълно безсмислени. Следенето на
> синтаксиса на "зоновите файлове" (ами ако в един файл има няколко
> "зони"? или е RDBMS?) е работа на DNS администратора или собственика на
> даден домейн. 

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

Що се касае до RIPE, те направиха така, че всеки регистър, който трансферира
зоната на своя домейн от първо ниво върху този сървър за обслужване, да
може да позволи ако иска трансфериране на зоналния файл. Това е факт за
TLD BG например. За другите зони, собственици на които са RIPE има пълен
и безпрепятствен достъп за трансфер. Това са всички in-addr.arpa зони. Можеш
да си дръпнеш някои от тях:

dig @ns.ripe.net ripe.net AXFR
dig @ns.ripe.net 62.in-addr.arpa AXFR

и т.н. Сигурно си ужасен?

Alter също предоставиха зоната си за свободен трансфер:

dig @auth60.ns.uu.net alter.net AXFR

и доста други хора.


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

> Не виждам по какъв начин "peer review" ще спомогне за
> работата на даден домейн, когато peer-ите нямат възможност да
> отстраняват грешките сами. Освен това не виждам по какъв начин
> некоректно конфигуриран домейн/сървър може да попречи на функционирането
> на някой друг домейн/сървър.

Момент. Ролята на един регистър не е само да следи дали някой си плаща
за домейна. Ролята на регистъра е все пак да може да преглежда зоните на
клиентите и при проблеми да ги съветва. Ти може би не си наясно с възможността
за CNAME рекурсии, която ако възникне (BIND
има възможност да избягва подобни рекурси до някъде),може
да доведе до "flood" и единствената възможност да бъде спрян е временно 
регистъра да суспендира делегирането на домейна. За да може регистъра да
 наблюдава за проблеми, той трябва да може да парсира зоналните файлове.
Ако това се прави ще могат да бъдат избегнати над 40% от lame делегиранията.

Трансферирането на зоните на клиентите върху сървърите за имена на регистъра
може да ускори с пъти обслужването на заявките. Регистър.БГ преди го беше
предложил. И само така си остана, щото никой не иска да дава трансфер.

>
> Разбира се, ако говорим за TLDA тогава "peer review" придобива малко
> по-различен смисъл и аз съм съгласен, че е полезен, но ти говориш за
> SpNet, нали така? Нека не забравяме, че в "зоновите файлове" на
> съответното TLDA няма нищо друго освен NS и glue записи, за разлика от
> някой DNS сървър от 2-ро, 3-то и т.н. нива.
>

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

>
> До тук съм съгласен с теоретичната част, но...
>
> >домейни в зоната, в която записа е извършен и тази зона се "изчерпва".
> >Т.е.
>
> ... тук не говориш сериозно нали? Искаш да кажеш, че VeriSign или което
> и да е друго TLDA след това няма да могат да различат дали един домейн е
> регистриран или не, и съответно дали могат да ти го продадат или не?
>

Ех... Обяснявам подробно и жалко, че не мога да показвам слайдчета за
да видите това.

Ако направиш "wildcard" NS ресурсен запис това означава, че делегираш
всички възможни домейни. От тук идва понятието "затворен домейн". Сиреч
става следното нещо. За който и домейн да попиташ чрез DNS, ти ще
получаваш отговор, че той е делегиран, защото ще имаш отговор включващ
неговите DNS записи. Това е тотален spoofing. Изглежда така, че не може
да се прибави нито един нов домейн, защото той вече ще е делегиран от
"wildcard" NS RR.

Вярно, в whois базата няма да има тези делегации и регистъра ще може да
регистрира нов домейн. Мисля, че ако VeriSign направят това обаче, те
нарушават един основен принцип, а именно whois базата да има пълно
съответствие с делегациите направени в зоната на TLD домейна. Ако това
не е така, ICANN имат пълното основание да наредят на IANA, сървърите за
имена на този регистър да бъдат изтрити от зоната на домена ".". Тогава се
назначава нов регистър и стария е длъжен да предаде на новия цялата база
данни за домейна от първо ниво. Това се нарича ре-делегиране на домейн
от първо ниво.

>
> Философски и строго далечно-научно-отнесено теоретично погледнато може,
> и да има някаква бегла прилика с черните дупки, но практически, и малко
> по-свързано с реалността теоретично погледнато, wildcard NS записът няма
> НИЩО общо с черните дупки. С други думи примерът който си дал е напълно
> неподходящ ;-). Късния час е лош съветник. Никога не съм предполагал, че
> квантовата физика и Общата Теория на Относителността ще ми бъдат полезни
> при четене на LUG-BG. :)

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

> Не я лъжем ти и аз, а VeriSign, но иначе си прав и съм съгласен с теб.
>
> Все още се чудя на какво дължа хапливия и заядлив тон на съобщението ти.
> Не смятам че в LUG-BG има място за подобен род кореспонденция. Ако
> държиш да запазиш тона си ще те помоля да пренесем дискусията си извън
> групата.

Предоставяш ли си как я пренасям:)))) Просто спирам да ти отговарям и следвам
политика "DROP"... Пък и никой не те насилва да ползваш нито ISC BIND, нито
root-delegation-only, нито е нужно да си съгласен с мен, нито е нужно и да
 знаеш що е квантова физика.. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/lBiM+48lZPXaa+MRAmP9AJ9Qh18mHRed7Wi5nKi2EFWedHVW4ACfZkAZ
fLSu1vlxXJRF0Oa8Lp/om7Y=
=pEOW
-----END PGP SIGNATURE-----

============================================================================
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
============================================================================