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 seerveruReceived-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)
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" :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é.
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)
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.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.
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.
helo * =alfa= PTR`
| •• ^
V •• |
A` =beta= #s-ip
helo * ≠ ≠ PTR` |—————+
|
| ^ fcrdns = s-ip ->ptr->a``
V | |
|
A` =beta= #s-ip <— =gamma=
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ánTí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.
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>
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ězcemTo, ž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.
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 ...
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
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)
$ 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:$ 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:$ 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.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.
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.
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ů.)
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...
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.
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ů.
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 :)Problém je v tom, že jste vůbec psal o MX záznamech, když se bavíme o tom, že se k vám připojil nějaký SMTP klient. O kterých MX záznamech teda píšete? Překládáte přes MX to, co klient poslal v EHLO? Nebo jaké jméno překládáte?
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.Ne, já si to – narozdíl od vás – nepletu. Běžná praxe je, že se pro web používá virtual host – tj. na jedné IP adrese jsou hostovány třeba stovky domén. Je takhle řešený každý sdílený webhosting. Když máte webové adresy www.example.com a example.com, zase to obvykle vede na jednu IP adresu. Pokud jedna firma provozuje víc webů (třeba firemní web a produktové weby), zase to bude mít pomocí virtualhostů na jedné IP adrese. Bylo to zavedeno jako rozšíření HTTP 1.0 a v HTTP 1.1 se podpora virtualhostů stala povinnou, protože IPv4 adres bylo málo.
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.Evidentně patříte k té většině, která neví, co CNAME doopravdy znamená a jak se při překladu používá.
Problém je v tom, že jste vůbec psal o MX záznamech, když se bavíme o tom, že se k vám připojil nějaký SMTP klient. O kterých MX záznamech teda píšete? Překládáte přes MX to, co klient poslal v EHLO? Nebo jaké jméno překládáte?
Ne, já si to – narozdíl od vás – nepletu. Běžná praxe je, že se pro web používá virtual host – tj. na jedné IP adrese jsou hostovány třeba stovky domén. Je takhle řešený každý sdílený webhosting. Když máte webové adresy www.example.com a example.com, zase to obvykle vede na jednu IP adresu. Pokud jedna firma provozuje víc webů (třeba firemní web a produktové weby), zase to bude mít pomocí virtualhostů na jedné IP adrese.Nie, virtual host vyuzijete vtedy ak mate weby ktore nevytazia efektivne server, co pri sucastnych servroch nie je problem. Taktiez je to otazka ceny prevadzky toho webu.
To, o čem píšete vy, je rozvažování zátěže, kdy je jeden A/AAAA směrován na více IP adres. To používají větší weby, případně ty, které používají CDN. Ale i v takovém případě zase jedna CDNka typicky obsluhuje spoustu webů, takže na jednu IP adresu vedou spousty záznamů.
Evidentně patříte k té většině, která neví, co CNAME doopravdy znamená a jak se při překladu používá.
example.org. IN A 198.51.100.2
www.example.org. IN CNAME example.org.
Mam za sebou vcelku dost webovych aplikacii, ci to bolo v roli architekta, programatora, komzultanta a nezriedka kedy aj admina. A to nie len nejake shopiky, ale mozem si zaratat aj dva hostingy, telco a dalsie...A to se vám při téhle kariéře podařilo úplně minout to, jak už čtvrt století funguje web? To vás nikdy nenapadlo, jak může webhosting obsloužit násobně víc doménových jmen, než má IP adres?
Prekladate to co vam urcuje SPF zaznam, v pripade ze tam mate 'v=spf1 mx -all' co nie je vobec zriedkave, tak ano, mimo canonical names aj mx zaznamy. V EHLO sa predstavy svojim canonical name. Rovnako PTR zaznam vam da pre IP canonical name, cez MX zaznam si overi ci patri medzi MTA pre danu domenu.O SPF vůbec nebyla řeč.
Nie, virtual host vyuzijete vtedy ak mate weby ktore nevytazia efektivne server, co pri sucastnych servroch nie je problem. Taktiez je to otazka ceny prevadzky toho webu.Ne, virtual host se používá kvůli nedostatku IPv4 adres. S výkonem serveru to nijak nesouvisí. Víc webů na jednom serveru byste klidně mohl mít s více IP adresami na server – dříve, když bylo IPv4 adres dost, se to tak dělalo. Nebo naopak můžete mít doménu nasměrovanou na nějaký reverzní proxy server, který dělá třeba rozvažování zátěže. Takže na provoz webu třeba potřebujete 4 servery, ale jsou schované za proxy serverem s jednou IP adresou. A za tím proxy serverem mohou být schované i jiné weby.
Pouzit pre kazdu domenu A zaznam na tu istu adresu je fakt blby napad. Nie ste potom z PTR zaznamu schopny dostat validne canonical name.Prosím vás, nepište o věcech, o kterých vůbec nic nevíte. Podívejte se na webhostingy typu Wedos nebo CDN jako Cloudflare a uvědomte si, kolik by museli mít IPv4 adres, kdyby pro každé doménové jméno měli samostatnou IP adresu.
Naviac ak sa zmeni IP servru, tak musite v dns menit x zaznamov.To je váš problém, že používáte ne moc chytrou správu DNS záznamů.
Ak tie domeny mate ako alias na jeden A zaznam, tak pri zmene ip menite 1 zaznam.Takový typ záznamu ovšem v DNS neexistuje. Už jsem vám to psal, že nevíte, co CNAME znamená.
Nie, to je koli redundacii. Je to sice mozne pouzit pre rozvazovanie zataze, ale ak mate schopneho admina, tak vam rozbeha load balancer, ktory pouzije oprimalnejsi sposob rozvazovania zataze ako browser, pretoze vidi ako su zatazene servre. A urobi to napr. 2x koli redundancii na 2 roznych IP.Redundance je jeden z důvodů, proč rozvažovat zátěž.
V tom vašem příkladu je www.example.org alias pro kanonické jméno example.org. Zkuste teď ten váš příklad upravit tak, abyste pro domény example.org a www.example.org mohl přijímat e-maily (s pomocí MX záznamů s prioritami). A pak zkuste přidat TXT záznam pro example.org a jiný pro www.example.org (třeba kvůli ověření vlastnictví domény).Kód: [Vybrat]example.org. IN A 198.51.100.2
www.example.org. IN CNAME example.org.
Co z 'www.example.org' a 'example.org' je podla vas alias a co canonical name? A aku mate predstavu ze sa to pouziva? Ja som zvyknuty na to ze resolver pri dotaze na 'www.example.org' zisti ze ide o alias 'example.org' a vrati IP pre canomical name 'example.org'... Ako sa to pouziva podla vas?
A to se vám při téhle kariéře podařilo úplně minout to, jak už čtvrt století funguje web? To vás nikdy nenapadlo, jak může webhosting obsloužit násobně víc doménových jmen, než má IP adres?
O SPF vůbec nebyla řeč.
Ne, virtual host se používá kvůli nedostatku IPv4 adres. S výkonem serveru to nijak nesouvisí. Víc webů na jednom serveru byste klidně mohl mít s více IP adresami na server – dříve, když bylo IPv4 adres dost, se to tak dělalo. Nebo naopak můžete mít doménu nasměrovanou na nějaký reverzní proxy server, který dělá třeba rozvažování zátěže. Takže na provoz webu třeba potřebujete 4 servery, ale jsou schované za proxy serverem s jednou IP adresou. A za tím proxy serverem mohou být schované i jiné weby.
Prosím vás, nepište o věcech, o kterých vůbec nic nevíte. Podívejte se na webhostingy typu Wedos nebo CDN jako Cloudflare a uvědomte si, kolik by museli mít IPv4 adres, kdyby pro každé doménové jméno měli samostatnou IP adresu.
Kanonické jméno v PTR dáte snadno – server má jedno kanonické jméno, třeba server123.example.com. Na to vede PTR záznam. A pak mohou existovat stovky dalších A záznamů, které vedou na stejnou IP adresu, a k nim žádné reverzní záznamy neexistují, nemusí existovat a je to tak v pořádku, protože to nejsou kanonická jména.
To je váš problém, že používáte ne moc chytrou správu DNS záznamů.Ja nerad vymyslam blbiny, radsej hram na bezpecnost. Cim menej duplicit, tym menej priestoru na chyby.
Takový typ záznamu ovšem v DNS neexistuje. Už jsem vám to psal, že nevíte, co CNAME znamená.
Redundance je jeden z důvodů, proč rozvažovat zátěž.Redundancia je sposob ako nahradit pripadny vypadok. Nic ine.
V tom vašem příkladu je www.example.org alias pro kanonické jméno example.org. Zkuste teď ten váš příklad upravit tak, abyste pro domény example.org a www.example.org mohl přijímat e-maily (s pomocí MX záznamů s prioritami). A pak zkuste přidat TXT záznam pro example.org a jiný pro www.example.org (třeba kvůli ověření vlastnictví domény).Preco by som to robil? Za MX zaznam alias nepatri, tam patri common name.
Zase kopa zbytocnych slov. A jeden slameny panak, za druhym. Nemyslim si ze niekto, kto zakryva vlastnu neschopnost halhou bezvyznamnych slov a argumentacnych klamov, je schopny posudit moje kvality :DTo byla jen reakce na kopu vašich zbytečných slov, kdy jste se snažil svými údajnými zkušenostmi zaštítit svá tvrzení, která jsou v rozporu s realitou – což byste zjistil, kdybyste se podíval na příslušná RFC nebo se zkusil podívat na nějaké reálné DNS.
V povodnym kontexom ma vacsiu spojitost ako virtual hosty http servru.Virtual hosty HTTP serveru jsem uváděl jako notoricky známý příklad toho, když různá doménová jména vedou na jednu IP adresu.
Pobavil ste nie len mna, ale aj kolegov, skoda ze sa nechceli stavit, sleduju root. :-/Vaši kolegové mají stejně mlhavé představy o fungování internetu, jako vy? A co děláte? Svářeče, kuchaře, řídíte tramvaj? Doufám, že to není nic s IT.
Na wedose par domen mam, nie je mozne tam zadat PTR nazov, ten sa generuje automaticky z A(AAAA) zaznamu. Nejde to uz len z principu, pretoze PTR zaznamy su v inej zone ako vasa domena a ak nie ste spravca DNS servru tak do tejto zony nemate priamy pristup. Takze nemate ako povedat PTR zaznamom, co je canonical name.Vy v tom teda plavete. PTR záznam uvádí majitel příslušného boku IP adres, protože ten má ve správě příslušnou část DNS stromu. Takže ten váš příklad, kdy někdo generuje automaticky PTR záznamy na základě A/AAAA záznamů, je možný pouze v případě, kdy jeden subjekt spravuje jak DNS pro danou doménu tak mu zároveň patří IP adresy. Tedy například pokud byste měl doménu hostovanou u Wedosu a zároveň ji chtěl nasměrovat na jejich servery.
I ked tak wedosu napisem ze to chcem a ak sa budu cukat, tak im hodim link sem, nech si pracitaju slova odbornika. (minimalne sa pobavia, tak ako ja)Nebojte, ve Wedosu vědí, že provozují mnohem více virtualhostů, než mají veřejných IP adres. Takže vědí, že na jednu IP adresu vede spousta různých A/AAAA záznamů.
Ja nerad vymyslam blbiny, radsej hram na bezpecnost.Tak si to vymýšlení blbin aspoň vynaharzujete tady v diskusi, že?
Cim menej duplicit, tym menej priestoru na chyby.No, evidentně DNS spravujete ručně, což je největší prostor pro chyby.
Tak sa vymacknite co podla vas znamena, fakt sa neviem dockat co splodite :DCNAME říká, že dané doménové jméno je přezdívkou pro jiné jméno. Takže když resolver hledá nějaký DNS záznam (libovolného typu!) pod daným jménem, má hledat záznam stejného typu pod jiným jménem. CNAME tedy není přezdívkou jen pro A/AAAA záznamy, jak se mylně domníváte, ale je přezdívkou pro všechny typy záznamů (s výjimkou DNSSEC záznamů, protože DNSSEC by s tím logicky nefungovalo).
Preco by som to robil? Za MX zaznam alias nepatri, tam patri common name.Třeba proto, abyste předvedl, že rozumíte tomu, co je CNAME záznam. Já jsem netvrdil, že máte dát alias do MX záznamu.
Zameriame sa ale na odpoved na moju otazku. Z vasej odpovede "V tom vašem příkladu je www.example.org alias pro kanonické jméno example.org", je zrejme za CNAME vytvara alias na common name. To je to iste co som uz tvrdil a vy ste sa to snazil rozporovat. Pridete si po psychickej stranke uplne v poriadku?Rozdíl je v tom, že já vím, co ta věta „X je alias pro kanonické jméno Y“ znamená. Vy to nevíte.
vdaka comu je mozne na jednej IP prevadzkovat viacero secure domenPřečtěte si tuhle větu ještě jednou. Pak si uvědomte, že jste to napsal vy. A pak si to přečtěte znova a celé to opakujte tak dlouho, dokud vám nedojde, že to znamená, že k jedné IP adrese musí existovat více jmen, která vedou na tu IP adresu.
SNI ma sice spojitost s HTTP, ale nie taku aku si myslite.Cha cha cha. Vy mne zkoušíte poučovat? Já vím velice dobře, k čemu SNI slouží. Nenapsal jsem o SNI nic, co by bylo v rozporu s tím, jak SNI funguje a k čemu slouží.
Ako, kazdy rozumny prispevok do diskusie je vytany, nikto nie je dokonaly a vacsina diskutuje pre to aby sa nieco naucil.Tak toho využijte. Evidentně se tu toho můžete naučit spoustu.
Takze zacnite diskutovat na urovni, tj. nepiste siahodlhe vykecavakyKdyž nechápete stručné argumenty, nezbývá, než vám to vysvětlit pomalu a s příklady.
nepouzivajte argumentacne faulyJá jsem tu žádný argumentační faul nepoužil.
Ak si v diskusii potrebujete liecit nejake mindraky, tak tym len kopu ludi nastvete. A ak to robite len koli tomu aby ste niekoho nastval, tak budte chlap a hodte nasierat kamionakov do hospody, nie tu na webe ako prizdisrac. Ak si tento zaver zoberiete k srdcu, tak tym potesite nie len mna, ale aj tunajsich diskutujucich, ktory na vas musia reagovat podrazdene, viac nez je zdrave (a to necitam komplet vsetky diskusie).Vaše pokusy poučovat někoho, jak má diskutovat, by mohly mít nějakou váhu, pokud byste vy sám ovládal techniku diskutování alespoň na nějaké minimální úrovni. Tedy například když vám někdo napíše nějaký argument, tak se ho pokusíte pochopit, a pokud se vám nezdá, zkusíte ověřit jeho pravdivost. Váš postup, kdy argumenty protistrany ignorujete a nejste schopen akceptovat ani tak jednoduchou věc, jako příklad s několika doménovými jmény, která jste si mohl velmi jednoduše ověřit, nemá s rozumnou diskusí nic společného.
Ste proste hlupak a ignorant, ktory akurak tak dokaze svoje nedostatky zakryvat mnozstvom zbytocnych slov. Mat vas v zivote na blizku musi byt fakt terno.Když někdo vyvrátí vaše bludy, neplyne z toho, že je hlupák a ignorant. Spíš naopak – nevím, co byste v takovém případě musel být vy, když vaše bludy rozpozná a vyvrátí i hlupák a ignorant.
Ste proste hlupak a ignorant, ktory akurak tak dokaze svoje nedostatky zakryvat mnozstvom zbytocnych slov. Mat vas v zivote na blizku musi byt fakt terno.
Musím uznat, že death walker nepoužívá uplně korektní pojmenování, kanonické jméno slyším prvně a je to takové hospodské vyjadřování.Ve skutečnosti je to termín z RFC zabývajících se doménovými jmény…
Tu se kanonické jméno použije pro řetězec v HELO, jindy se tím myslí název domény.Je to (doménový) název počítače. Který se má dávat do EHLO.
Zajímá mě ale jedna věc, a sice jaké druhy odpovědí se vrací na druhy dotazů na nějakém resolveru.Když se ptáte na konkrétní typ záznamu, vrací resolver daný typ. Když se ptáte bez typu, vrací všechny záznamy s daným jménem, bez ohledu na typ. Když jako odpověď dostane CNAME, vezme kanonické jméno z odpovědi a zeptá se znovu na něj a typ, který jste požadoval. Případně se to opakuje, pokud zase dostane CNAME odpověď (což by neměl, ale musí s tím počítat). Výjimkou je, když požadujete CNAME, ten se vrací rovnou (to rekurzivní hledání by v takovém případě nedávalo smysl).
CNAME vrací CNAME
A vrací CNAME+A
nespecifikováno cname,a,mx
Je to nějaká dobrá vůle resolveru, že to pospojuje?
Ale setkávám se s chováním, že domény které mají CNAME záznam na jinou doménu už jiné záznamy nemajíTak je CNAME definováno – pokud je k nějakému jménu definován záznam CNAME, žádné jiné typy už k tomu jménu nemají být (kromě typů pro DNSSEC, jinak by to nefungovalo).
Ale v některých případech TXT záznam má i alias.Myslíte, že k jednomu jménu existuje CNAME záznam i TXT záznam? To je špatně. Jste si tím jistý, že dostáváte opravdu TXT záznam k tomu jménu, že to není záznam až z cílového jména (z kanonického jména)?
Co z toho je správně, může mít i alias své záznamyNe, nemá je mít. RFC 1034, 3.6.2.
Zajímá mě ale jedna věc, a sice jaké druhy odpovědí se vrací na druhy dotazů na nějakém resolveru.Tak je CNAME definováno – pokud je k nějakému jménu definován záznam CNAME, žádné jiné typy už k tomu jménu nemají být (kromě typů pro DNSSEC, jinak by to nefungovalo).
CNAME vrací CNAME
A vrací CNAME+A
nespecifikováno cname,a,mx
Je to nějaká dobrá vůle resolveru, že to pospojuje?Ale v některých případech TXT záznam má i alias.Myslíte, že k jednomu jménu existuje CNAME záznam i TXT záznam? To je špatně. Jste si tím jistý, že dostáváte opravdu TXT záznam k tomu jménu, že to není záznam až z cílového jména (z kanonického jména)?
Ne, nemá je mít. RFC 1034, 3.6.2.
host -ttxt www.zive.cz
www.zive.cz is an alias for zive.cz.
.....
....
host -ttxt zive.cz
....
.....
host -ttxt zive.cz ; host -ttxt www.zive.cz (nepoužil jsem autoritativní server)Ale www.zive.cz je alias pro zive.cz. Takže ta odpověď, kterou dostanete, je právě výsledek rekurzivního dotazu na zive.cz po té, co resolver zjistil, že www.zive.cz je alias pro zive.cz.
To jsem si myslel, že je nemá mít. Ale otázka je jestli se tím myslí že nemají být v záznamech v zóně a nebo zda je ani nemá vracet (nějaký cizí )resolverKdyž nejsou v zóně, nemůže je vracet ani resolver. Resolver si nemá vymýšlet neexistující záznamy.
No a já právě myslel, jestli je přípustné, aby forwardující resolver při dotazu typu TXT na některý z aliasů vrátil holou odpověď typu CNAME bez TXT (tedy výstup příkazu host jen jednořádkové "dotazovane jmeno" is an alias for "original")To je každé něco jiného. Resolver (systémová knihovna) vrací jen hodnotu požadovaného záznamu (rekurzivní dotazování zajistí sám). host vrací detailnější informace a ptá se na ně konkrétními dotazy, není to jen prosté zavolání systémového resolveru (rekurzivní volání si zajistí sama utilita host).