Reverzní záznam

[Míla Kuchta]

Zdravim,

Petr Novotny <Petr.Novotny na antek.cz> napsal:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 30 Aug 2000, at 19:24, Míla Kuchta wrote:
> 
>> Ale kdo Vas nuti cacheovat stroj.jinadomena.cz ma adresu 1.2.3.4, kdyz
>> vy potrebujete uchovat jen informaci o tom, ze www.nejakadomena.cz ma
>> adresu 1.2.3.4, a nedovedu si predstavit proc by v teto souvislosti
>> ten name server lhal. Vy ano?
> 
> Nemusi lhat umyslne; treba jen ma starou verzi te druhe zony. 
> Nakonec, poprve cache poisoning take nastal neumyslne, tak, ze 
> nejaky operator nekam nahral starou zonu s outdated glue.

To chcete rici, ze jeden a ten samy ns bude udrzovat pro kazdou zonu s jejich
dependencema zvlastni cache?

> 
>> > Dosud mi nikdo nerekl, ze by name.server.cz mel byt autoritativni 
>> 
>> A proc to potrebujete vedet? Vy se neptate na www.jinadomena.cz, ale
>> na www.nejakadomena.cz. Pokud by Vas resolver nacachoval informace i o
>> jinadomena.cz, pak uz by zrejme slo o spatnou implementaci.
> 
> Podle RFC 1912 si moje cache _muze_ a _nemusi_ toho 
> additional recordu vsimat. Oboji je spravne chovani. RFC1912 
> explicitne tento druh recordu oznacuje za "least trustworthy".
> 
> Ja osobne jsem pro, aby si resolver kanonicke jmeno opravdu overil 
> pocinaje od zdroje. Opacny postup totiz (mimo jine) svadi k 
> chybam pri implementaci.
> 

Souhlasim, ze je to zbytecne "zesloziteni". Problem je v tom, ze mnoho
soucasnych implementaci si tyto veci resi jaksi "posvem".

>> Jak uz jsem se zminil, tak tento pripad za cache poison nepovazuji.
> 
> A za potencialni cache poison? :-)

Zalezi od implementace. Pokud se to bude chovat jako bind 8.2.2 a vracet
pri CNAME primo A record ciloveho stroje bez ohledu na domenu, tak by urcite
problemy nastat mohly. Na druhou stranu je pravdu ze nevim jak se k temto
zaznamum chova coby resolver.