classic.ISPforum.cz

Nenapadá někoho, proč by měl mít mikrotikův DNS problém s výpadkem služeb google, jako se stalo dnes? Chvilku nad tím přemýšlím a vůbec nic mě nenapadá ...

Nechtěl jsem to používat, ale okolnosti (upgrade bodu) mě donutily. Takže na CCR1036 s ROS 6.35.4 používám DNS server. Je to pro pár set lidí (šest set myslím). Samozřejmě nepoužívám jako forwardery google, ale jiné vlastní (Bind) na čistém linuxu a ve vnitřní síti běžící. A ty také nemají forwardery, maximálně mezi sebou.
V době výpadku google ale čas od času nechtěl překládat, timeout. A to ani vnitřní jména, kvůli kterým do internetu nemusí ani náhodou. Přitom v cache (která nebyla na 100 %) ten záznam je a byl.
Kontrola je scriptem, pravidelně, čili o vyloženou náhodu se nejednalo.

Jen se spravil google, už zase překládá.

ludvik píše:Nenapadá někoho, proč by měl mít mikrotikův DNS problém s výpadkem služeb google, jako se stalo dnes? Chvilku nad tím přemýšlím a vůbec nic mě nenapadá ...

Nechtěl jsem to používat, ale okolnosti (upgrade bodu) mě donutily. Takže na CCR1036 s ROS 6.35.4 používám DNS server. Je to pro pár set lidí (šest set myslím). Samozřejmě nepoužívám jako forwardery google, ale jiné vlastní (Bind) na čistém linuxu a ve vnitřní síti běžící. A ty také nemají forwardery, maximálně mezi sebou.
V době výpadku google ale čas od času nechtěl překládat, timeout. A to ani vnitřní jména, kvůli kterým do internetu nemusí ani náhodou. Přitom v cache (která nebyla na 100 %) ten záznam je a byl.
Kontrola je scriptem, pravidelně, čili o vyloženou náhodu se nejednalo.

Jen se spravil google, už zase překládá.

Dělalo to na mě dojem, že dynamické routování v síti Google se proste odmlčelo. DNS servery se vůbec nedostaly na googlí DNS směřovač. Mě pomohlo 2x promazat cache a nový request už byl aktuální a šlo to..
U google to bylo úplně mrtvé, takže asi nějaky ARP exploit u nich v síti.

Je pravděpodobné, že se asi Googlu zbořil routing. Třeba k tomu vydají snadno pochopitelné, důvěryhodně znějící, nesprávné zdůvodnění.

Nicméně k tomu zdrhávjícímu se DNS i když neforwarduje na resolvery Googlu. IMHO to způsobovaly DNS dotazy na ty tuny Googlích odkazů, co jsou všude dneska rozlezlé. Google kvůli balancingu má krátké TTL, a to jak pro platné, tak i negativní odpovědi, takže pokud stovky klientů leze kamkoliv, tak to stejně generuje tisíce DNS dotazů na resolving v googlích primárních DNSkách a když neodpovídají, tak chvilkama může bindu dojít limit, když se to sejde a právě se flushnou negativní data z cache o nedostupnosti Googlích DNS, pak bind není ochoten odpovídt i na jiné věci, byť je má v cache.

Google neřeším Zprávy mluví o rozbořeném BGP v kombinaci s jejich kreativním routingem.

S bindem problém nebyl - hlídám je také a je jich víc, dokonce je podstatně více userů na nich závislých (a optikáři jsou jen na bindech) ... jen s mikrotikem byl. A nejen se záznamy google, ale tak nějak se všemi.
Mám jenom jeden (uživatelsky přístupný) resolver na mikrotiku, takže nevím jestli to není feature této verze.

Myslíš, že nedostupnost google vyvolala DoS toho mikrotiku (čistě procesorově problém nebyl)? Sice to asi možné je, ale těch dotazů tam musí být stejné množství. Spíš méně, když ten první neprojde ...
Spíš mě teď napadá součet timeoutů jednotlivých serverů a nic moc multithreadové provedení mikrotikovic DNS. Otázkou je, jestli je z toho cesta ven jiná, než jeho likvidace.

Dost mě ta závislost na google štve. Zvlášť, když jsem závislý i když nechci a podle mě nejsem

Forwarder v ROSu je paskvil, a snad jednovláknový. Takže klidně to, že google neodpovídal, tak fungovalo jak DOS na klienty i při dotazech na jiné domény. Jak často k tomu bude docházet záleží na tom, jakou máš max cache TTL v tom ROSu.

Jinak k tomu Mikrotik DNS.. není to klasický DNS server s bindem ale pouze DNS cache.. Tzn. na vstupu potřebuje nějaký bindovy resolver, aby z něho cachoval dotazy s určitým time outem..

Pokud se na resolver posíláji dotazy z ROS a resolver na ne nezna odpoved, posle mu zpet informaci o absenci zaznamu, nebo v horsim případe ceka na time out (což v případě rozpadu core směřovače google mohlo nastat), protože resolver sám je v timeout cyklu. 600lidi už vytvoří docela pekny query pack a vzhledem k tomu, že na DNS se v MTiku nesahlo tak 10 let, tak to nebude asi ani hi tech. Pokud primarni DNS přestane odpovídat na query, které nemá resolvnute a odmlčí se, to same bude dělat Tik, a pokud tam má na dotazy nějaký FIFO, tak je vymalovano.. DNS cache na Mikrotiku je je opravdova z nouze ctnost, ktere je rozumnější se vyhýbat a já ji nechávám jenom jako sekundár, pro případ restartu primaru

A co se týče kapacity.. Ta je myslim velká.. jednu dobu na nás byly směrovaný útoky přes port 53 systémem, že jsme byli terminací pro nečí DNS request a naše CCR1036 odbavovalo cca 25000 paketů tohoto typu a bralo mu to nějaký výkon. Protože se mi nelíbilo, že to žere strojovej čas, zakázal jsem destination a byl klid, takže ta logika je poměrně výkoná, ale asi nesmí mít nějaké nevyřízené query.