DNS etc.

[Pavel Kankovsky]

On Thu, 6 Apr 2000, Petr Novotny wrote:

> A je string delky CACHE_ELEMENT_MAX_LENGTH dost velky, 
> aby se do nej dal zkopirovat string delky 
> MAX_INPUT_LINE_LENGTH?

Jsou hrusky dost velke, aby se daly pouzit misto jablek? :)

> Mate priklad neceho, co je architektonicky vybudovano jinak, nebo 
> jen spekulujete? (Jen se ptam.)

Pokud chcete neco blizkeho realite, tak si treba predstavte Dents, kde
jsou nektere moduly vytazene do jineho procesu. Hmm...nebo by slo udelat
"frontend", co by proste preposilal dotazy i odpovedi. To by vlastne
fungovalo i s neupravenym tinydns & dnscache, akorat bude problem v tom,
ze nebude mit smysl nic psat do logu (stejne by tam byla jen adresa
frontendu).

(BTW: stejne mi pripada, ze adresovaci schema <IP, port> je pekne blbe,
mnohem lepsi by bylo <IP, sluzba, instance sluzby>).

> > Transparent proxy se ale s UDP moc neda pouzit.
> Tak si ho napisu. (Prijimam UDP pakety, a podle tabulky je 
> "forwarduju" na jine porty tehoz interface.)

Hm? Tim je mineno neco jako vyse popsany frontend?

> > Oprava: o nekterych programech lze dokazat, ze maji nektere
> > vlastnosti. (Tim nechci zpochybnovat vhodnost formalnich metod, ale
> > nejsou vsemocne.)
> 
> Zalezi na tom, v jakem smyslu myslite vsemocnost. Samozrejme 
> je zname ono fousate "Nelze napsat program, ktery ma za vstup 
> libovolny program a za vystup odpoved, zda je ten zkoumany 
> program spravne". Ovsem je dosti zrejme, ze my zde nepracujeme 
> s libovolnym programem. Pracujeme s konkretnim programem, a 
> spravnost/nespravnost lze dokazat. (Pravda, pokud bychom meli 
> smulu, tak nam to akorat trva strasne dlouho.)

1. Jak spravne poznamenal kolega Mares, spravnost lze posuzovat pouze
relativne. 2. Vzdycky muze byt tvrzeni, ze DANY program ma DANOU vlastnost
v prislusne teorii nerozhodnutelne (diky panu Godelovi vime, ze vsechny
zajimave teorie jsou neuplne)...pak nelze dukaz, ani dukaz opaku, najit
nikdy. (Ovsem podle marxismu-leninismu je vzdy aspon mozno zjistit, ze
ten dukaz nelze najit. :> )

> Jinak receno, pridavat chyby se zduvodnenim "treba je spatne 
> kernel" je nebezpecna cesta.

Rozdeleni sluzeb do samostatnych jednotek neni otazka spravnosti ci
chybnosti, ale softwaroveho inzenyrstvi a rizeni rizik, pricemz oboje
ma dost daleko do exaktni vedy. :)

> > Krome toho, jestlize se mistni resolvery na vsechno (vcetne lokalne
> > obsluhovanych zon) dotazuji pres kes (coz je AFAIK djb-approved modus
> > operandi), pak je naruseni bezpecnosti kese z pohledu lokalnich
> > uzivatelu nejmene tak zavazne, jako naruseni bezpecnosti mistniho aut.
> > ns.
> 
> Z pohledu LAN ano. Z pohledu zakaznika zvenci ne. Rekl bych, ze 
> zamestnancum amazon.com az tak vadit nebude, kdyz nebudou 
> moct browsit kvuli otrave lokalni cache - hlavne ze bude 
> www.amazon.com ukazovat na spravne misto pro zbytek sveta.

Zbytek sveta ma svoji vlastni cache. Je ovsem pravda, ze cache lze z jedne
strany proti neprizni pocasi ochranit.

> (Na druhe strane vam bude asi vadit, kdyz kvuli otrave lokalni 
> cache odvysilate cislo sve kreditkarty nekomu jinemu. Ale 
> kontrolujete, zda nahodou neklikate na www.anazon.com?)

V US na to vsichni s..., protoze jim banka ty penize musi vratit (kdyz
nedokaze, ze si je zdefraudovali sami).

> Jinak mate samozrejme pravdu. Jenze IPSec uz je, a vsechny 
> slusne OS ho umeji. DNSSEC je porad ve stadiu hibernace.

Na co vubec DNSSEC a ne DNS over IPSec?

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."