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

Kód: Vybrat vše

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