Re: lug-bg: интеграция на DNS server и DB server

[Peter Pentchev <roam@xxxxxxxxxxx>]

On Mon, Jun 28, 2004 at 10:43:45PM +0300, Vesselin Kolev wrote:
> Dimitar Katerinski wrote:
> 
> >Po tochno koi RFC dokumenti? I koi imal po-osobena gledna tochka? DJB 
> >li? ;-)
> >Az lichno sym protiw Name server s sql backend, taka stawash zawisim i ot
> >backend-a.
> >
> >DImitar
> >
> >P.S. Ne na 6lokawizata!
> >
> Ами няма никакъв проблем да заформим един як флейм;)

Добре, като ще е флейм, флейм да е :)  Някои от нещата, които казваш, са
съвсем валидни, и са проблеми, и силно се надявам, че DJB ще ги реши в
1.06 (което май все пак ще се появи скоро).  Други... ами не са съвсем
верни за djbdns-1.05, а някои от тях не са били верни от 1.02 насам,
което беше преди три години.  А някои от нещата, които казваш, и редът,
в който си ги изложил, малко ми напомня Frequently Given Answers на
Jonathan De Boyne-Pollard на
http://homepages.tesco.net/~J.deBoynePollard/FGA/djbdns-problems.html
...май е време пак да му драсна един мейл да си обнови страницата, както
направих преди две години :)

> 1) проблеми при компилирането с по-нови версии на libc. Дали го оправиха 
> не знам. Същия проблем го имаше в qmail.

Да, DJB още смята, че това не е проблем, и се оправдава с почти резонния
аргумент, че <errno.h> е заместил 'extern int errno' като официален
стандарт само преди две-три години и се е появил в истински OS дистрибуции
само преди година-две.  Това дори не е вярно :(

Както и да е, това се оправя с едно предефиниране на conf-cc или с едно
бързо минаване по сорсовете с perl -pi или sed -i, но си прав, това може
да бъде auto-detected, както се прави за няколко други неща.

> 2) По едно време скандално списъка с NS хостове за "." беше неверен и 
> несинхронизиран с промените направени от ICANN (да ме извинявате, ама 
> дори Microsoft DNS сървъра имаше кръпка за проблема) (това е също RFC 
> противоречие)

Това май е било доста преди аз да започна да се занимавам с djbdns :)
Или.. може би имаш предвид факта, че ICANN смениха адреса на j наскоро?
Да, DJB не пусна нова версия тогава, но публикува информация какво къде
да бъде сменено.

> Други проблеми (някой от тях доста скандални):
> 
> - dnscache - никакъв кеш на CNAME ресурсни записи (шок и ужас). Това 
> може да вдигне DNS трафика до 5% (имало пач). Дори да се включи насила 
> има репорти за crash.

Хмм.. това трябва да е било преди, в 1.05 няма нищо такова: CNAME's си
се cache-ват съвсем нормално.

> Тук има проблеми с обработката на "lame" делегиранията. (RFC противоречие)

EXPN?  Или това е свързано по някакъв начин с не-кешването на CNAME's?

А, чакай малко... да не би да имаш предвид tinydns, а не dnscache?  Да,
tinydns има един малък проблем с обработка на *верига* от CNAME записи,
т.е. bar CNAME foo, foo CNAME quux, quux CNAME baz, но специално за това
не съм сигурен, че е толкова голям проблем - не е като съвсем да не мога
да си представя ситуация, в която ще има повече от едно ниво на CNAME's
де, има ги определено.  Мда, и това е проблем, и за него си има patch,
който между другото е направен две години след излизането на djbdns-1.05
- през април 2003-та - така че и той има шансове да влезе в 1.06.

(не, не казвам, че това, че има patch отпреди година, е добре - но все
пак виж в края на мейла... не вярвам и ти да не използваш нито едно
парче софтуер, което да няма никакви, ама съвсем никакви local или
third-party patches :)

> - dnscache - не прилага "forward only" - създава възможността външни 
> потребители да правят "proxy loop" като "публикуват" върху сървъра за 
> имена данни за делегации (уж има пач, ама колко процента от 
> потребителите са го приложили?). Искате пример:) Скандалът около домейна 
> aereolineas.com.ar (потърсете в Google). Ето ви poisonous cache:

Вярно, това още е проблем със stock distribution.  DJB напоследък издава
разни звуци, силно наподобяващи развитие по djbdns, та може и скоро да
излезе 1.06, което да го оправи наистина...

> Друг доста сериозен проблем:
> 
> Библиотеката за dns клиентските програми прави нещо доста гадно. Опитайте:
> 
> $ dnsq a cr.yp.to a.ns.yp.to
> 
> Ако името на хоста е свързано към няколко IP адреса, ще има отделно 
> запитване към всеки IP адрес, което е безмислено.

Не съм напълно съгласен, че е безсмислено; dnsq просто се опитва да
провери дали всичките authoritative servers дават една и съща
информация.  Някои хора все още се опитват да правят round-robin дори на
DNS сървърите си без anycast :)

> Тук има третиране на "full stop character" като сепаратор за адреси в
> ${DNSCACHEIP}. Имало пач. Аз лично знам 4 DNS сървъра в България,
> който не са приложили този пач:) Колегиално ли е да кажа кои са те?
> Този бъг може да се използва (при определени ситуации) за спуфинг.
> 
> Малко обяснение. DNS клиентската библиотека има злощастието да разделя 
> задаваните "proxy DNS" сървъри чрез "full stop character", т.е. ".". 
> Представете си какво става като зададете вместо име на хост октетен 
> запис за IP адрес.

Ъъъъъъ.. аз не виждам това като проблем.  В dns_recp.c от djbdns-1.05,
във функцията init(), където е единственото парсване на DNSCACHEIP, след
всяка точка се прави специален опит за ip4_scan(), което намира IP адрес
и си го разпознава прекрасно.  Май наистина е време JdeBP да си обнови
страницата с проблемите :)

> Гордо да кажем, че Djb направи нещо характерно за себе си - отрече доста 
> от проблемите, та се наложи някой друг да пише пачове.

За някои от нещата DJB продължава да отрича, че са проблеми, като
например това с extern int errno и errno.h.  За други обаче вече е
оправил нещата, а трети силно се надяваме всички да оправи във
следващата версия.  И не, djbdns-1.06 не е толкова vaporware, колкото е
qmail 2.0 - наистина вярвам, че djbdns 1.06 ще се появи скоро :)

>    Скромността краси човека.

А иначе за това, че DJB определено има от време на време проблеми с
отношенията с хората, от време на време с признаването на грешките си, и
от време на време с прекалено много приказки за неща, които се чакат от
5-6 години, съм напълно съгласен - това е една от причините никога
изобщо да не съм се абонирал за qmail-листата.  При djbdns обаче, както
и при ezmlm, mess822, cdb, libtai, clockspeed и още пет-шест проектчета,
нещата не са чак толкова зле :)  А за personality problems - *shrug*..
не е първият, няма и да е последният... това поне на мен не ми пречи да
ползвам софтуера, който пише, и да се примирявам с това, че от време на
време трябва да ползвам patches от други хора - м'че то аз самият си
имам кажи-речи 500K patches за FreeBSD, за някои от които е съвсем
сигурно, че няма да влязат в base system съвсем, ама съвсем никога :)

А между другото... не знам дали усети, но само един от проблемите, които
спомена, няма отношение към sqldjbdns, така че като оставим настрана
политическите аргументи, няма причина да не бъде поне изпробвана
sqldjbdns като вариант за решаване на проблема, който започна целия
thread :)))

Поздрави,
Петър

ПП. No hard feelings, I hope? :)  Като ще правим флейм, да правим :)
(олелееее, това нещо започнах да го пиша преди точно един час.. е май е
време вече и да го изпращам, а? :)

-- 
Peter Pentchev	roam@xxxxxxxxxxx    roam@xxxxxxxx    roam@xxxxxxxxxxx
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
"yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation.

Attachment: pgpEZlIICzuXD.pgp
Description: PGP signature