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

[Dimitar Katerinski <train@xxxxxxx>]

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!
Здравей,
> Ами няма никакъв проблем да заформим един як флейм;)
Не, не обичам флеймове. На кой DNS сървъра бил по хубав, на кой SMTP-то,
коя дистрибуция била по хубава и т.н. глупости.
>
> 1) проблеми при компилирането с по-нови версии на libc. Дали го оправиха 
> не знам. Същия проблем го имаше в qmail.
Оправен е, би трябвало да знаеш, както с qmail така и с djbdns. Решаването
на проблема беше тривиално, просто заменяш "extern int errno;" с
"#include <errno.h>. Както и да е, на който му се е занимавало се е поинтересувал.

> 2) По едно време скандално списъка с NS хостове за "." беше неверен и 
> несинхронизиран с промените направени от ICANN (да ме извинявате, ама 
> дори Microsoft DNS сървъра имаше кръпка за проблема) (това е също RFC 
> противоречие)
Навярно говориш за списъка с root сървъри или файла /var/dnscache/root/servers/\@ или
още известен като /etc/dnsroots.global. Ако е така, може би знаеш че е задължение на
администратора, да синхронизира този списък с актуални от ftp://rs.internic.net/domain/ .

> Други проблеми (някой от тях доста скандални):
>
> - dnscache - никакъв кеш на CNAME ресурсни записи (шок и ужас). Това 
> може да вдигне DNS трафика до 5% (имало пач). Дори да се включи насила 
> има репорти за crash. Тук има проблеми с обработката на "lame" 
> делегиранията. (RFC противоречие)
Относно CNAME записите, ще постна обяснението на DJB (вместо да се
правя на доста умен, и да разкажа с мои думи това което той или някои друг
е казал).
"Say a cache is looking for information on www.espn.tv. If it encounters a
CNAME record for www.espn.tv pointing to www.espn.go.com, it is supposed to
start over again, looking for the same information on www.espn.go.com.
www.espn.tv is an alias for www.espn.go.com. RFC 1034 says that an alias
``should'' not point to another alias. In reality, however, if an administrator
decides to set up www.espn.go.com as an alias for espn.go.com, he probably won't
remember to change www.espn.tv---but users will kick and scream if www.espn.tv breaks.
``CNAME chains should be followed,'' RFC 1034 says.Aliases, like gluelessness, force
DNS clients to chew up time and memory."

Ta ако администратора направил еди каква си грешка, щяло да стане еди що си, па и рам
и цпу щяло да иде :). Иди сега разбери ти ли си прав, или той. И ти говориш за повишаване
на DNS трафика ...
Относно lame делегиранията, нямам какво да кажа тъй като ще говоря наизуст. Въпрос, BIND
спазва ли всички RFC, щом ще се уповаваме на тях?

> - dnscache - не прилага "forward only" - създава възможността външни 
> потребители да правят "proxy loop" като "публикуват" върху сървъра за 
> имена данни за делегации (уж има пач, ама колко процента от 
> потребителите са го приложили?). Искате пример:) Скандалът около домейна 
> aereolineas.com.ar (потърсете в Google). Ето ви poisonous cache:
> aereolineas.com.ar. IN NS ns1.aereolineas.com.ar.
> aereolineas.com.ar. IN NS ns2.aereolineas.com.ar.
> ns1.aereolineas.com.ar. IN A 127.0.0.1
> ns2.aereolineas.com.ar. IN A 127.0.0.2
dnscache прилага forward only"
echo 1.2.3.4 > /var/dnscache/root/servers/\@
echo FORWARDONLY > /var/dnscache/env/FORWARDONLY

> Много е мило нали:))))) Проблема съм го виждал върху 2 сървъра в 
> българското интернет пространство. За единият предупредих администрара 
> му. Минаха 7 месеца:) още е така.
Невежеството и незаинтересуваността са лошо нещо ;-) Някои хора например все
още обожават RedHat 7.3.

> Друг доста сериозен проблем:
>
> Библиотеката за dns клиентските програми прави нещо доста гадно. Опитайте:
>
> $ dnsq a cr.yp.to a.ns.yp.to
>
> Ако името на хоста е свързано към няколко IP адреса, ще има отделно 
> запитване към всеки IP адрес, което е безмислено. Тук има третиране на 
> "full stop character" като сепаратор за адреси в ${DNSCACHEIP}. Имало 
> пач. Аз лично знам 4 DNS сървъра в България, който не са приложили този 
> пач:) Колегиално ли е да кажа кои са те? Този бъг може да се използва 
> (при определени ситуации) за спуфинг.
Аз лично знам още 5. За хората които се чудят какво си искал да кажеш с горното
твърдение ще поясня (понеже трябваше да го прочета на английски за да го осъзная)
dnsq е нещо като dig. Отправяш dns query за даден тип запис, на даден domain или
hostname към опрделен NS сървър.
dnsq <type> <domainname> <name server>
Та ако си бил сетнал няколко <name server>s w ${DNSCACHEIP}, щото то позволява,
щяло да стане горния фал. Въпрос, ти като имаш name server, по цял ден си играеш
с dnsq, или оставяш tinydns да си върши работата?
> Малко обяснение. DNS клиентската библиотека има злощастието да разделя 
> задаваните "proxy DNS" сървъри чрез "full stop character", т.е. ".". 
> Представете си какво става като зададете вместо име на хост октетен 
> запис за IP адрес.
> Гордо да кажем, че Djb направи нещо характерно за себе си - отрече доста 
> от проблемите, та се наложи някой друг да пише пачове.
Колкото е мразен, толкова е и обичан DJB. Мразен заради арогантността си, заради това
че смее да коментира група брадати хипита начело с Paul Vixie (начело на ISC и забележете
Vixie Enterprises). Лично се възхищавам на такива хора. А колкото до софтуера, планирам да
мигрирам към postfix и BIND ;-), поради лични причини. А да забравих ли да спомена и кофти
лиценза, и това че е отебал да си ъпдейтва нещата. Най-малкото е показал как трябва да се
правят нещата (както казва един колега), или че сегашният ред си има и проблеми (всички сме
чували за BIND нали?).

>    Скромността краси човека.
Това майка ми, ми го разправяше навремето, взех че и повярвах :).
>       Весо
И пак, повтарям, след всичките ми писания по-горе, не искам флейм.

Димитър

P.S. Ne na 6lokawizata!
P.S.1 За пълен списък с проблемите на djbdns, общо 7 на брой, в оригинален текст на английски,
всички могат да прочетат на http://homepages.tesco.net/~J.deBoynePollard/FGA/djbdns-problems.html
P.S.2 Превода ти се разминава на някои места :) No offence.


--
"The only thing necessary for the triumph of evil is for good men to do nothing."
                                                  --Edmund Burke.
============================================================================
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
============================================================================