Re: lug-bg: mail.bg, abv.bg etc..

[alex@email.domain.hidden (Alexander Atanasov)]

        Zdrasti,

On Wed, 16 Apr 2003 10:53:38 +0300
Vesselin Kolev <vlk_at_lcpe.uni-sofia.bg> wrote:

<em class="quotelev1">> -----BEGIN PGP SIGNED MESSAGE-----
<em class="quotelev1">> Hash: SHA1
<em class="quotelev1">> 
<em class="quotelev1">> 
<em class="quotelev1">> Mnogo zhalko, che e nelogichno za teb. Sega shte ti obiasnia zashto e
<em class="quotelev1">> logichno. Viarno, niama da e na kratko.
<em class="quotelev1">> 
<em class="quotelev1">> Pyrvo malko obiasnenia za mehanizma na izvlichane na A RR predshestvan
<em class="quotelev1">> ot CNAME. Mnogo e zhalko, che tozi mehanizym masovo ne se znae, dori
<em class="quotelev1">> poniakoga se iadosvam ot tozi fact!
<em class="quotelev1">> 
<em class="quotelev1">> Spored men triabva po reklamnite pana po krystovishtata i po reklamite
<em class="quotelev1">> po televiziata da se nabiva na horata, che izvlichaneto na IP adres za
<em class="quotelev1">> host, ukazan s CNAME vodi do izvyrshvaneto na DVE zaiavki i to v
<em class="quotelev1">> idealizirania suchai! 

        Ne , samo v kraen sluchai stava tova.
<em class="quotelev1">> 
<em class="quotelev1">> Vnimanie sega. Eto shemata taka, kakto shte ia izpylni bibliotekata na
<em class="quotelev1">> 
<em class="quotelev1">> resolvera. Tyrsi se IP adresa na hosta example.domain.dom. V zonata na
<em class="quotelev1">> domaina domain.dom e napraveno slednoto opisanie
<em class="quotelev1">> 
<em class="quotelev1">> $ORIGIN domain.dom.
<em class="quotelev1">> example   CNAME   host-1
<em class="quotelev1">> host-1   A   192.168.0.44
<em class="quotelev1">> 
<em class="quotelev1">> Resolvera pyrvo shte potyrsi zapis za example.domain.dom. Shte mu byde
<em class="quotelev1">> vyrnat CNAME host-1. Posle resolvera (vnimanie v tozi moment!!!) shte
<em class="quotelev1">> napravi zapitvane za host-1.domain.dom i chak togava shte mu byde 
<em class="quotelev1">> vyrnat IP adresa.
<em class="quotelev1">> 
<em class="quotelev1">> Po-gore govorih za idealiziran sluchai. E, ta idealizirania sluchai e
<em class="quotelev1">> tozi,
<em class="quotelev1">>  pri koito i CNAME i A resursnite zapisi sa napraveni v edna i syshta
<em class="quotelev1">>  zona.

        Reslovera prashta kum server query za type A RR, dns server-a spored RFC-to triabva
mu otgovori s A RRs, v paketa koito se poluchava obratno ot server-a ima 3 sekcii:
Answer, Authority i Aditional.

dig cname.domai.com A
v answer sekciata idvat:
cname.domain.com.         300     IN      CNAME   host.domain.com.
host.domain.com.        300     IN      A       1.2.3.4

ako se pita za cname, niama da doide A RR, server-a po jelanie moje da go sloji v aditional.
T.e. resolver-a kato client s edno query si poluchava zapisa, nishto che e cname.
V server-a syotvetno pak ima edin lookup v zonata dobria sluchai, moje i dva no edva li.

        
<em class="quotelev1">> Neidealniat sluchai vkliuchva v sebe si CNAME, sochesht kym A RR
<em class="quotelev1">> zapis v druga zona! Eto primer:
<em class="quotelev1">> 
<em class="quotelev1">> $ORIGIN domain.dom.
<em class="quotelev1">> example CNAME host-1.other-domain.dom.
<em class="quotelev1">> 
<em class="quotelev1">> V zonata na drugia domain se pravi pyk opisanieto na A RR.
<em class="quotelev1">> 
<em class="quotelev1">> $ORIGIN other-donain.dom.
<em class="quotelev1">> host-1  A  192.168.0.33
<em class="quotelev1">> 

        Tuk variantite sa 2:
1. ako edin server obslujva i dvete zoni, v reply mogat da doidat
i CNAME i A RRs, ne pomnia kogato beshe druga zonata kum koiato sochi 
cname dali se prashtashe v Answer ili v Aditional, no resultata pak
se poluchava samo s 1 query.
2. Ako zonata ne se obslujva ot sushtia server v zavisimost ot 
settings v server, za recursive i cache toi pak moje da vyrne
i CNAME i A RRs, no ima podrobnosti okolo tova dali e authoritative
answera.

        V normalna situacia clientite shte si poluchat vsichko ot
cache na servera koito polzvat, tuk obache se stiga do TTL na RRs
koeto e druga interesna dulga tema.

<em class="quotelev1">> Mnogo losho e, che pochti nikoi ne shvashta, che CNAME e zamislen
<em class="quotelev1">> za prenasochvane na resursni zapisi mezhdu RAZLICHNI zoni! Tova 
<em class="quotelev1">> traibva da se napishe na rabotnoto miasto na vseki administrator s 15
<em class="quotelev1">> santimetrovi bukvi, ako triabva i kato barelef da se izvaia! Primer za
<em class="quotelev1">> izpolzvaneto na taka napraveni CNAME zapisi e bezklasovoto delegirane
<em class="quotelev1">> na in-addr.arpa. Priatno biah iznenadan, che Boyan Krosnov beshe
<em class="quotelev1">> izpolzval CNAME za bezklasovo delegirane na edin PTR RR. Zaradva me
<em class="quotelev1">> vsyshnost facta, che chovek na rykovodna dlyzhnost v ISP znae tozi
<em class="quotelev1">> pohvat. Niama da kazvam v kolko drugi ISP-ta za tozi pohvat ne sa i
<em class="quotelev1">> chuvali!!!
<em class="quotelev1">> 

        Ne, CNAME m/u zoni ne mislia. Celta na cnames spored men
e da kajat koito tochno host kakvo e
smtp           cname  funnyname.domain.com
i taka, a tova izobshto ne e problem.
Polzata ot tova e che lesno moje da si smenish koi da ti 
e smtp v domain-a. (ako ima maluk TTL pochti na momenta).
Procheti otnovo RFC-tata koito sa za DNS, mislia che si propusnal
niakoi momenti, tova koeto kazvash moje da se sluchi realno samo 
s mnoooogo kalpavi serveri, a takiva az pone ne sym vijdal.

<em class="quotelev1">> Sega otnovo se vryshtame na temata UDP. Celta na UDP uslugite
<em class="quotelev1">> e da osiguriat byrzina (predi vsichko). Da me proshtavat niakoi hora,
<em class="quotelev1">> no az ne vizhdam kak posledovatelnoto tirazhirane na DNS zaiavki
<em class="quotelev1">> spomaga za byrzinata na UDP uslugite. Pak davam primer. Primerno UDP
<em class="quotelev1">> bazirana usluga traibva da izprati UDP paket sys zaiavka do server.
<em class="quotelev1">> Zadachata vkliuchva namiraneto na IP adresa na servera. Ako toi e
<em class="quotelev1">> opisan s CNAME tova shte zabavi sulugata dvoino it gledna tochka na
<em class="quotelev1">> DNS vremeto za poluchavane na resursen zapis. Mozhe da se sluchi taka,
<em class="quotelev1">> che paket za usluga, koiato po princip ima vreme za izvyrshvane 2 ms
<em class="quotelev1">> mozhe da se izpylni za vreme mnogo po-goliamo ot 2 ms (dori za
<em class="quotelev1">> secundi). I cialata efektivnost i byrzina se gubi. Efekta se useshta
<em class="quotelev1">> osobeno silno pri zabaveni otogovori ot DNS. 

        Ako client/server si govoriat po udp postoianno, ima edin resolving
v nachaloto , i ot cname niama zabaviane. Za DNS i podobni na nego
pak e constantno vremeto, nezavisimo dali e cname ili ne.

[cut]
za delegiraneto po kusno, ako ostane vreme.

<em class="quotelev1">> Bibliotekata na resolvera obsluzhva nai-popyliarnata UDP usluga... 

        da


--
have fun,
alex
============================================================================
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
============================================================================