Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 20 21 [22] 23 24 ... 375
316
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.

Že jsou má slova zbytečná jsem dopředu nemohl tušit. Přispěl jste do diskuse, tak jsem očekával, že chcete diskutovat. A že vyvrácení vašich omylů pro vás bude užitečné. Kdybyste rovnou na začátku napsal, že vás nezajímá nic, co by vyvracelo vaše tvrzení, nebudu se obtěžovat diskusí s vámi. Jenom bych pro ostatní napsal, jak je to doopravdy, kdyby se tu náhodou objevil někdo, kdo by toho věděl stejně málo, jako vy.

Tak nějak se mi zdá, že spoustu zbytečných slov jste tu napsal spíš vy. Protože jste tu toho napsal hodně, ale marně v tom hledám nějaký argument na podporu vašeho tvrzení, že na jednu IP adresu má směřovat jenom jeden A záznam.

317
Jako „slaměný panák“ se označuje argumentační faul – podsunutý argument, který údajně tvrdí druhá strana. Já jsem netvrdil, že něco o virtual hostu tvrdíte vy. O virtual hostu jsem začal psát já – uváděl jsem to názorný příklad toho, kdy mnoho A záznamů vede na jednu IP adresu. Doufal jsem (marně), že tak notoricky známý příklad budete znát. Takže nejen, že se neorientujete v základech problematiky domén, v základech problematiky webhostingu, ale neznáme ani význam pojmu „slaměný panák“.

Ano, k původnímu tématu jste se už vyjádřil až moc. Váš nesmysl o tom, že a jednu IP adresu má vést jenom jeden A záznam, jsem vám vyvrátil už odkazem na běžnou praxi virtual hostů v HTTP, kterou jsem doložil i konkrétními příklady. Vyvrátil jsem to také poukazem na to, že nemůžete ovlivnit, kdo si udělá A záznam na vaši IP adresu, takže byste nebyl schopen zajistit dodržení tohoto pravidla. Dále můžu pokračovat existencí hvězdičkových záznamů, které logicky musí překládat různá jména na stejnou IP adresu.

Když nejste schopen pochopit ani takhle jednoduchou věc, o to směšnější jsou vaše útoky o trollingu a argumentačních faulech. Protože každý vidí, že problém je jenom v tom, že si vůbec nedokážete připustit, že byste se mýlil. Takže když vám někdo předloží různé DNS názvy, které A záznamy překládají na stejnou IPv4 adresu, vy si je ani nezkusíte přeložit, abyste zjistil, že se opravdu překládají na stejné IP adresy. (Já s těmi doménami nemám vůbec nic společného).

Jmenné virtual hosty vznikly kvůli nedostatku IPv4 adres. Vaše teorie o tom, že to bylo kvůli sdílení výkonu serveru, je sice hezká, má však „drobnou“ trhlinu – kvůli sdílení výkonu serveru nejsou vůbec potřeba. Takže by to tenkrát těžko někdo řešil nestandardním rozšířením protokolu (v době HTTP 1.0) a úpravou standardu v následující verzi (HTTP 1.1). Výkon serveru by se totiž bez jmenných virtual hostů jednoduše sdílel tak, že byste tomu serveru přidělil více IP adres, a na každé IP adrese by běžel jiný web.

Ano, virtual host se používá i jako obecné označení pro provoz více webů na jednom web serveru, nemusí být odlišené jen jménem. Ale zároveň se ten termín dnes používá i v tom užším významu, že se tím myslí named virtual host. Pokud ale víte, že může být virtual host odlišen i IP adresou, nechápu, proč píšete o tom nesmyslu, že se named virtual host používal kvůli sdílení výkonu serveru a ne kvůli nedostatku IP adres.

vdaka comu je mozne na jednej IP prevadzkovat viacero secure domen
Př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 vykecavaky
Když nechápete stručné argumenty, nezbývá, než vám to vysvětlit pomalu a s příklady.

nepouzivajte argumentacne fauly
Já 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.
Podrážděně na mé komentáře opravdu reagovat nemusíte. Stačí, když si je budete pečlivě číst a budete se z nich učit. (Na tohle by někdo mohl reagovat podrážděně. Vy na to ale nemáte právo, protože už jste více než dostatečně prokázal, že ve vašem případě je tohle tvrzení pravdivé. Za to, že jsem vám to napsal takhle natvrdo si můžete sám, když místo toho, abyste se omluvil za to, jaké nesmysly jste napsal, ignorujete triviální argumenty vyvracející ty vaše nesmysly a ještě se u toho blahosklonně tváříte, jak ostatní učíte diskutovat.)

318
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 :D
To 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.

Pokud byste měl u Wedosu jenom doménu, ale A/AAAA záznam chtěl směrovat třeba na AWS, žádný PTR záznam Wedos neupraví, protože do DNS stromu patřícího k IP adresám AWS nemá přístup.

Pokud byste měl naopak doménu hostovanou třeba u Active24 a chtěl provozovat web u Wedosu, Wedos vám rozhodně žádný PTR záznam nenastaví na základě vzniku A/AAAA záznamu, protože se o jeho vzniku ani nedozví.

Což je mimochodem další věc, která vám uniká – já klidně můžu ve svém DNS nastavit A záznam na vaši IP adresu. Vy se to nedozvíte, a i kdybyste to náhodou zjistil, nic s tím nemůžete udělat. Pokud by platila vaše teorie, že ke každému A záznamu musí existovat i odpovídající reverzní záznam, a kdyby ne, bude za to příslušná IP adresa penalizována, mohl bych takhle snadno zařídit penalizací vaší IP adresy – a vy byste s tím nemohl udělat vůbec nic. To by byl hezký DoS, že?

Proto ISP, kteří provozují služby hostování (třeba serverhosting, serverhousing, VPS apod.) obvykle nabízejí možnost k IP adresám, které vám přidělí, nastavovat i PTR záznamy. Protože vy si DNS hostujete kde chcete, ale potřebujete, aby vám tento ISP nastavil do svého DNS PTR záznamy, které potřebujete.

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ů.

Zkuste si získat IP adresy k následujícím názvům:

  • the9010rule.com
  • 39dollaroptical.com
  • akrobatusa.com
  • audioinnovationsnw.com

Nebo k těmhle:

  • abcsvatby.cz
  • abroadwithdenisa.com
  • abson.cz
  • jarotds.cz
  • cqiservices.cz
  • startupcoffee.cz
  • omega-interiery.com

Myslím, že vám to dost rozšíří obzory ohledně HTTP virtualhostů.

Zkuste si pak také nastudovat technologii SNI – a můžete dumat, proč asi vznikla. A proč čtvrt století před tím vznikla hlavička Host a proč byla v HTTP 1.1 zavedena jako povinná.


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 :D
CNAME ří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.

319
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.

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.

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ěž.

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?
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).

320
Distribuce / Re:Nastavení rozložení klávesnice
« kdy: 03. 12. 2022, 19:42:01 »
V jakém operačním systému, případně desktopovém prostředí?

321
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.

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ů.

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á.

322
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í.

323
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.

324
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.

325
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.

326
Server / Re:virtualizace desitek systemu
« kdy: 28. 11. 2022, 09:35:55 »
Předpokládám, že to chcete migrovat bez nějakých výraznějších zásahů, takže chcete plnohodnotné virtuální stroje a ne jen kontejnery.

Pro vytvoření virtuálních strojů použijte nějaký nástroj pro orchestraci – Terraform, Ansible, Puppet…

Pro rozlišení jednotlivých instancí použijte cloud-init – je to standardní řešení, nebudete muset vymýšlet a ručně nějakou konfiguraci podle IP adres a podobně.

Vytvoření 150 obdobných virtuálních strojů není žádný neobvyklý požadavek, nekliká se to ručně, jsou na to nástroje (viz výše).

327
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.

328
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.

329
Plugin v prohlížeči žádný. Jinak používám HTTP klienta v IntelliJ Idea (nebo WebStorm), Postman, Insomnia, curl.

330
Server / Re:Nefungující HTTP
« kdy: 22. 11. 2022, 17:33:01 »
Současně se pouze domnívám, že je to věcí http nebo https, protože např. www.seznam.cz mi jde, ale např. www.mcu.cz už nejde.
Tak v tu chvíli vyzkoušejte oba dva protokoly s jedním webem. Tj. zkuste Seznam i mcu.cz jako po HTTP tak po HTTPS. použijte k tomu nějakého řádkového klienta, třeba curl:

Kód: [Vybrat]
curl -vk http://www.seznam.cz

Tohle vypíše i detaily komunikace. Kdybyste šel na Seznam.cz přes HTTP z prohlížeče, pravděpodobně se stejně rovnou použije HTTPS, protože Seznam doufám používá HSTS, tj. prohlížeč si bude pamatovat, že má použít HTTPS. Naopak parametr -k u curl zajistí, že se bude ignorovat neplatný certifikát u https://www.mcu.cz.

Tím ověříte, zda je problém opravdu u HTTP a HTTPS je v pořádku, nebo jestli je to danou doménou.

Stran: 1 ... 20 21 [22] 23 24 ... 375