Pred nejakym casem jsem stavel router pro nejaky breeznet v Praze. Celke me prekvalilo, kdyz jsem si nechal vypsal packety co prichazely a nebyly urceny pro prislurny uzel. Kde jake "windows" si myslely, ze Internet (sit breeznentu) je "Microsofti sit". A hlavne kolik toho bylo (nezanedbatelna cast trafficu).
Je projek AS112 nutnou reakci na podobne chovani nekompetentnich administratoru ?
Názory k článku
AS112 - projekt DNS anycast
Ondrej Filip (neregistrovaný)
16. 8. 2004 10:20
Nový
Re: "divny traffic" na sitich
celé vlákno
Castecne ano, i kdyz to, co popisujete je neco trochu jineho. Na takovyhle traffic pomaha jiz dole zmineny filtering.
Dan Lukes (neregistrovaný)
17. 8. 2004 13:09
Nový
Re: "divny traffic" na sitich
celé vlákno
AS112 smeruje proti jine nekompetentnosti administratoru lokalni site - a to te, ze pro adresy, ktere ve sve siti pouzivaji nemaji korektne zavedene dopredne a reverzni zaznamy na nameserverech urcenych uzivatelum takove site ...
Gino (neregistrovaný)
16. 8. 2004 8:21
Nový
Hmm
celé vlákno
Proc veci delat jednoduse, ze? Staci jen zahazovat komunikaci z privatnich rozsahu na smerovacich ISP. Vetsina slusnych ISP to tak dela. Ovsem problem je s temi kdo to nedelaji a neni sila ktera by je donutila to zmenit proto tahle kulisarna, chapu. Ale ta vyhoda maleho zrychleni komunikace v lokalni siti je kaleni do vlastniho hnizda. Jeste min lidi bude kaslat na spravnou konfiguraci, protoze jim to stejne bude fungovat i kdyz vnitrne to bude blbe, ale co as112 to za ne vyresi.
Root (neregistrovaný)
16. 8. 2004 9:07
Nový
Re: Hmm
celé vlákno
Aha, takze jste nepochopil, co projekt AS112 dela ;-) Komunikaci z privatnich rozsahu samozrejme zahazovat muzete, ale hloupe DNS dotazy, ktere pochopitelne projdou a korektne se prelozi nejakym NATem, nicmene porad se budou hloupe ptat na napriklad 1.1.168.192.in-addr.arpa, bohuzel pomoci zadneho filtrovani packetu zahodit nemuzete. Jinak leda pomoci binda znasilneneho jako "DNS transparent proxy".
Petr Souček (neregistrovaný)
16. 8. 2004 10:00
Nový
Re: Hmm
celé vlákno
No, ono to z článku není tak úplně jasné, o dělá, a stránka http://www.chagreslabs.net/jmbrown/research/as112/ kde má být popis je down.
Pokusím se shrnout, jak se mi to rýsuje, kdyžtak mě opravte:
Pokud chci zjistit překlad adresy 192.168.0.1, tak se nejprve zeptám některého z [a-m].root-servers.net. Ten mi odpoví, že se mám zeptat některého ze 7 serverů [chia, dill...].arin.net, které jsou autoritativní pro 192.in-addr.arpa. Ten mi odpoví, že se mám zeptat blackhole-1.iana.org nebo blackhole-2.iana.org. A tady teprve nastupuje AS112 - v AS112 jsou routovány adresy 192.175.48.0/24 tedy poslední dotaz půjde na nejbližší server a ne do USA.
V případě jednoho zjištění zpětného překladu tedy jdou dva dotazy do USA a jeden lokálně. Tedy úspora nic moc. Leda to, že díky TTL 1 den:
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 86400 IN NS BLACKHOLE-1.IANA.ORG.
168.192.in-addr.arpa. 86400 IN NS BLACKHOLE-2.IANA.ORG.
bude ten dotaz na kořenové servery jen jeden denně. Což asi neplatí pro uživatele tinydns, který se pokud vím nespoléhá na platnost záznamů a provádí dotazy znova.
Nerozumím přesně, co se myslí tím "Zvláštní je v tom, že jeho servery neslouží pro překlad DNS dotazů, ale spíše pro jejich pohlcování.". Vždyť ta anycastová zrcadla na ty dotazy normálně odpovídají (NXDOMAIN), tak to bych těžko označil jako pohlcování. Nebo je to myšlené jinak?
V adresním rozsahu 192.175.48.0/24 se nacházejí tyto dva servery a server prisoner.iana.org z SOA záznamu - na ten budou zřejmě směrovány požadavky na update dns z Windows, že?
Existuje nějaká kvantifikace, kolik procent provozu tvoří u běžného ISP reverzní dotazy na RFC1918 adresy? Existuje nějaká statistika zatížení toho zrcadla v NIXu?
K čemu je ten dotaz na F root server? Jako další případ DNS anycastu? Narozdíl od předchozího případu ale síť 192.5.5.0/24 nemá vlastní AS. Ná s tím něco společného NIX? Na seznamu http://www.isc.org/ops/f-root/sites.php není.
A pro servery tld1.ultradns.net, tld2.ultradns.net platí totéž? Tedy že se stejnou IP adresou je jich po světě víc?
A nakonec prakticky - co musí ISP pro to udělat, aby používal lokální anycastové zrcadlo z AS112? Zdá se, že ode mě to totiž nefunguje.
Pokusím se shrnout, jak se mi to rýsuje, kdyžtak mě opravte:
Pokud chci zjistit překlad adresy 192.168.0.1, tak se nejprve zeptám některého z [a-m].root-servers.net. Ten mi odpoví, že se mám zeptat některého ze 7 serverů [chia, dill...].arin.net, které jsou autoritativní pro 192.in-addr.arpa. Ten mi odpoví, že se mám zeptat blackhole-1.iana.org nebo blackhole-2.iana.org. A tady teprve nastupuje AS112 - v AS112 jsou routovány adresy 192.175.48.0/24 tedy poslední dotaz půjde na nejbližší server a ne do USA.
V případě jednoho zjištění zpětného překladu tedy jdou dva dotazy do USA a jeden lokálně. Tedy úspora nic moc. Leda to, že díky TTL 1 den:
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 86400 IN NS BLACKHOLE-1.IANA.ORG.
168.192.in-addr.arpa. 86400 IN NS BLACKHOLE-2.IANA.ORG.
bude ten dotaz na kořenové servery jen jeden denně. Což asi neplatí pro uživatele tinydns, který se pokud vím nespoléhá na platnost záznamů a provádí dotazy znova.
Nerozumím přesně, co se myslí tím "Zvláštní je v tom, že jeho servery neslouží pro překlad DNS dotazů, ale spíše pro jejich pohlcování.". Vždyť ta anycastová zrcadla na ty dotazy normálně odpovídají (NXDOMAIN), tak to bych těžko označil jako pohlcování. Nebo je to myšlené jinak?
V adresním rozsahu 192.175.48.0/24 se nacházejí tyto dva servery a server prisoner.iana.org z SOA záznamu - na ten budou zřejmě směrovány požadavky na update dns z Windows, že?
Existuje nějaká kvantifikace, kolik procent provozu tvoří u běžného ISP reverzní dotazy na RFC1918 adresy? Existuje nějaká statistika zatížení toho zrcadla v NIXu?
K čemu je ten dotaz na F root server? Jako další případ DNS anycastu? Narozdíl od předchozího případu ale síť 192.5.5.0/24 nemá vlastní AS. Ná s tím něco společného NIX? Na seznamu http://www.isc.org/ops/f-root/sites.php není.
A pro servery tld1.ultradns.net, tld2.ultradns.net platí totéž? Tedy že se stejnou IP adresou je jich po světě víc?
A nakonec prakticky - co musí ISP pro to udělat, aby používal lokální anycastové zrcadlo z AS112? Zdá se, že ode mě to totiž nefunguje.
Ondrej Filip (neregistrovaný)
16. 8. 2004 10:11
Nový
Re: Hmm
celé vlákno
Predevsim diky za dobry komentar.
Dotazu na preklady techto adres muze byt potencialne hodne, proto i pri TTL 1 den muze byt uspora znacna.
S tim vyrazem "pohlcovani" mate pravdu. Nicmene smyslem DNS je spise preklad provest nez vratit neexistenci. Proto jsem ten termin pouzil.
Ano, updaty pujdou na nej.
Statistika existuje, zatim je jen interni NIXova, jiste nebude problem ji zverejnit.
F.root je jen priklad anycastu. S NIXem to nic spolecneho "zatim" nema.
Pro ultradns plati to same.
Aby ISP pouzival lokalni zrcadlo AS112 staci, aby si v NIXu nastavil s prislusnym routerem peering. To je technicky relativne snadna zalezitost.
Dotazu na preklady techto adres muze byt potencialne hodne, proto i pri TTL 1 den muze byt uspora znacna.
S tim vyrazem "pohlcovani" mate pravdu. Nicmene smyslem DNS je spise preklad provest nez vratit neexistenci. Proto jsem ten termin pouzil.
Ano, updaty pujdou na nej.
Statistika existuje, zatim je jen interni NIXova, jiste nebude problem ji zverejnit.
F.root je jen priklad anycastu. S NIXem to nic spolecneho "zatim" nema.
Pro ultradns plati to same.
Aby ISP pouzival lokalni zrcadlo AS112 staci, aby si v NIXu nastavil s prislusnym routerem peering. To je technicky relativne snadna zalezitost.
mira (neregistrovaný)
16. 8. 2004 22:43
Nový
Re: Hmm
celé vlákno
....bude ten dotaz na kořenové servery jen jeden denně. Což asi neplatí pro uživatele tinydns, který se pokud vím nespoléhá na platnost záznamů a provádí dotazy znova.
nee, tinydns zadne dotazy neprovadi
nee, tinydns zadne dotazy neprovadi
Root (neregistrovaný)
17. 8. 2004 10:03
Nový
Re: Hmm
celé vlákno
coze? a jak tedy zjisti, co ma odpovedet na dotaz, pro ktery nezna odpoved?
Yenya (neregistrovaný)
17. 8. 2004 16:33
Nový
Re: Hmm
celé vlákno
Neplette si TinyDNS a DNSCache.
TinyDNS odpovida jen na to co vi ze sve databaze a je nerekurzivni.
-Yenya
TinyDNS odpovida jen na to co vi ze sve databaze a je nerekurzivni.
-Yenya
Petr Souček (neregistrovaný)
17. 8. 2004 22:13
Nový
Re: Hmm
celé vlákno
To byl překlep, chtěl jsem napsat djbdns místo tinydns.
Myšel (neregistrovaný)
16. 8. 2004 12:06
Nový
Re: Hmm
celé vlákno
ISP to tak dělají. Problém je v tom, že třeba ta breezenetí síť se chová jako ethernet. Co tam kde odfiltrujete? :o))
Ondrej Filip (neregistrovaný)
16. 8. 2004 13:35
Nový
Re: Hmm
celé vlákno
Predpokladam, ze tato reakce patri do threadu '"divny traffic" na sitich'.
Filtrovani se na breezenetu provest rozumne neda, proste je nutne mezi SA a ty Windowsy vlozit nejaky prvek, ktery to umi, optimalne router nebo proste dobre nakonfigurovat Windowsy.
ISP, ktery si k beznemu breezenetu necha pripojit primo zakaznicka zarizeni, ktera nema ve sprave, si koleduje o to, ze mu 2 pripojky "sezerou" celou kapacitu AP.
Filtrovani se na breezenetu provest rozumne neda, proste je nutne mezi SA a ty Windowsy vlozit nejaky prvek, ktery to umi, optimalne router nebo proste dobre nakonfigurovat Windowsy.
ISP, ktery si k beznemu breezenetu necha pripojit primo zakaznicka zarizeni, ktera nema ve sprave, si koleduje o to, ze mu 2 pripojky "sezerou" celou kapacitu AP.
já (neregistrovaný)
21. 8. 2004 20:31
Nový
běžešelemovací řůčovičky
celé vlákno
běžešelemovací řůčovičky
Tiskni