Ne, nebylo to vporadku. ns.uu.net je sekundar jak pro TLD at, tak
es. Pri validnim chovani ma odpoved vypadat takhle:
> botanix.wu-wien.ac.at.
Server: ns.uu.net
Address: 137.39.1.3
Authoritative answers can be found from:
AC.at nameserver = ns2.univie.AC.at
AC.at nameserver = alijku01.edvz.uni-linz.AC.at
AC.at nameserver = ns.austria.eu.net
AC.at nameserver = ns1.univie.AC.at
ns2.univie.AC.at internet address = 193.171.255.66
alijku01.edvz.uni-linz.AC.at internet address = 140.78.2.62
ns.austria.eu.net internet address = 192.92.138.35
ns1.univie.AC.at internet address = 193.171.255.2
> www.rediris.es.
Server: ns.uu.net
Address: 137.39.1.3
Authoritative answers can be found from:
rediris.es nameserver = sun.rediris.es
rediris.es nameserver = chico.rediris.es
rediris.es nameserver = tais.rediris.es
sun.rediris.es internet address = 130.206.1.2
chico.rediris.es internet address = 130.206.1.3
tais.rediris.es internet address = 130.206.1.39
tais.rediris.es internet address = 193.144.0.39
tais.rediris.es internet address = 130.206.206.137
Jak at, tak es byly ve stejne situaci jako my a diky
tomu, ze jsme prorazili my, ma najednou i ns.uu.net cerstve
verze at a es zon. Mimochodem doba expirace u at zony je
7 dni, u es je 30 dni. Je to velmi ruzne a evidentne to
ani jedne TLD nepomohlo. I ja si pamatuji, ze v dobach,
kdy jsem se nekonecne radoval z prvni komercni 64 kbps
linky do Amsterodamu, napsal Piet Beertema rfc v ktere
doporucoval expiraci pro tld kolem 4 tydnu. Jenze to bylo
nekdy pred 8 lety, kdy internet byl o necem jinem. Dnes
je peering mezi EUnetem a UUnetem na OC-12, a za 30 dni
jsme letos lednu v cz udelali 4854 novych registraci a zmen nameserveru, proti par zmenam za mesic nekdy v roce 1992.
Bohuzel se zmenili i lidi a supportu se staly velke organizace,
kde chvili trva nez se clovek probojuje, k nekomu, kdo nejen
muze, ale i chape :-(. Zatim co minula zmena na ns.uu.net
byla diky Andrew Partanovi hotova za par hodin. Reseni
soucasneho problemu trvalo mnohem dele.
Na reseni problemu s vyexpirovanou zonou na ns.uu.net jsem
zacal delat v patek, kdy jsem dostal warning z testu. Vzhledem k tomu, ze z UUnetiho supportu pres urgence, nebyla zadna odezva zacal jsem v nedeli a pondeli problem eskalovat. Dostal jsem se
na 3rd level (4th level je Vice President of Customer Service
and E-Commerce, 5th level je Peter Van Camp) kdyz se ozvala v utery po obede Marion Adams, ze uz jako sef 1st level supportu nepracuje, ale forwardovala mne na zodpovedneho cloveka. Pak uz byly jen 2 iterace, kdy jsem Mary presvedcoval, ze je u nich musi byt neco shnileho, ze se zona nemuze pri nasi vzajemne konektivite tahat 3 hodiny a nekdy k veceru jsem dostal konfirmaci, ze ns.uu.net je vporadku a opravdu je. Tohle je ta konfirmace:
|Hi Jiri,
|
|I just verified that I am able to do a zone transfer from that IP
|address, and we now have the same serial. You are correct, previously
|before I had made the change on our side we were not able to pull
|the zone.
|
|Please let me know if you see any other problems, and I will look
|further.
Jeste par poznamek k nekterym myslenkam v diskusi:
ad rekurze - rekurze stejne jako transfer zony pro neautorizovane
servery z cz.eunet.cz zakazeme. Nepovazuji, ale za moudre
omezovat tok dat z nameserveru, kdyz jsou potize s transferem na
2 z 6 sekundaru. Az bude distribuce nejakou dobu stabilni
uriznu co nebude nezbytne. Jiste se pak najdou lide, kteri budou
mit pocit, ze CZ nefunguje, protoze jejich vypis z nslookupu
bude vypadat najednou jinak. S tim se, ale neda nic delat,
protoze vypnuti rekurzi a omezeni transferu je v technickych
podminkach provozu.
Ad hypoteza o tom, ze 17.1. byl spusten novy nameserver s TSIG
Posledni zmena binarek bindu je z 6.1. a nijak nesouvisi s
DNSSEC. TSIG je s ruznymi problemy podporovana od verze 8.2 od leta lonskeho roku. Je sice pravda, ze mohou byt problemy s
transferem podepsanych zon z/do neopatchovanych verzi bind 8.1.x
(bug v db_load 8.1.x), ale to neni nas pripad. Zona CZ neni
podepsana.
Ad citace rfc2010 - rfc2010 je RFC v kategorii "Informational"
z roku 1996 a popisuje "Operational Criteria for Root Name Servers". Od roku 1996 prodelal bind docela velky vyvoj v
zabezpeceni udrzovanych zon pred znecistenim z cache. Pokud bychom dnes meli vyjadrit racionalni duvod pro blokovani rekurzi, tak je to mnohem vice zatez nameserveru, zvlaste pak s ohledem na nastupujici DNSSEC.
Ad ruzne chovani resoluci z ruznych mist:
To, jak a kde se problem s resolucemi pres ns.uu.net projevoval bylo dost nahodne a zaviselo to na razeni nameserveru v odpovedi (round robin,sekvencni), pripadne na preferencich resolveru nebo nameserveru pres ktery klient resolvoval. To vedlo k tomu,
ze nekde bylo treba pokus o resoluci (pristup na stranku,
odeslani mailu) opakovat vicekrat, nekde se situace zlepsila po expiraci zaznamu.