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

[Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>]

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

> > Интернет. Следвателно горните разсъждения за ISC BIND не се приложими
> > за софтуерите на VeriSign.
>
> Горните разсъждения са валидни само ако говорим за stock ISC BIND. Нека
> не забравяме, че ISC BIND e софтуер с отворен код, и като такъв може да
> бъде променян (и проверката свързана с горното съобщение за грешка
> премахната изцяло).
>

Ех... Добре, ще промениш изходния
код и ще разрешиш NR "wildcard". И какво, ще си пуснеш един локален пачнат
ISC BIND, на който ще се радваш само ти, защото нито една зона с "wildcard"
NS RR няма да трансферира върху друг сървър за имена, защото парсера на
тансфериращия сървър ще откаже обслужване като види такова нещо... Е, ако
всичките ти сървъри за имена на домейна ти са си твои и зоните им никой не
вижда (сиреч не може де се изпълни AXFR) може и номера ти да мине... ама за
другаде едва ли ще мине. SpNet имат дългогодишен опит в криене на зони чрез
забрана на трансфер, между впрочем.

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

ISC пуснаха зоната на "." нарочно свободна за трансфер, за да може първо
всеки, който поиска да си прави anycast огледало и второ за да може всеки да
гледа зоната за да няма в нея "паразити". RIPE върху ns.ripe.net отвориха
всички зони за трансфер за да може да има оглед върху всяка една от тях.
Тези неща не се правят случайно. Взаимния контрол е най-добрата предпоставка
за намаляване на проблемите в системата за имена.

> > Аз не мога да кажа със 100% сигурност дали VeriSign няма да направят
> > "wildcard" NS ресурсни записи. Ако те направят това обаче, те ще трябва
> > (ВНИМАНИЕ в тънкия момент) да делегират всички визможни домейни, което
>
> Добавянето на NS запис не е ли делегиране само по себе си?

Тук или не си прочел внимателно, или не си разбрал. Добавянето на NS RR
винаги е делегиране. То и затова са направени тези ресурсни записи. Но ако
направиш "wildcard" NS RR, ти напрактика делегираш безброй много домейни.
Причината е в свойството на "wildcard" записа "да бъде всичко, което иначе
не е делегирано". Т.е. ако направиш "wildcard" NS RR ти създаваш безброй много
домейни в зоната, в която записа е извършен и тази зона се "изчерпва". Т.е.
в нея има всякакво име на домейн, за което се сетиш и няма свободни,
незаети имена. Т.е. който го направи си прави зоната едно безкрайно голямо
и затворено множество от домейни и се затваря като черна дупка -малко
аналогията е непълна, щото няма гравитационен колапс, нито радиус на
Шварцшилд, нито хоризонт на събитията:))))) но в този късен час и при тази
умора друго на ми дойде на главата.

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

  Поздрави
    Весо
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/kC+w+48lZPXaa+MRAs2TAKD/d0oOg5mQAr3uiHQZLQdZXeQ7JACeNpqb
HY0HLVnPpTJYKmVYHBmDVio=
=ymE6
-----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
============================================================================