Neshoda reverzních záznamů u odesílajícího SMTP

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Je problém, když (poslední)SMTP server, má jiné

Kód: [Vybrat]

formát typu mxe1.seznam.cz (mxe2.seznam.cz [SS.S5.76.34])
echo "$rpc" | grep -Evi --color 'from ([^ ]+) \(\1'

Vypíše)
mxe1.seznam.cz (mxe2.seznam.cz xxx.75.76.34])
mxe2.seznam.cz (mxe1.seznam.cz xxx.75.78.34])
smtp.github.com (out-17.smtp.github.com xxx.30.252.200])
smtp.github.com (out-18.smtp.github.com xxx.30.252.201])
smtp.github.com (out-21.smtp.github.com xxx.30.252.204])
smtp.github.com (out-22.smtp.github.com xxx.30.252.205])
smtp.github.com (out-25.smtp.github.com xxx.30.252.208])
smtpx012.webglobe.com (smtpx012-2.webglobe.com xxx.109.150.178])
Ostatních 50 je OK čili tak z vzorku 60. Pozor, je to po sort -u, takže nezohledňuje četnost zpráv od daného seerveru




1 Zajímá mě praxe, jestli to  není chyba, nebo třeba jen flag pro nižší skóre. Vím, že jde nakonfigurovat třeba že se to musí rovnat(uvedený v HELO a zjištěný , případně že nesmí být ve tvaru dynamické IP a taky že třeba zpětný záznam musí existovat  ...

2 A z druhé strany, jestli je nutné aby se HELO řetězec musí rovnat  zpětnému doménovému jménu adresy počítače. TO znamená že mám nějaké ptr název daného počítače, ale v HELO chci uvádět jiné jméno. Samozřejmě obě vedou na tutéž IP

3 Hint: tak se z druhé strany (tedy v případě naslouchání příchozí pošty) odhalí spameři: posílají poštu adresátovi ptrjmeno.domena.cz místo  domena.cz. kupodivu na mx.domena.cz neposílají vůbec


4 Například mxe{1,2} neexistují (může jít ale o historická DNSdata, protože to bylo resolvováno Teď, ale data jsou historická až pár měsíců)... Ono když si vyzkoušíte ty adresy ze seznamu, jsou to unikátní situace, dostanete se do různých grafů., částečně tím, že jak A, tak/nebo PTR záznamy jsou vícepoložkové. Než když je to siutace, kdy to souhlasí přesně 1:1. (což právě ve výpisu nemám, díky parametru -v grepu)

[Reklama]

[Filip Jirsák]

Není jasné, čeho je to výpis, co je jiné. (Ano, vidím, že je rozdíl smtpx012.webglobe.com a smtpx012-2.webglobe.com, ale nenapsal jste, kde jste ty názvy vzal.) Když zkusím přeložit smtpx012.webglobe.com, dostávám 62.109.150.11 a 2001:1ab0:7e1e:151::91, obojí vede zase zpět na smtpx012.webglobe.com. (Je vtipné „začerňovat“ IP adresy, když stejně uvádíte doménová jména.) smtpx012-2.webglobe.com se mi překládá na 62.109.150.178 a to zase zpět na smtpx012-2.webglobe.com.

Pro antispam neexistují žádná pravidla, každý si dělá, co chce. Takže na otázku, jestli je nutné, vám nikdo neodpoví – podle RFC má být za EHLO doménové jméno počítače nebo IP adresa, ale někdo to kontrolovat může, někdo nemusí.

Podobné je to s IP adresou odesílajícího počítače. Podle obecných pravidel by pro ni měl existovat reverzní záznam vedoucí na nějaké jméno, a to jméno by se zase mělo překládat zpět i na uvedenou IP adresu. Ve standardech je should a že by na to nikdo neměl spoléhat, ale spousta e-mailových serverů to kontroluje.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Je to log přijatých. Je to standardní syntaxe v těle zprávy hlavičky Received   -v tomto případě poslední chronologicky,(kromě nějakého LMTP případně vnitřních zpracování). Tedy hlavička která už neprošla odesilatelovou stranou. Snad je to pochopitelné, prostě "ta důležitá" hlavička Received.
a formát je  Received from:  <EHLO> (PTR [IP])

Proto možná proč se podivujete, že to souhlasí, je že zkoumáš  špatné páry. v HELO je verze bez pomlčky (podobně jako u github "smtp."), ale PTR adresy vede na verzi s pomlčkou. Což by nevadilo za předpokladu, že budou propojené tím způsobem, že buď se upraví  EHLO a nebo se upraví PTR) .... A nebo ještě nějak propleteněji, protože "A" I "PTR" umí vícenásobné záznamy

Ono při přemýšlení o tom  se dá dojít až k "6 proměnným" :
1. Prvotní informace: zdrojová srcIP (nelze "zfalšovat") +  EHLO(lze vepsa cokoliv)
Obojí jde "ždímat"  kaskádou ?PTR->?A->?PTR->?A   (Dle mě u IP adresy má smysl jen kolečko [srcIP]->PTR->A->A, u [EHLO] má smysl [EHLO]->A->PTR , přičemž škrtnutě jsou vyznačené údaje, které už nemá cenu zkoumat, pokud se předchozí/jiné liší, ale mohou dát jiný zajímavý výsledek)

Samozřejmě v růžovém světě, kde PTR srcIP je shodný s EHLO je situace jasná a není potřeba {dva,tři,n}krát resolvovat to samé.

Logicky se musí EHLO->A rovnat srcIP (bez nadstandardních kontrol ), o tom není třeba vést diskuzi.
Pak je tu  EHLO a srcIP->PTR, což je to na co tady poukazuju. Pokud vím, tak tahle kontrola je volitelná, není to ani nějaký hard fail.


Potud to ještě ale není žádný mechanismus proti zombie spamerským počítačům (+ nulové složitosti zaregistrovat si doménu,abych si mohl obstarat validní EHLO)

Z toho vyplývá, že kontrola src-IP->PTR se musí dělat vždy (s ohledem na praxi proti boje s zombie , ne s nutností ze strany RFC)


Jsou 2 možnosti-:
PTR se rovná EHLO (což je ten růžový příklad), vše je OK.
PTR je odlišné (na to se ptám), je potřeba udělat o jednu kontrolu navíc : PTR->A'. A to už se musí přeci rovnat, další kolečko už se mi zdá nesmysl.

Je to takhle popsané dobře? Tažkže pro EHLO jedna dopředný překlad a pro srcIP minimálně jeden zpětný a možná navíc   jeden dopředný toho zpětného.



Jo a mimochodem, jenom tak  pod čarou, "nad tou hlavičkou" Received se mi ukazuje hlavička fcrDNS: <PTR>

Kód: [Vybrat]

Received-SPF: Pass/None (mx-in.vvv.vn: domain of (smtp.)github.com
  does (not )designate 192.30.252.204 as permitted sender)
  receiver=mx-in.vvv.vn; identity=mail-from/helo;
  client-ip=192.30.252.204 helo=smtp.github.com;
  envelope-from=<noreply@github.com>
X-fcrDNS: out-21.smtp.github.com
Received: from smtp.github.com (out-21.smtp.github.com [192.30.252.204])
...
From: notifications@github.com(fun fact)

[Filip Jirsák]

Proto možná proč se podivujete, že to souhlasí, je že zkoumáš  špatné páry.

Ne, neporovnávám špatné páry. Vzal jsem normálně vámi uvedené doménové jméno, přeložil jsem ho na IP adresy, a takto získané IP adresy jsem reverzním záznamem přeložil na doménové jméno.

Ono při přemýšlení o tom  se dá dojít až k "6 proměnným" :
1. Prvotní informace: zdrojová srcIP (nelze "zfalšovat") +  EHLO(lze vepsa cokoliv)
Obojí jde "ždímat"  kaskádou ?PTR->?A->?PTR->?A   (Dle mě u IP adresy má smysl jen kolečko [srcIP]->PTR->A->A, u [EHLO] má smysl [EHLO]->A->PTR , přičemž škrtnutě jsou vyznačené údaje, které už nemá cenu zkoumat, pokud se předchozí/jiné liší, ale mohou dát jiný zajímavý výsledek)

Když se server představí nějakým jménem (v EHLO), dává smysl kontrolovat, zda se nepředstavil cizím jménem, takže převést uvedené DNS jméno na IP adresu a zkontrolovat, zda se mezi vrácenými IP adresami je zdrojová adresa serveru. Případně můžete kontrolovat i PTR záznam zdrojové adresy, jestli vede i na uvedený název. Žádná další kolečka nemá smysl dělat, protože byste kontroloval pořád dokola to samé.

Pak je tu  EHLO a srcIP->PTR, což je to na co tady poukazuju. Pokud vím, tak tahle kontrola je volitelná, není to ani nějaký hard fail.

Všechny kontroly jsou volitelné a záleží na tom, kdo ty kontroly uplatňuje, jak bude zacházet s výsledkem.

PTR se rovná EHLO (což je ten růžový příklad), vše je OK.
PTR je odlišné (na to se ptám), je potřeba udělat o jednu kontrolu navíc : PTR->A'. A to už se musí přeci rovnat, další kolečko už se mi zdá nesmysl.

Je to takhle popsané dobře? Tažkže pro EHLO jedna dopředný překlad a pro srcIP minimálně jeden zpětný a možná navíc   jeden dopředný toho zpětného.

Není potřeba dělat žádné kontroly, je jenom na vás, jaké kontroly se rozhodnete dělat. Jako první jste popsal kontrolu názvu v EHLO, to nějaký smysl dává. Je na vás, jestli budete akceptovat chybný název nebo ne. Nezávisle na tom můžete kontrolovat vazbu mezi dopředným a zpětným DNS záznamem.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Zkusím to graficky.Srovnávají se řádky, tudíž vstupní údaje nejsou na jednom řádku, ale v poli A1 a B2 jako v šachu

Kód: [Vybrat]


helo *  =alfa=    PTR`
                         
  |       ••        ^ 
  V       ••        | 
                         
  A`    =beta=  #s-ip 
 
Beta kontroluje shodnost IP, tedy zjednodušeně jestli překlad helo odpovídá IP.
Alfa kontroluje, jestli ip adresa je posvěcená providerem.  S jedním  (potenciálním  a ne vždy) neduhem, že dynamické "adsl" ip adresy typu xx-yy-yy-yy-cust.vodafone.cz toto splní vždy  (obousměrně) . Plus ještě pokud tedy není port 25 blokován
Malými písmeny jsou vstupní hodnoty (#neměnná ip a * zadané ehlo)
S čárkou ` jsou odvozené hodnoty.

A můj dotaz,  na situaaci. , když alfa kontrola selže.  Zda je to legitimní. Za druhé, je nutné udělat to druhé kolečko (zdaleka ne 6)

Kód: [Vybrat]


helo *  ≠    ≠    PTR` |—————+
                             |
  |                 ^     fcrdns = s-ip ->ptr->a``
  V                 |        |
                             |
  A`    =beta=  #s-ip   <— =gamma=
 
Tedy když kontrola alfa selhala, proběhne kontrola gamma, že se jednou reverzní záznam opět převede na IP a teď už to musí sedět.

[Reklama]

[Filip Jirsák]

Já bych doporučil místo šachové terminologie použít raději IT terminologii, konkrétně pojmy protokolů SMTP, DNS apod.

Jste v situaci, kdy provozujete SMTP server a někdo se vám pokouší doručit e-mail. Takže znáte jeho IP adresu(ze které se k vám připojil, IP adresa klienta, nazvěme ji třeba A) a text, který předal v EHLO (nazvěme jej třeba T).

Ta vaše beta tedy asi přeloží název poskytnutý v EHLO (T) přes A/AAAA záznam na IP adresu(y) a ověří zda jedna z nich je IP adresou klienta (A).

Co je alfa netuším:

Alfa kontroluje, jestli ip adresa je posvěcená providerem.

Co znamená „posvěcená providerem“? Napište to v IT terminologii.

Plus ještě pokud tedy není port 25 blokován

Tím myslíte „pokud není na straně klienta blokována odchozí TCP komunikace na port 25“, pak to nemusíte řešit, protože kdyby ta komunikace blokována byla, klient se k vám vůbec nepřipojí. Pokud tím myslíte něco jiného, napište to IP terminologií a přesně.

Zda je to legitimní.

Pokud řešíte reverzní záznamy a dopředné záznamy, na to jsou jenom doporučení, nic závazného.

Za druhé, je nutné udělat to druhé kolečko (zdaleka ne 6)

Nutné není nic. Děláte antispamovou kontrolu, na to nejsou žádná pravidla. Je to vaše rozhodnutí, zda se vám nějaká kombinace líbí nebo nelíbí. Někdo třeba považuje klienta za spammera jenom proto, že v DNS názvu jsou číslice.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Končím, du si dát opium. a až to vyprchá, dám si měsíc přestávku a zkusím to natočit formou youtube videa, udělat tam nějaké vizualizace jako v intru Reporteři ČT.

Posvěcená providerem je novinářská zkratka, že to není zombí počítač (obrazně), tedy že reverzní záznam připojivšíse ip adresy sedí  s HELO řetězcem  , a pokud, ne tak sedí s dopředně-zpětným-záznamem. (což je úhlavní bod dotazu)

Ta blokace portu se netýkal kontroly alfa(kontroly PTR),ale  té "správnosti" F+c+RDNS záznamů u ip providerů koncových uživatelů, že i když tedy ta kontrola by seděla (pak tu jsou ty zmíněné kontroly, co hledají shluk čísel v revezním názvu), tak obvykle bývá odchozí port 25 těchto přípojek blokován.

PS: nádherné a překvapivé (a pro vás důležité), je, že se v těchto příkladech vystačí s unikátními  a rozlišitelnými pojmy:
-HELO řetězec
- - A záznam ( HELO řetězce)
-ip adresa
- - reverzní záznam nebo ptr záznam ( ip adresy)
- - - fcrdns (revezního  záznamu(ip adresy)) - i doslovný překlad dopředně ověřený reverzní překlad sedí, i když to slovo ověřený je zavádějící. Ověřený je jen, když souhlasí s ip adresou

[_mbily]

Mohu-li Vám radit, tak z řetězce uvedeného v HELO/EHLO lze jen těžko něco podstatného vyvozovat. Bylo tomu tak vždy, a je tomu tak i dnes. Rovněž tak ze vztahu HELO/EHLO k ip adrese či dns jménu smtp klienta. Vizte tento výběr z pár minut reálného poštovního provozu dnešního dne:

client=mail-vi1eur04on0630.outbound.protection.outlook.com[2a01:111:f400:fe0e::630], helo=<EUR04-VI1-obe.outbound.protection.outlook.com>
client=relay.netic.dk[2a03:dc80:0:f136::218], helo=<mxout02.netic.dk>
client=mailgate.tugraz.at[129.27.2.197], helo=<mxesa1.tugraz.at>
client=budka.sunnysoft.cz[86.49.189.186], helo=<host-22.sunnysoft.cz>

Můžete ty jednotlivé případy analyzovat a hádat, zda jsou to servery s více interfejsy, jestli třeba není ve hře load-balancer, zda ip adresa má omylem více PTR záznamů apod. Bude se tahhle snažit hádat i Váš antispam?

Použil jste pojem něco jako ověřený překlad. I na to pozor. Očekával bych, že v dnešním světě k tomu přidáte nějaké další pojmy. Když se bavíme o smtp, tak třeba smtp spojení zabezpečené pomocí TLS, s platným certifikátem (obou stran?), vydaným respektovanou certifikační autoritou, zabezpečení DNS komunikace na bázi DNSSEC, nad tím kontrola certifikátu podle DANE.

[Zopper]

Já bych jen doplnil, že schopnosti (a snaha) nejlepších spamerů jsou nad schopnostmi a snahou některých správců. Stejně, jako inteligence nejchytřejších medvědů je vyšší, než nejhloupějších turistů. Takže tak, jako v národních parcích nemůžou udělat popelnice, které by nedokázal otevřít žádný medvěd, protože pak by se do nich nedostali ani někteří turisti, takováhle ochrana proti spamu zaručeně zablokuje nějaký legitimní provoz. Můžete akorát doufat, že s vaším serverem nebude chtít komunikovat nikdo, kdo si před 20 lety rozjel mail server a od té doby jeho konfiguraci nezměnil.

[Filip Jirsák]

Končím, du si dát opium. a až to vyprchá, dám si měsíc přestávku a zkusím to natočit formou youtube videa, udělat tam nějaké vizualizace jako v intru Reporteři ČT.

Pokud chcete poradit, raději přestaňte vymýšlet hlouposti a místo toho se naučte základní IT terminologii a používejte ji. Mám takové tušení, že až si tu terminologii ujasníte, polovina vašich otázek najednou zmizí.

Posvěcená providerem je novinářská zkratka, že to není zombí počítač (obrazně), tedy že reverzní záznam připojivšíse ip adresy sedí  s HELO řetězcem

To, že reverzní záznam k IP adrese vede na stejný název jako je v EHLO, nijak neznačí, že nejde o zombie počítač. Protože zjistit název z reverzního záznamu je pro zombie počítač triviální, takže spamující software snadno nastaví správné EHLO (pokud reverzní záznam existuje).

a pokud, ne tak sedí s dopředně-zpětným-záznamem. (což je úhlavní bod dotazu)

Žádný dopředně-zpětný záznam neexistuje. Zatím to vypadá, že váš rádobyhumorný jazyk má skrývat to, že se v problematice moc nevyznáte.

Ta blokace portu se netýkal kontroly alfa(kontroly PTR),ale  té "správnosti" F+c+RDNS záznamů u ip providerů koncových uživatelů, že i když tedy ta kontrola by seděla (pak tu jsou ty zmíněné kontroly, co hledají shluk čísel v revezním názvu), tak obvykle bývá odchozí port 25 těchto přípojek blokován.

Ono totiž účelem DNS záznamů je poskytovat informace k názvům (zejména IP adresy) a případně názvy k IP adresám. Ne řídit přístup k SMTP serverům.

PS: nádherné a překvapivé (a pro vás důležité), je, že se v těchto příkladech vystačí s unikátními  a rozlišitelnými pojmy:

Tak ty pojmy zkuste začít používat.

[Death Walker]

1 Zajímá mě praxe, jestli to  není chyba, nebo třeba jen flag pro nižší skóre. Vím, že jde nakonfigurovat třeba že se to musí rovnat(uvedený v HELO a zjištěný , případně že nesmí být ve tvaru dynamické IP a taky že třeba zpětný záznam musí existovat  ...

Za EHLO(HELO) nasleduje skutocny nazov hostu (canonical name) ktory suvisi s A alebo AAAA zaznamom v dns. PTR zaznam vznika na zaklade A alebo AAAA zaznamu, ak najdete reverzny zaznam, ktory nekoresponduje s A alebo AAAA zaznamom, tak je chyba u prevadzkovatela DNS.

Co je

tvar dynamickej IP

? Dynamicka adresa viem co je, viem ako vznikne. Mna skor zaujima co si predstavujete pod tou frazou vy.

2 A z druhé strany, jestli je nutné aby se HELO řetězec musí rovnat  zpětnému doménovému jménu adresy počítače. TO znamená že mám nějaké ptr název daného počítače, ale v HELO chci uvádět jiné jméno. Samozřejmě obě vedou na tutéž IP

Za HELO musi byt canonical name. Ak mate v MX zaznamoch pre danu domenu viac SMTP servrov, tak sa kazdy ohlasi svojim skutocnym menom (hostname). V DNS by nemali byt dva zaznamy ktore vedu na tu istu IP.

3 Hint: tak se z druhé strany (tedy v případě naslouchání příchozí pošty) odhalí spameři: posílají poštu adresátovi ptrjmeno.domena.cz místo  domena.cz. kupodivu na mx.domena.cz neposílají vůbec

Tak to neposielaju len  spamery, tak to normalne funguje. Klient si z MX zaznamu pre domenu zisti nazvy SMTP servrov, to su tie ktore su v A alebo AAAA zaznamoch, tym padom aj v PTR zazname.

4 Například mxe{1,2} neexistují (může jít ale o historická DNSdata, protože to bylo resolvováno Teď, ale data jsou historická až pár měsíců)... Ono když si vyzkoušíte ty adresy ze seznamu, jsou to unikátní situace, dostanete se do různých grafů., částečně tím, že jak A, tak/nebo PTR záznamy jsou vícepoložkové. Než když je to siutace, kdy to souhlasí přesně 1:1. (což právě ve výpisu nemám, díky parametru -v grepu)

Takze, mail servery pre domenu seznam.cz:

Kód: [Vybrat]

$ dig seznam.cz MX
seznam.cz.              48      IN      MX      20 mx2.seznam.cz.
seznam.cz.              48      IN      MX      10 mx1.seznam.cz.
To odpoveda adresam:

Kód: [Vybrat]

$ dig mx1.seznam.cz
mx1.seznam.cz.          288     IN      A       77.75.76.42
mx1.seznam.cz.          288     IN      A       77.75.78.42
$ dig mx2.seznam.cz
mx2.seznam.cz.          10      IN      A       77.75.78.32
mx2.seznam.cz.          10      IN      A       77.75.76.32
Reverzne zaznamy:

Kód: [Vybrat]

$ dig -x 77.75.76.42
42.76.75.77.in-addr.arpa. 3046  IN      PTR     mx1.seznam.cz.
$ dig -x 77.75.78.42
42.78.75.77.in-addr.arpa. 99    IN      PTR     mx1.seznam.cz.
$ dig -x 77.75.76.32
32.76.75.77.in-addr.arpa. 3600  IN      PTR     mx2.seznam.cz.
$ dig -x 77.75.78.32
32.78.75.77.in-addr.arpa. 300   IN      PTR     mx2.seznam.cz.
Vsetko je v najlepsom poriadku co sa tyka DNS. Vsetky PTR su unikatne a koresponduju s A zaznamom.

Par rad na zaver:
1. Fakt nieco spravte s tou terminologiou. Toto je ako ked casnikovy v Mexiku zahlasite "el rizek, el brambor". Tiez si nebude isty tym ci mu nahodou nenadavate.

2. To co najdete na SO a diskusiach, nepiste priamo do terminalu. Metoda pokus-omyl vam na tej instancii zanecha bordel, ktory pozmeni chovanie tak ako to nechcete. Pouzite nap. ansible, s tym ze citive udaje ulozite do vaultu. Pri vacsich zmenach a ked budete mat pocit ze je hotovo, tak povodny server zmazte a pustite playbook nanovo. Naviac ten playbook mozete ukazat niekomu kto vie ako to konfigurovat a moze vam rovno napisat co nerobite dobre.

3. Ak sa vam nechce citat manualy, co zrejme nechce (terminologia), tak si zaplate niekoho kto to nakonfiguruje miesto vas.

Vsetky 3 body platia nie len pre mail server ale aj pre ostatne servre co si chcete hostovat doma.

[Filip Jirsák]

Za HELO musi byt canonical name. Ak mate v MX zaznamoch pre danu domenu viac SMTP servrov, tak sa kazdy ohlasi svojim skutocnym menom (hostname).

Bavíme se o názvech SMTP klienta, MX záznamy s tím nemají nic společného. To, že nějaké zařízení odesílá e-maily pro nějakou doménu vůbec neznamená, že to samé zařízení bude nějaké e-maily přijímat.

V DNS by nemali byt dva zaznamy ktore vedu na tu istu IP.

Pokud je řeč o MX záznamech (které ovšem nesouvisí s původní diskusí), pak je to pravda. Pokud o A/AAAA záznamech, pak to v žádném případě není pravda – na stejnou IP adresu můžou vést stovky A záznamů. (U AAAA bych spíš preferoval samostatné IPv6 adresy, ale i tam není nic proti ničemu, když na stejnou IPv6 adresu povedou desítky či stovky AAAA záznamů.)

Vsetky 3 body platia nie len pre mail server ale aj pre ostatne servre co si chcete hostovat doma.

Nicméně pro poštovní server to platí daleko víc, než pro jiné servery. Když špatně nakonfigurujete DNS nebo HTTP server, poškodíte maximálně své vlastní uživatele (ty, kteří chtěli třeba jít na váš web). Když špatně nakonfigurujete poštovní server, bude rozesílat spam a viry, a budete tím škodit celému světu.

[Death Walker]

Bavíme se o názvech SMTP klienta, MX záznamy s tím nemají nic společného. To, že nějaké zařízení odesílá e-maily pro nějakou doménu vůbec neznamená, že to samé zařízení bude nějaké e-maily přijímat.

Kazdy host ktory sa prihlasi ako klient k SMTP servru, sa predstavi za HELO svojim canonical name, vratane podmnoziny MTA uvedenych v MX zazname.

Pokud je řeč o MX záznamech (které ovšem nesouvisí s původní diskusí), pak je to pravda. Pokud o A/AAAA záznamech, pak to v žádném případě není pravda – na stejnou IP adresu můžou vést stovky A záznamů. (U AAAA bych spíš preferoval samostatné IPv6 adresy, ale i tam není nic proti ničemu, když na stejnou IPv6 adresu povedou desítky či stovky AAAA záznamů.)

Tak mozete si ich tam dat, ale pravdepodobne vam to rozbije PTR zaznamy. Bezpecnejsie je pouzivat aliasy.

Nicméně pro poštovní server to platí daleko víc, než pro jiné servery. Když špatně nakonfigurujete DNS nebo HTTP server, poškodíte maximálně své vlastní uživatele (ty, kteří chtěli třeba jít na váš web). Když špatně nakonfigurujete poštovní server, bude rozesílat spam a viry, a budete tím škodit celému světu.

To na zaver bolo myslene skor tak aby to bolo replikovatelne a auditovatelne...

[Filip Jirsák]

Kazdy host ktory sa prihlasi ako klient k SMTP servru, sa predstavi za HELO svojim canonical name, vratane podmnoziny MTA uvedenych v MX zazname.

Ano, každý SMTP klient se serveru představí svým jménem v EHLO. MX záznamy v tom nehrajou vůbec žádnou roli – ten klient nemusí být vůbec schopen přijímat e-maily.

Pro doménu exmaple.com klidně mohou e-maily rozesílat jenom následující klienti:

• mx1-outgoing.example.com
• mx2-outgoing.example.com

Zatímco MX záznamy budou nasměrované na servery:

• mx1-incoming.example.net
• mx2-incoming.example.net
• mx3-incoming.example.net

a bude to tak naprosto v pořádku.

Tak mozete si ich tam dat, ale pravdepodobne vam to rozbije PTR zaznamy. Bezpecnejsie je pouzivat aliasy.

Ne, A/AAAA záznamy vedoucí na stejnou IP adresu žádné PTR nerozbijí. Podívejte se na libovolný sdílený webhosting nebo cloudovou API gateway, na jednu IP adresu tam budou směřovat desítky nebo stovky záznamů.

Používat aliasy (CNAME záznamy) je naopak nebezpečné – znamenají totiž něco jiného, než si většina lidí myslí.

[Death Walker]

Aha, chapem v podstate sa nerozporujeme, len ste zamrzol na vlastnej domienke ako som to myslel. Pisal som "...kazdy klient sa prihlasi...", nepisal som nic na sposob "... kazdy server v MX zaznamoch je klient SMTP...", ak to niekde vidite tak budte konkretnejsi 

Nepletiete si to tak trochu? Bezna prax je ze jedno domenove meno je mapovane na viacero IP adries. Kdezto s pripadom ze viacero canonical names mapovanych na jednu IP je nastastie malo caste.

Ad CNAME, neviem k comu je urcene vo vasom vesmire, ale vacsinou sa pouziva k tomu podla toho coho je nazvane. Mapuje alias na Canonical NAME.