Autor: Tomasz Surmacz (tsurmacz_at_okapi.ict.pwr.wroc.pl)
Data: Mon 23 Oct 1995 - 13:22:46 MET
Andrzej Resztak (resz_at_priam.umcs.lublin.pl) wrote:
: Rafal Maszkowski (rzm_at_mat.uni.torun.pl) wrote:
: : Maciek Uhlig (muhlig_at_helios.cto.us.edu.pl) wrote:
: : : On Fri, 20 Oct 1995, Ireneusz Neska wrote:
:
: : man host:
:
: : extraneous glue record for name within zone from server
: : During a zone transfer, a glue record is included for a
: : name which is not part of the zone or its delegated
: : subzones. This is done in some older versions of BIND.
: : It is undesirable since unauthoritative, or even
: : incorrect, information may be propagated.
:
: : Nie wiem jak uniknac. Zainstalowac bind4.3.9?
:
: Nie wystarczy wywalic nadmiarowy rekord NS? Przypuszcam, ze w wiekszosci
: przypadkow powstaly one po dodaniu domeny na primary NS
: i nie poprawieniu na secondary NS, ktore tym samym nie wiedza,
Jeden z mechanizmow "recznego" powstawania takich rekordow opisal
Wojtek Myszka, natomiast z wlasnego doswiedczenia moge powiedziec,
ze najczesciej powstaja one "automatycznie" w taki mniej wiecej sposob:
Przypuscmy, ze na komputerze amargosa.ict.pwr.wroc.pl mam PRIMARY dla
ict.pwr.wroc.pl. W tablicach DNS jako SECONDARY dla tej domeny
wpisanych jest kilka innych hostow - m.in. sun2.ci.pwr.wroc.pl i
okapi.ict.pwr.wroc.pl. named na amargosie kopiuje sobie rekord A
dotyczacy sun2 i jest to wlasnie taki 'extraneous glue record'. Na
dodatek zostaje on przetransportowany do wszystkich SECONDARY wraz z
tablicami domeny. A jak nawet nie zostanie, to named na tych SECONDARY (np.
na okapi.ict.pwr.wroc.pl) sam sobie znajdzie i dolozy.
Widac to wyraznie w plikach 'skopiowanych' na okapi z amargosy:
$ORIGIN pwr.wroc.pl.
ict IN SOA amargosa.ict.pwr.wroc.pl. urban.ict.pwr.wroc.pl.
(
95101901 43200 7200 432000 86400 )
IN NS sequoia.ict.pwr.wroc.pl.
$ORIGIN ict.pwr.wroc.pl.
sequoia IN A 156.17.9.3
$ORIGIN pwr.wroc.pl.
ict IN NS okapi.ict.pwr.wroc.pl.
$ORIGIN ict.pwr.wroc.pl.
okapi IN A 156.17.42.30
$ORIGIN pwr.wroc.pl.
ict IN NS sun2.ci.pwr.wroc.pl.
$ORIGIN ci.pwr.wroc.pl.
sun2 81838 IN A 156.17.5.2
Jak widac - rekordy dotyczace adresow sa uzupelniane z najrozniejszych
miejsc w trakcie transferu tablicy dla strefy ("zone") z primary do
secondary.
Tak sie w kazdym razie zachowuja wszystkie named na znanych mi
systemach (SUN, Linux), nie zachowuje sie tak nowy bind, ktorego mozna
skompilowac. Ogolnie rzecz biorac, nie jest to blad, lecz
ostrzezenie. Problem powstac moze dopiero wtedy, gdy przez pomylke
zrobimy co innego - np. na serwerze dla pwr.wroc.pl delegujemy domene
ict.pwr.wroc.pl na jakis inny nameserver i... pomylimy sie w numerku
tego serwera. Taki blad naprawde trudno wykryc, a jest on w stanie
kompletnie rozlozyc komunikacje z nieszczesnym komputerem...
Tomek
-- _________ (_ _' __) Tomasz R. Surmacz *----* Work:(071)202823 tsurmacz_at_ict.pwr.wroc.pl | (__ \ http://www.ict.pwr.wroc.pl/~tsurmacz/ Home: ts_at_papaja.wroc.apk.net |__(____/ For PGP key finger tsurmacz_at_asic.ict.pwr.wroc.pl *---* irc: TomekS
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 15:53:19 MET DST