Dotaz: Oprava DNS záznamů

[Milan Dobeš]

Ahoj, potřeboval bych pomoci s opravou DNS záznamů několika domén. Máme potíž s doručováním mailů, některé se ztrácejí a jeden významný zákazník mi poslal protokol z mxtoolbox.com, ve kterém jsou dvě chyby a dvě varování.

Stávající situace je taková, že pro domena1.cz mám od O2 (iProvider) nastavený reverzní záznam a hlavní ve firmě používaná doména je domena2.cz. Vše je na jedné veřejné IP adrese.

Nyní ty chyby:

kategorie http: domena2.cz: The underlying connection was closed: The connection was closed unexpectedly. (http://domena2.cz)

Zde asi vím, záznam bez www má jinou (špatnou) IP adresu, než záznam s www.

kategorie dmarc: domena2.cz: Missing or Invalid Record

Tady jsem úplně mimo, mám na doméně nastavené SPF i DKIM, ale tady vůbec nevím jak na to. Potřeboval bych záznam nastavit co nejpropustněji, aby byl přijemce co nejtolerantnější.

Nyní ty varování:

kategorie: smtp: jmeno.domena2.cz: Reverse DNS does not match SMTP Banner

Také jsem mimo, asi to nebude mít nic společného s reverzním záznamem k IP adrese.

kategorie: smtp: jmeno.domena2.cz: Warning - Does not support TLS.

Také to samé. Nevím o co se jedná.

Poradíte mi prosím, ředitel mi sedí za krkem

---

---

Odpovědi

[NN]

Ja bych jako uplnou fatalitu videl to posledni. Imho kazda hlaska hovori sama za sebe. Vezmi to postupne zjisti si co to znamena a jak to opravit.

[Milan Dobeš]

No super, fakt dík. Moc jsi mi pomohl. Zatím mám opravený tu první chybu. Kdybys poradil alespoň s tím dmarc.

[NN]

DMARC je to popsane do detailu..

[MMMMMMMMM]

DMARC ani TLS není to nejdůležitější. TLS doporučuju zprovoznit v každém případě. IMHO nejdůležitější je korektní PTR záznam, vyhovující SMTP banner, to je naprostý základ.

Pěkný článek o DMARC - https://www.skelleton.net/2015/03/21/how-to-eliminate-spam-and-protect-your-name-with-dmarc/
Nástroje k otestování - https://socl.cz/online-nastroje-na-otestovani-postovniho-serveru

[Andrej]

Tak TLS je nezbytnost, jinak to není mail server, ale hračka pro děti. Takže tím bych začal. Já používám certifikáty od autority StartCom, ale alternativ je spousta. (Na vnitřní síti a IPSec sítích s předem známými klienty mám taky vlastní autoritu, která mi ušetří jednání s veřejnou autoritou, která navíc rozhodně nepodepíše fiktivní TLD a další výdobytky — vyžaduje standardní DNS záznamy.

S provozem serveru bez TLS se dnes už zkrátka nepočítá. Některé freemaily dokonce už zobrazují velká červená varování, když ukazují maily doručené bez TLS, jako že mohly být někde cestou pozměněné nebo přečtené neoprávněnou třetí stranou.

Aby DKIM, SPF a DMARC dával vůbec aspoň náznakem smysl, je třeba mít DNSSEC. To je asi jasné. Jakmile funguje DNSSEC, pak je ještě vhodné všechna navazující nastavení (DKIM, DomainKeys, SPF, DMARC) prověřit pomocí různých online validátorů a odstranit případné nedostatky.

Se zpětným mapováním v DNS je to prostě tak, že je leckdy potřeba mít víc PTR záznamů. Takže mám-li mx.domena1.org AAAA abcd::ef00 a taktéž mx.domena2.org AAAA abcd::ef00, pak musím mít příslušné 0.0.f.e…d.c.b.a PTR mx.domena1.org a totéž pro mx.domena2.org, aby SMTP protistrana vždy našla příslušné zpětné mapování. Hledá ho podle toho, jak se server přes SMTP představí (za EHLO a případně ještě implicitně na dalších místech protokolu).

[Filip Jirsák]

Především by to chtělo najít si někoho, kdo se vám o poštovní server a DNS bude starat, protože zrovna poštovní server nejde spravovat způsobem „nerozumím tomu, nastavím něco, co mi poradili v diskusi“.

Ty popsané chyby a varování jsou taková směska, která sama o sobě nic moc neznamená.

První – http://domena2.cz – to s e-maily vůbec nijak nesouvisí, pro řešení problémů s e-maily to můžete klidně ignorovat.

Druhé – DMARC. DMARC je jakási nadstavba nad SPF a DKIM, která říká, co se pro danou doménu používá, jak to má být hodnoceno, jaké množství e-mailů vyhodnocovat a kam se mají posílat chyby. Ty poslední dvě části jsou nejdůležitější – umožňují nasazovat politiku postupně. Řeknete, že se má vyhodnocovat třeba 10 % e-mailů a že vám má být poslán protokol s výsledkem. Přijímající server pak vyhodnotí jen uvedených 10 % e-mailů (a zbytek propustí, jako by tam DMARC nebyl), a pošle vám o tom zprávu, ze které můžete zjistit, že třeba odmítl některé e-maily, které by projít měly. Vy pak můžete konfiguraci politiky upravit (a nebo zajistit, aby e-maily byly odesílány správnou cestou).

Co nejtolerantnější bude příjemce tehdy, pokud DKIM, SPF i DMARC vůbec mít nebudete. Akorát to zároveň znamená, že veškerý spam odeslaný jakoby z vaší domény projde příslušnými filtry příjemce a dostane se až k rozpoznávání dle obsahu – takže vaše doména bude náchylná k tomu, aby byla vyhodnocována jako spam.

Třetí – reverse DNS a SMTP Banner. Poštovní klient by měl v hlavičce odesílat jméno serveru, které by mělo po překladu přes DNS vést zpět na tento server. A zároveň by k IP adrese serveru měl existovat reverzní DNS záznam (odkazující na jméno), a překlad toho jména by měl vést opět na stejnou IP adresu. Některé poštovní servery některé z těch názvů porovnávají – nejjednodušší je, když má server nějaké jméno, tohle jméno se překládá na jeho IP adresu, k IP adrese existuje reverzní záznam, který vede opět na stejné jméno, a tímto jménem se server také představuje při SMTP komunikaci.

Čtvrté – TLS. Váš server při příjmu e-mailů nepodporuje TLS, nebo-li šifrované spojení. Dnes si můžete nechat od Let'S Encrypt vystavit důvěryhodný certifikát zdarma, příchozí komunikace tak může být šifrována a nikdo nemůže e-maily odposlouchávat na cestě. Doporučuju na šifrování příležitostně přejít, dnes je tlak na šifrování na webu (HTTPS), dá se očekávat, že v budoucnu bude podobný tlak i na šifrování při přenosu e-mailů. Podobně je dobré nastavit, aby váš klient používal šifrované spojení, když komunikuje s jinými servery. Opět to není úplně jednoduché nastavit, je dobré, když se server pokusí odeslat e-mail nešifrovaným spojením, když šifrované selže, na druhou stranu to je přesně způsob, kterým bude někdo útočit – bude se snažit přesvědčit váš server, že šifrované spojení s cílovým serverem není možné.

[Milan Dobeš]

Moc děkuji za Vaši odpověď, problém mě skutečně trápí.

S prvním Vaším odstavcem nelze než souhlasit, bohužel problém musím nějak kloudně vyřešit, pokud možno dnes.

První - vyřešeno.

Čtvrté - pravděpodobně vyřešeno, v LOGu se objevují řádky se STARTTLS server i client a Verify=OK.

Třetí - s tím je největší potíž. Používám sendmail a pokud vím, jméno které odesílá ve hlavičce je jméno serveru a nelze je nijak nastavit. Navíc jméno je z domena2 a reverzní záznam veřejné IP adresy je z domena1. A ještě k tomu jsou kvůli spolehlivosti severy dva v Heartbeat clusteru a pouze jeden aktuálně dělá poštovní server (a samozřejmě se nejmenují stejně).

Druhé - SPF a DKIM mi nějakou dobu pracují, o dmarc vím ode dneška, pomohl by mi příklad nastavení DNS záznamu s nějakým malým komentářem.

Ještě jednou děkuji

[Milan Dobeš]

To, že jsou servery v clusteru, nevadí – v tomto případě vystupují v roli klienta. Každý komunikuje ze své IP adresy, daná IP adresa by měla mít alespoň jeden reverzní záznam, dané jméno by mělo vést zpět na danou IP adresu a to jméno by mělo být použité i v poštovním klientovi. Nerozumím tomu, proč je ve vašem případě jméno serveru jiné než reverzní záznam veřejné IP adresy – to je přesně to, proč některé servery tohle kontrolují, protože ve „standardní“ konfiguraci se tahle jména shodují.

Ale našel jsem na internetu několik příkladů, které obsahují následující řádek:

define(`confHELO_NAME', `servername.example.com')dnl

Takže i sendmail by měl umět změnit jméno, kterým se představuje.

Nějaké příklady konfigurace DMARC má třeba Google: https://support.google.com/a/answer/2466580?hl=en nebo Add a DMARC record.

[Milan Dobeš]

Díky moc, už je mi to celkem jasné, detailní popis DMARC záznamu jsem našel na root.cz. K těm IP adresám, servery jsou na lokální síti s vlastním DNS serverem a ven komunikují přes firewall. Reverzní záznam veřejné IP adresy je z historických důvodů na první doménu. Dnes je domén několik a na všechny (a ze všech) chodí pošta.

Díky za tu konfiguraci sendmailu, tu určitě použiji a dám tak do pořádku alespoň jméno, kterým se sendmail představuje se jménem v DNS. Reverzní záznam k veřejné IP adrese asi nechám nastavit pro nejpoužívanější doménu.

Ještě jednou díky za cenné rady!

[Milan Dobeš]

Nezáleží na tom, v jaké doméně je ten reverzní záznam (ono by tedy nemělo záležet ani na tom reverzním záznamu, ale jsou servery, kterým na tom záleží). Důležité je, aby ten reverzní záznam byl stejný jako to, jak se hlásí sendmail při odesílání, a aby dopředný překlad vedl zase na tu stejnou IP adresu. Takže ten reverzní záznam klidně můžete nechat, akorát změňte jméno sendmailu.

[Milan Dobeš]

jeste bych doplnil, ze na diagnostiku problemu se docela hodi napriklad MxToolbox Investigator.

Do MX zaznamu vsech domena uvest mail.domena1.cz, A zaznam pro mail.domena1.cz verejna IP adresa, k verejne IP adrese PTR zaznam mail.domena1.cz a v konfiguraci sendmailu uvest to jmeno, kterym se ma server predstavovat.

[Milan Dobeš]

ok, moc děkuji za upřesnění, dnes to již funguje jak má, nicméně ty DNS dle Vašeho návodu určitě nastavím.

[Filip Jirsák]

Já bych jen upřesnil, že upřesnění klasický míchá dohromady klienta a server. On se ten program/služba obvykle nazývá „poštovní server“, ale ve skutečnosti vystupuje ve dvou rolích – když e-maily přijímá, je to server, když je odesílá, je to klient (a jsou možné i takové konfigurace, že dělá jenom jedno z toho).

MX záznamy vedou na váš server, a je celkem jedno, jak je pojmenovaný. Takže není problém mít MX záznamy pro 5 domén, které povedou na 5 různých názvů serveru, a ty se všechny přeloží na jednu IP adresu (např. můžete mít server mail.example.com pro doménu example.com, mail.example.net pro example.net a mail2.example.com pro doménu example.org). Na reverzních adresách v tomto případě nezáleží, stejně jako nezáleží na tom, jak se server představuje (a už vůbec nezáleží na tom, jak se představuje klient běžící na stejné IP adrese) – každý je rád, že se může nějakého e-mailu zbavit a předat jej k doručení někomu jinému, takže když váš server e-mail přijme, je odesílající klient spokojený, a nebude zkoumat nějaké reverzní záznamy a názvy.

Pojmenování je důležité, když váš poštovní server vystupuje v roli klienta – protože některé servery podle toho pojmenování „rozpoznávají“ spammery. Tam je důležité, aby jméno, kterým se představuje váš server (v roli klienta) bylo stejné, jako jméno, na které se přeloží (pomocí reverzního záznamu) IP adresa, pod kterou se klient připojuje. Úvaha „antispammerů“ je asi takováhle – legitimní poštovní server má stálé jméno a jeho správce ho zná, takže ho poštovnímu serveru nakonfiguruje. Spamující napadený počítač je schovaný někde za NATem, takže tam spamovací robot nezná jméno, pod jakým bude vystupovat na internetu – musel by se připojit někam ven, tam zjistit, jakou má vlastně veřejnou IP adresu, tu pak přeložit a teprve pak ji začít používat. A doufat, že příští spojení nepůjde ven přes jinou IP adresu. Dále je potřeba, aby tohle doménové jméno (název serveru a reverzní záznam k IP adrese) vedlo zase na tu původní IP adresu. Tak by to mělo být podle RFC a „antispammeři“ opět předpokládají, že správce legitimního poštovního serveru to nechá nastavit správně, kdežto spamující počítač někde na ADSL to bude mít špatně, protože na to ISP kašle. „Antispammeři“, kteří definitivně přešli na temnou stranu síly, pak dokonce vyhodnocují, jak ten reverzní název vypadá, a pokud se jim zdá, že je automaticky generovaný, dají danou IP adresu rovnou na blacklist (a požadují výkupné za její odstranění).