DNS - ts00.eset.com na 127.0.0.1

tom-tom

čaute, řešil jsem nějaké problémy s DNS, někteří klioši mi totiž volali, že se jim špatně načítá facebook nebo youtube, nenačítá to obrázky, nebo styly, resp. se zmrší layout webu, ale třeba jen na jednom počítači doma, jiný pc ok..

Našel jsem v DNS záznamech hostname ts00.eset.com (ts00 - ts09) s ip adresou 127.0.0.1

Neříkám, že tohle je zrovna zdrojem těch problémů, ale chvíli předtím jsem viděl totéž s hostname domény mcafee.com, ale přijde mi zvláštní, že dnsko vrací ip loopbacku.

Nejdřív jsem myslel, že se mi zbláznil DNS server, ale pak jsem zkusil několik online DNS lookup na netu a tam je to taky. Co je to kua za haluz?

hapi

ty hele, před 14 dny tu někdo zakládal jiný vlákno se stejnym problémem. Přispíval sem tam taky i když takhle podrobně jsem to nezkoumal ale problem byl stejnej.

reset

jak pises, to dns jsi testoval odkud ?

tohle jsme zazili u nas priblizne pred rokem, pro FB to vracelo loopback , ale uz v prvniho routru to fungovalo korektne , usoudili jsme na zavirovany widloidni stroj .

iTomB

To se vraci i na linuxu a i z DNS google. Takze zavirovane wokna to nejsou.

reset

mas recht, ts00.eset.com to preklada odkudkoliv na 127.0.0.1

s tim FB to byl asi jinej pripad

iTomB

Jednou se me klient ptal, zda mu neblokuju FB, ze mu na jednom PC nejde. Tak jsem mu sdelil, ze ja nic. Problem byl v ovladacich sitvoky.

Druhej pripad (sam jsem zkousel najit opravu, ale nezadarilo se. Ovladace jsem tam novejsi nedaval) vse z PC slo, jen jeden server ne. Ping prosel zobrazeni stranky ne. Z toho sameho kabelu ci z jineho PC sel ten web normalne. Nevim co to bylo, ale do dneska to nejede.

iTomB

tom-tom

No, právě kdyby to bylo u jednoho klienta.. v pátek dopoledne jsem měl na firmě klienta s notebookem, kterého to nechtělo doma pustit hrát jednu onlajnovku. Vzal ho sebou, připojil se na kábl na stole a hra šla. Tak jel domů a zase nešla. Winboxnul jsem se k AP, ke kterému je ten klient připojený a zjistil jsem, že se ztratilo nastavení DNS. Chtěl jsem ho nastavit znova, ale nešlo to uložit. Prostě to nereagovalo na tlačítko OK, ani z konzole to nešlo nastavit, tam to asi po minutě vyhodilo nějaký timeout. Pomohl až update mikrotiku na novější verzi. Od této chvíle jsem měl na stole nachystanou záložní CF s licencí na výměnu :)

Večer volal druhý klient - jiné město, jiné AP. Dva ze tří PC doma mají problém s yt a fb. Flushnul jsem dns-cache na AP, on si doma restartnul wifi a zařízko a rozjelo se mu to.

Po něm volal další klient, opět jiné město a AP. Pro změnu jeden PC ze tří měl problém, všechno už zkusil restartovat než mi volal, ale nepomohlo mu to. Dneska jsem mu volal, abych zjistil jestli je to ok, podle všeho se to "samo spravilo" zhruba v době, kdy jsem u nás na AP flushnul dnsko.

No a dnes ráno volala klientka, která je připojená na stejném AP i sektoru jako já, má doma jen jeden počítač a problém s yt a fb. Já mám doma 4 aktivně využívané PC/ntb a žádný problém se stránkama jsem zatím nezaregistroval. Tak jsem vyčistil dnsko i na tomto AP, jenom mi teď ta klientka nebere telefon, abych se dozvěděl, jestli jí to ještě zlobí nebo ne.

hapi

ty používáš DNSko u klientů v zařízení a nebo na APčkách? ty voe tak to sis docela posral život. Každý malí dítě ví že DNSko mikrotiku stojí těžce za hovno pokud tam neupravíš jeden parametr. Proč sakra nemáš centrální DNS? to by totiž vysvětlovalo ten samej problem u mě kdy po zapnutí hotspotu se zapne DNS na MKčku pro potřeby hotspotu. Doma nám to jelo vždy ok protože tam je vyladěný DNS na hlavní GW ale u toho chlápka co jede přes hotspot to ještě protejká DNSkem na hotspotu který to asi vykurvilo úplně stejně jako vám.

tom-tom

Používám to tak roky rokoucí a nikdy jsem s tím neměl problém. Mám:

Primární DNS na linuxu

Sekundární DNS na linuxu

- tyhle dva si bere hlavní gw (mikrotik x86, dvoujádrový Intel)

- od něj si pak berou APčka, které dělají taky cache

U klientů pak nastavuju primár na adresu toho AP a sekundár na hlavní gw (pro případ, že by na AP cache "nějak" lehnula)

reset

my jsme ty cache na MK vypnuli a pouzivame jen primarni Bind , funguje to daleko lip

hafieror

Používám to úplně stejně jako tom-tom a nikdy jsem nezažil problém

tom-tom

Nevím ale, jestli to s tím esetem na loopbacku nějak souvisí, jenom jsem si toho všiml při kontrole těch dns-cache a obou našich dns serverů.

Podle výpisu z primárního dns to pochází z nameserverů dynect.net

; <<>> DiG 9.5.1-P2.1 <<>> ts00.eset.com

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47882

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:

;ts00.eset.com. IN A

;; ANSWER SECTION:

ts00.eset.com. 558625 IN A 127.0.0.1

;; AUTHORITY SECTION:

eset.com. 31890 IN NS ns2.p06.dynect.net.

eset.com. 31890 IN NS ns3.p06.dynect.net.

eset.com. 31890 IN NS ns4.p06.dynect.net.

eset.com. 31890 IN NS ns1.p06.dynect.net.

;; ADDITIONAL SECTION:

ns1.p06.dynect.net. 31858 IN A 208.78.70.6

ns2.p06.dynect.net. 31858 IN A 204.13.250.6

ns3.p06.dynect.net. 31858 IN A 208.78.71.6

ns4.p06.dynect.net. 31858 IN A 204.13.251.6

;; Query time: 0 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Sat Jan 12 11:36:01 2013

;; MSG SIZE rcvd: 197

Podle informací na webu té domény, jde o nějakou dns službu, přes kterou si můžete nasměrovat záznamy k vašemu serveru, pokud u něho občas hrozí k nárazovému náporu návštěvníků, mělo by to zabránit položení serveru pod takovým náporem. Takže to zřejmě nějak hlídá počet počet dns žádostí a jak se to dostane nad nějakou předem nastavenou laťku, začne to vracet IP domény jako 127.0.0.1, takže to další počítače začne směrovat na jejich loopback a tím pádem ten server nelehne.

V tom případě to s mým problémem nemá nic společného, protože facebook a youtube mají svoje nameservery. Ledaže by používali stejný způsob. V tom případě by to teda znamenalo, že poslední 2 dny tyto dva weby čelí nějakému slabému dos útoku, což se projeví tím, že to občas někomu nechce jet... no ale proč jen v mé síti?

hapi

Používám to tak roky rokoucí a nikdy jsem s tím neměl problém. Mám:

Primární DNS na linuxu

Sekundární DNS na linuxu

- tyhle dva si bere hlavní gw (mikrotik x86, dvoujádrový Intel)

- od něj si pak berou APčka, které dělají taky cache

U klientů pak nastavuju primár na adresu toho AP a sekundár na hlavní gw (pro případ, že by na AP cache "nějak" lehnula)

právě kvůli těmhle kratochvílím nějaký takový kaskádový uspořádání DNS serverů jsme zamítly. Jednak nevim proč bych si zatěžoval APčka něčim takovym a druhak nemusim řešit nějaký podružný DNS resolvery po cestě. Nic to nepřinese kromě toho že když se něco takhle posere tak to abych vyflushovat půlku sítě. Jeden primár, jeden sekundár a šmitec. bind nebo jinej resolver a hotovo.

Pokud tedy nehodláš přendat z MKčka DNSko jinam tak si nastav kratší TTL v MKčku přes terminal. Na hlavní GW máme 5 minut. Čim víc dotazů, tim kratší TTL doporučuju. Když to tam cca při 500 lidech neni tak to dělá fakt výborný kraviny. To samí jsem nedavno udělal na tom hotspotu a je od tý doby klid.

tom-tom

Standartně je ttl 1w, já používám 30 minut na všech cache. Na APčkách mám výkonu i paměti dost, takže mi tam cache nevadí.

Tu kaskádu bych teoreticky zrušit mohl, ta je tam z čistě historického důvodu, kdy jsme měli na hlavní gw celeron, který dostával dost zabrat (mangle, qos, webproxy pro přesměrování neplatičů),

tak jsem mu ulehčoval kešováním na každém AP. Takže když jsme pak dali core2duo, nechtěl jsem do toho vrtat, když to fungovalo. Flush můžu udělat i hromadně, takže tohle pro mě nebyla žádná komplikace.

hapi

30 minut bylo pro nás hodně, sem tam to občas kravlo.

kovi_m

Měl jsem podobný problém ale seznam.cz 127.0.0.1, můj dodavatel konektu říkal že nás se stejným problémem je víc, příčinu nenašli. řešení: promazat DNS a restartnout síťovku. Dlouhodobé řešení neznám.

level

taky ten samej problem seznam.cz = 127.0.0.1

okoun

tento problém vypadá jako kdyby někde v nějakýmn centrálním DNS serveru někdo uděla takový zánam třeba nějakým omylem a ten záznam se zpropagoval dále do všech IPS DNSek. ten kdo měl již v keši tento záznam, tak problém neměl ale ten kdo si ho zorchu načítal z centrálních, tak měl průser.

nevím, ale úplně to tak vypadá...

whef

V týdnu stejný problém, způsobený zřejmě seznamem. Jak v naší síti tak v síti O2 nedostupný seznam atd. Museli se vymazat nějaké keše a někde to ručně i na pc :) restart pc nepomohl.

ppp76

Reseni uz se tu psalo , zakazat cokoliv na port 53 zvenci a problemny zmizej jak mavnujtim kouzeleneho proutku ..... plus jest edelam black list utoku z asie na verejky (rozumej neopravneny pristupy na tiky z verejkama) a jakejkoliv utok tak jde ipka hned na black list ....

Další stránka »