-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Biah se otkazal da pisha v lista.. no tazi tema e interesna i shte spodelia
niakoi misli kym neia, kato shte dopylnia Velin i shte pokazha oshte niakoi
neshta.
1. Protocolyt za syncronizacia na zonite NE znae nishto za view statement-a
na BIND. Za spravka mozhete da chetete diskusiite po temata v arhiva na
www.isc.org. Sledovatelno niama kak da kazhete koi tochno poimenen view
statement za zona da transferirate. Vie vinagi shte transferirate samo tozi,
koito otsreshnata systema shte vi dade. A tia shte vi dade tazi view obvyrzana
zona, koiato syvpadne s acl, v koeto e vkliuchen izrichno ili po pravilo na
izkliuchvane ot drugi vew statementi vashia IP adres.
Defacto view statement-a e localna vyzmozhnost na BIND i tia vinagi traibva
da se tretira kato takava makar, che chrez rndc mozhete da zadavate refresh
ili reload na view obvyrzani zoni na druga mashina, vse pak tova e forma na
remote administracia, a ne protocolno obvyrzano reshenie v ramkite na DNS.
2. View statement-a vi obvyrzva s reshenia za transfer, koito izlizat izvyn
ramkite na upravlenieto a systemata za imena taka, kakto tia e opisana v
syotvetnite RFC-ta. Velin obiasni, che mozhe da se raboti s rsync. Pri tova
zabelezhete, che synchrona na failove shte vi prinudi da izpylnite pyrvo
rsync, posle rndc. Ot gledna tochka na named.conf vsichki serveri
za imena, koito se synchronizirat po tozi nachin za edna i syshta zona shte
sa master. Prichinata e prosta. Ne mozhete da zadadete deklaraciata
type slave;
zashtoto shta traibva da go pridruzhite s opisanie na master serveri za imena.
No sled kato view statemnta izkliuchva opoznavane na zonovia transfer po
view statement, to tova e napylno bezpolezhno (vizh po-gore). Zatova e
nai-udachno da se polzva deklariraneto na zonata kato master. Sled kato
rsync prehvyrli file-a tova ne opresniava zapisite v zonata. Prichinate e,
che BIND gradi svoi cache-s na zonalnite files, a ne chete napravo ot
ASCII formatnite filove na zonite (mislia, che niama symnenia v nikoi, che
inache skorostta na BIND bi bila tvyrde niska). Za celta e nuzhno BIND
da byde priveden vyv rezhim na opresniavane na cache informaciata za
syotvetnata zona (otbelzhete, che pri tova se gradi authoritative cache,
pravete razlika s tipa na cache zapisite polucheni vsledstvie na rekursia!
Poslednite ne sa authoritative). Sled kato byde izvikan rndc i byde ukazano
koia zona v koi view statement da se opresni, promenite dovedeni ot rsync
shte vliazat v sila.
Rsync i rndc traibva vnimatelno da se obmisliat kato strategia za chroot-ed
BIND instalacii. Da se vnimava s ownership-a na file-ovete, koito se
transferirat! Tochno tuk se dopuskat dosta greshki.
3. DNS NAT Sieve
Ideiata za NAT sito ne e nova, no stranno zashto se polzva ultra riadko i se
priema za ekzotika. Osven ISC i RIPE mai nikoi drug ne ia polzva. Poradi tova
niama i documentacia i chovek traibva da razchita na lichni kontakti za da
poluchi poveche info po vyprosa. Edin holandec ot RIPE se beshe opital
da pishe neshto po vyprosa.. ne znam do kyde e stignal.
Ideiata e slednata. Ima edna NAT mashina s niakolko real IP adresa. Tezi
realno IP adresi sa pone tolkova, kolkoto sa view statement-ite vyrhu
vytreshnia DNS server (vizh niakolko reda po-dolu). Posle shte stane
iasno zashto e taka.
Zad NAT mashinata ima chastno adresno
prostrasntvo po RFC 1918 (makar, che mozhe da ima i realno, no tova e
po-redkia sluchai). Na interface-a na NAT mashinata, koeto gleda kym
vytreshnoto IP prostranstvo ima pone tolkova adresi, kolkoto view statementa
ima definirani vyrhu namirashtia se vyv vytreshnata mrezha DNS server.
Zaiavkite idvashti ot vyn se razpredeliat po NAT tablicata za maskirane prez
vytreshnite adresi. T.e. vytreshniat server za imena vizhda SAMO adresite
na NAT mashinata, koito gledat kym nego, no ne i adresite na realniat
iztochnik. Chrez NAT tablicata taka na praktika se kazva koi adresni
prostranstva kym koi view statement da se prilagat. Taka view statementa
na DNS servera stoi s postoianen acl, koito vkliuchva edin edinstven
IP adres.
Taka NAT tablicata na praktika nasochva zaiavkite kym razlichnite stementi
i tova mozhe da uskori rabotata na DNS servera.
Kak sega stoi transfera sys zonite. Stoi po syshtia nachin. Neka imame slave
server za imena, koito ima definirani slave zoni angazhrani s deden poimenen
view. Togava se podhozhda taka. Znae se koi realen IP adres shte translira
zaiavkata kym dadeno view (govorim za realen IP adres na NAT mashinata).
Tozi IP adres se opisva kato master za zonata vyv syotvetnoto view. Taka se
tegli tochno tazi zona, koiato se iziskva.
Razbira se, tova e model za naprednali. T.e. dalech sym ot misylta, che shte
se masovizira. Tozi model syshto taka ne mozhe da osiguri informacia za
zhurnalnite file-ove na BIND, osobeno ako shte se pravi statistika po IP
adresi na iztochnika sled tova ot tiah.
4. NAT + Anycast modeli
Tova samo vi go kazvam kato vyzmozhnost. Ne sym go vizhdal prilozheno
nikyde. Ako niakoi den mi se zanimava shte go opisha. V smisal, che sega i
da go opisha... niama da predizvika interes. Kakto se kazva.. ne mu e doshlo
vremeto.
Pozdravi i izvinenia za dylgia posting
Vesselin Kolev
On Thursday 12 Jun 2003 17:06, Alexander Velin wrote:
> On Thu, 12 Jun 2003, raptor wrote:
> > > Slave DNSа да трансферва и двете зони в две отделни viewта, като VIEW1
> > > да се вижда от 127.0.0.1 и в resolv.conf да ползваш 127.0.0.1 ?
> >
> > hmm :").. a kak da mu kava na slave da transferira samo opredelena zona.
> > Toi nali wivda samo tazi koqto mi predostawq master-a. Ili move li po
> > nqkakaw nachin da kava na master-a kogato resolva ot tozi adress da e
> > ednoto view a kogato trafsnferrira zona ot drugoto ?!
>
> Много добър въпрос :) За view-то немисля че може, но би могъл да взимаш
> VIEW1 зоната към slave-a:
>
> а) по rsync (over ssh)
> б) ако можеш да имаш routeing м/у masterа и slaveа на 192.168.1/32 ..
> специално за този трансфер може да направиш listen-on + match-clients
>
>
> happy hacking,
> velin
>
> ===========================================================================
>= 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
> ===========================================================================
>=
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+6XRv+48lZPXaa+MRAoxOAJ49hKX+PeWs8q03g2IBr9+b2eWiAQCgj8jD
RPx1kfWXZEJ0pLCvn68ADlg=
=+Dgg
-----END PGP SIGNATURE-----
============================================================================
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
============================================================================
