Předpokládám, že nejčastější důvod otravy cache je ten, že ISP používá jeden DNS server jako autoritativní i pro vyřizování rekurzivních dotazů (bezpečnosti DNS by asi dost pomohlo, kdyby to měl Bind ve výchozí konfiguraci zakázané, a povolil to jedině tehdy, pokud správce vlastní krví podepíše, že to opravdu chce povolit). Pokud u něj někdo hostuje doménu, server má ty záznamy správně ve vlastní zóně a poskytuje je jako autoritativní server. Jenže když pak majitel doménu přestěhuje jinam, v nadřazené doméně jen změní adresy doménových serverů, ale nezařídí smazání ze zóny původního ISP, ten poskytuje dál staré odpovědi ze svého zónového souboru i na rekurzivní dotazy, protože neví, že už není autoritativním serverem (i když by to samozřejmě vědět mohl).
Pokud majitel domény používal DNSSEC a po přestěhování klíče nezmění, bude dokonce procházet i validace DNSSEC.
Není to ale problém DNSSEC ani DNS, ale jen toho míchání autoritativního a rekurzivního DNS serveru v jedné instanci. Autoři bezpečných DNS serverů vědí, proč tyto dvě služby nedovolí zkombinovat do jednoho serveru.
Pokud jsem dobře pochopil původní zdroj, tak machinace s IP adresami MX serverů se týkaly třeba serverů jako gmail-smtp-in.l.google.com. U těch bych moc nepředpokládal, že k jejich změně dojde takovýmto omylem. Jinak obecně ano, stínové autoritativní zóny vzniklé po odstěhování domény jinam, jsou asi nejhorším důsledkem kombinování autoritativního a rekurzivního serveru.
U těch MX záznamů bych se vůbec nedivil, kdyby to bylo jedno z mnoha geniálních antispamových řešení. "Z naší sítě chodí moc spamů na GMail, tak ten traffic přesměrujeme k sobě, přefiltrujem, a máme to vyřešené. Padla!" Jako cílený útok na konkrétního uživatele mi to připadá příliš humpolácké. Ale vyloučit to samozřejmě nelze, a cílený útok by bylo možné provést stejným nebo podobným způsobem, akorát by se na něj nepřišlo tímhle postupem.
Každopádně je dobře, že se takovéhle výzkumy dělají.
Takové jemnosit se neřeší. Přesměruje se natvrdo vše, profiltruje a pošle dál. že je tomu často tak, že někaqm jina,, než to původn mířilo, žetím rozbiju SFP, DKIM další neřeší...
To už povařuji za slušnější ty, co port 25 blokují, takže vím, že to neprojde a neřeším problém, proč pošta někde tiše mizí....
z pohladu mailserveru je kazda posta cudzia. Ziadna nepatri jemu - je to logicke, je to stroj. To znamena ze strojova analyza mailov (hlavicky alebo aj obsah) sa neda brat za porusenie zakona. Ak samozrejme tie vystupy necita nejaky clovek.
Principialne - posles mail a ten prejde skrz 5 relayov, potom sietou k prijemcovi, kde si to zas pohadze medz isebou antivir, antispam, supne sa to za nat ... budes riesit ktory z tej plejady MTA tvoj mail "cital" neopravnene? Bez toho aby tu spravu celu prijal by ju totizto nevedel ani dorucit.
Většina nic takového v podmínkách nemá a ani to neřeší,nechlubí se tím a spíše to tutlají, než jim to omlátíte o hlavu dle debugu paketů a co odkud chodí. A někteří si dávají např i práci s tím, že simulují ověřování, takže když spojení unesou a klient se začne ověřovat, tak mu vyhoví a vrací na všechno OK, aby to prošlo. Takže jen na případné kontrole SSL to kleintovi zařve a support pak doporučí SSL vypnout. Toť realita. :-)
Po párnví stránce je to dost na vodě. Sice zákon o elektornických komunikacích dává ISPíkům právo provádět akce pro ochranu integrity a spolehlivosti atd sítě, ale nepředpokládá takovéto hormadné únosy. Ale také trestní zákon má svůj názor (1 až 3 roky) na pozměnění nebo potlačení přenosu zpráv telko operátorem, podobně i zákon o některých aspektech informační společnosti činí pak operátora odpovědným za to, co se stane v pípadě, že pozmění nebo přesměruje komunikaci.
Popravdě řečeno jsem se za posledních 10+ let nepotkal poskytovalele poštovního řešení, který by MSA nepodporoval. Na klientské straně mi to s rozvojem mobilních zařízení taky připadá už jako standard. Thunderbird/Icedove port 587 také používá jako standard.
Ale vím, že je to pouze má "anecdotal evidence"...