Názory k článku Český Internet není zvenku vidět!

Je to tak; jsme do internetu pripojeni pres uzel v Londyne a pro vetsinu ceskych stranek/serveru mame smulu - resp. hlaseni od firewallu Unknown host specified: www.vol.cz, (Authoritative host not found)

Mame stejny problem (nase firewall je v New Yorku)- trva to jiz nekolik dnu a do znacne miry to paralyzuje chod nasi kancelare. Zajimalo by mne, zda existuje instituce, ktera za spravnou funkcnost narodnich nameserveru zodpovida a jestli je moznost se nekde urychlene dozadovat napravy.

1. problém není zřejmě v serveru ns.uu.net, protože funguje spolehlivě jako sekundár pro Rakousko (.at), Španělsko (.es), Portugalsko (.pt) - u všech zón obsahuje ns.uu.net skutečně tu nejnovější zónu. Na to, že problém je skutečně na straně EUnetu ukazuje i to, že na sekundáru sparky.arl.mil je 4 dny stará zóna.

2. Situaci "pomohlo" i to, že je v zóně .cz nastavená poměrně krátká doba expirace 10 dnů, obvykle to bývá cca 6 týdnů (3600000 s).

Mam takovy pocit ze ted uz nefunguje .CZ domena
ani v ramci Ceskeho internetu. Nefunguje mi napr.
justice.cz, nic.cz atp., cerpame z ns.anet.cz.
Doufam ze se treba pletu. Muzete to nekdo potvrdit ?

No, www.nic.cz, www.justice.cz jede, nic.cz a justice.cz ne, takze to asi bude tim, ze nic.cz a spol. proste neexistuje. (Zkouseno na ns.anet.cz i jinde)

Me zase nefunguji dneska (vcera v pohode) domeny www.zive.cz a www.cpress.cz ci zive.cpress.cz. Zkouseno tez na mnoha nameserverech, i na cz.eunet.cz. Takze asi nejaky problemek...

Tak uz to jede...

rekl bych, ze ns.uu.net nefunguje ani pro Rakousko ani pro Spanelsko:

> botanix.wu-wien.ac.at
Server: ns.uu.net
Address: 137.39.1.3

*** No address (A) records available for botanix.wu-wien.ac.at
> www.rediris.es
Server: ns.uu.net
Address: 137.39.1.3

*** No address (A) records available for www.rediris.es
> www.uu.net
Server: ns.uu.net
Address: 137.39.1.3

Name: www.uu.net
Address: 208.243.117.123

Vypada, ze se to uz probralo vsechno.

Vypada, ze se to uz probralo vsechno.

Uz od vcerejsiho vecera jsem mel problemy se zasilanim posty z Hotmailu. Nekam se mi podarilo dorucit e-mai az na potreti. Dnes je situace podobna. Někam to doručím a jinam zase ne. Takze opet pouzivam telefon. :-)

Zatímco cpress.cz mi dnes dopoledne sel, zive.cpress.cz ani omylem. Rano mi to hazelo hlasku, ze neexistuje (Hlavenka to asi vzdal :-)), ted to po mne zase chce login a heslo.

Uvazoval jsem, zda jsem neprehledl, ze by melo byt Zive od dneska placene. Po zaplaceni bych dostal jmeno a heslo a mohl bych si ho cist vesele dal. Mozna tomu tak je. Takze zkuste napsat na hlavenka@cpress.cz a zeptat se, kolik stoji predplatne Zive na rok. :-) Prece nebudeme chtit od Computer Pressu neco zadarmo.

No konecne uz vim proc. Myslel jsem, ze my zacnul blaznit provider, ale jak je videt, pravda je jina.
Tady v USA me to parkrat docela nastvalo, protoze sem si zvyknul cist v ceskych domenach, kazdy den. Pak, jsem ale prisel na jednoduchej trik, staci proste furt klikat na "REFRESH" dokud se stranka nenajde. Zdrzujeto, ale ucel to po case splni. Sance jsou podle mych zkusenosti, ze do 20 pokusu se vzdycky vejdete.
Ale stejne by se s tim melo neco delat, a to RYCHLE.

Asi to tak bude, me ted vubec nejde www.paegas.cz, server nenalezen. Co se to proboha deje??? Cesi asi zase ukazuji svetu svoji pripravenost na vstup do EU :o)

Jelikoz jsem webmaster stranek, ktery maji smysl pouze v zahranici a denni navstevnost je ve stovkach, tak jsem z teto situace celkem nervozni. Jestli nekdo vi kdy a jak to bude spraveno muze mi prosim poslat email. Tato situace je celkem zarazejici. Verim, ze kdyby se neco podobneho stalo treba v USA, tak z toho bude dost velky soudni proces o miliardy dolaru odskodneho. V Cechach asi nahradu usleho zisku vymahat nejde, ze? Asi ne, vzdyt nase zakony maji o internetu velikou diru!!! Oprvavdu se domnivam, ze jako uzival, ktery radne plati za svoji domenu .cz by se melo dostat nejake nahrady.

Momentalne je neco pred pulnoci a servery Eunety prestaly znat nekolik ceskych domen. Nevim jestli se jedna o problem spojeny s odstranovani nejakych problemu nebo se nachazime v agonii, ale vraci se nam hordy mailu a dalsi horda webovskych stranek negunguje :-((((((

zd

Nejsem zadny odbornik, jen potrebuji z Lucemburska, kdy bydlim, posilat maily do Brna, a porad se mi vraci s poznamkou, ze "host doesn't exist"! Nemohl by s tim nekdo neco udelat? Jsem uplne odriznuta!

Pokud je vše ostatní v pořádku, nejspíš má ještě váš nameserver v keši odpověd z (autoritativního) ns.uu.net, že daná doména neexistuje. Nejlepší asi bude nějaký čas počkat a pak to zkoušet znovu, nemělo by to trvat dlouho.

Mohu potvrdit, že pošta posílaná z USA k nám se vracela jako nedoručitelná, totéž se stalo i při pokusu poslat mail do USA. Ne vždy, ale stalo se.

To je v pořádku, nikde není řečeno, že musí zpracovávat rekurzivní dotazy, ne? ns.uu.net musí umět odpovědět na dotaz na nameservery pro doménu ac.at nebo rediris.es, a to zvládne. Root nameservery take neumožňují rekurzivní dotazy, ns2.nic.fr také ne. cz.eunet.cz rekurzvivní dotazy umožňuje, dokonce i na jiné domény než .cz, címž si koleduje o problémy. RFC2010 vysvětluje, proč by neměly byt povoleny rekurzivní dotazy (týká se root nameserverů, ale lze to vztáhnout i na tld nameservery):
Recursion is a major source of cache pollution, and can be a major drain on name server performance. An organization's recursive DNS needs should be served by some other host than its root name server(s). An exception is made for missing glue since it's possible that glue needed for some delegations will not be within or beneath any zone for which the server is authoritative. Such glue must be fetched via recursive lookups to other servers.

Tak nevim jak moc se lisi postup a vysledek:
> www.seznam.cz
Server: ns.uu.net
Address: 137.39.1.3

*** No address (A) records available for www.seznam.cz

a
> www.rediris.es
Server: ns.uu.net
Address: 137.39.1.3

*** No address (A) records available for www.rediris.es
V prvnim pripade se jedna o cituji:
"Výjimkou jsou pouze přímé dotazy, který nameserver je pro určitou
českou doménu druhého řádu autoritativní, což však pro běžného uživatele není žádná pomoc."
tedy z tohoto pohledu je to prezentovano jako chyba, zatimco v druhem pripade se jedna o:
"To je v pořádku, nikde není řečeno, že musí zpracovávat
rekurzivní dotazy, ne?"
Upozornuji, ze druhy nazor neni z ust autora clanku!!!
Tak a ted mi vysvetlete. Nebo ze by opravdu cesi museli mit neco extra?

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.

Zdá se, že zdánlivě jednoduché věci se můžou pěkně zkomplikovat...
Ale k tomu "cache pollution" - pokud se nezakáže rekurze, tak i do nejnovějšího bindu je možné zatáhnout zcela chybné A záznamy v additional section - pokud se někdo o to snaží., i když je to mnohem složitější než dříve.

Zdá se, že v různé době a z různých míst dával ns.uu.net různé odpovědi - jedně tak se dá vysvětlit to, že pozorování byla různá.
Co se rekurze týče, tak pokud vím, nameservery mezi sebou posílají nerekurzivní dotazy, takže to, že TLD server neřeší rekurzivní dotazy nemusí vůbec nikomu vadit. Resolver na každém počítači je nastaven na nameserver lokální nebo providera, který tu rekurzi vyřeší.