Hlavní navigace

Vlákno názorů k článku Český Internet není zvenku vidět! od Petr Souček - 1. problém není zřejmě v serveru ns.uu.net, protože...

  • Článek je starý, nové názory již nelze přidávat.
  • 1. 2. 2000 11:51

    Petr Souček (neregistrovaný)
    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).
  • 1. 2. 2000 14:11

    Lukas Vesely (neregistrovaný)
    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. 2. 2000 18:04

    Petr Souček (neregistrovaný)
    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.
  • 2. 2. 2000 3:00

    Jiri Orsag (neregistrovaný)
    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.


  • 2. 2. 2000 10:49

    Petr Souček (neregistrovaný)
    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.