Vlákno názorů k článku Český Internet není zvenku vidět! od Petr Souček - Zdá se, že zdánlivě jednoduché věci se můžou...

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.

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.

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.

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

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).