Názory k článku
Google od února zvýší ceny za IPv4 adresy ve svém cloudu

Tuším že qBittorrent to umí. Utorent to také uměl.
Já nemám ani veřejnou 4 ani můj poskytovatel t -mobile optika neumí IPv6.
Takže když bych chtěl 6tju řešilo by to třeba warp 1.1.1.1 nebo nefunguje pro příchozí spojení?
Tohle je pro mě asi moc složité
https://kb.vpsfree.cz/informace/projekty/ipv6tunel

1. 10. 2023, 10:48 editováno autorem komentáře

Ani jedna? A vedia vôbec použiť IPv6?

Torrent klienta neviem. Už veľmi dávno som žiadneho nepoužil a teraz si ani neviem spomenúť, akého som to vtedy vôbec použil. Ale pokiaľ by som to tak hádal, tak je to klientská koncová stanica, tak nepotrebuje mať viac IPv6 adries na odchodzom rozhraní. Tak by tam problém nemal byť. Jedine, že by to bola taká všehochuť, aj pracovná stanica. aj vlastne server, či router.

Nedalo mi to. Našiel som nejaký transmission (možno ten som používal, lebo mi je známa jeho klient server architektúra https://wiki.archlinux.org/title/transmission#top-page), Našiel som, že pre spojenia používa knižnicu libcurl (https://github.com/transmission/transmission/blob/main/docs/Environment-Variables.md) a tá sa dá konfigurovať cez ENV:CURLOPT_IN­TERFACE (https://curl.se/libcurl/c/CURLOPT_INTERFACE.html) a tam by sa mala dať zapísať aj IP. Nemám vyskúšané.

Psal jste o odchozích spojeních a zároveň o MX záznamu, který je pro příchozí spojení.

Na které IP adrese má aplikace naslouchat se nastavuje v konfiguraci konkrétní aplikace, je to stejné pro IPv4 a IPv6. Je málo důvodů, proč určovat, kterou IP adresu použije aplikace pro odchozí spojení. Nejlepší je nechat to na OS.

PTR pro IPv6 nemá smysl, protože IPv6 adres je obrovské množství, a není důvod, aby každá z nich měla své jméno. Třeba zmíněné privacy extension slouží k tomu, aby mohl klient IP adresy často střídat. Jaký smysl by mělo je pojmenovávat? Buď bude jméno dokazovat na konkrétního klienta, a pak je nesmysl měnit mu IP adresy, když podle jména poznáte, že jde pořád o stejného klienta. Nebo se jméno bude měnit spolu s IP adresou, buď podle IP adresy nebo náhodně – a k čemu je pak takové jméno?

Všechny porty jsou ve výchozím stavu otevřené. Zavřít je můžete zprovozněním firewallu. Jenže firewall by neměl provozovat nikdo, kdo sítím nerozumí – takový firewall nejen, že je k ničemu, ale naopak škodí – jednak vzbuzuje falešný pocit bezpečí, jednak rozbíjí síťovou komunikaci když blokuje provoz, který blokován být nemá.

Nevím, co chcete směrovat na jednu IP. Ale pokud chcete, aby aplikace naslouchala na konkrétní IP adrese, nakonfigurujte tu aplikaci – je to stejné pro IPv4 i IPv6. Pokud chcete používat konkrétní IP adresu i pro odchozí spojení té aplikace, opět je potřeba to nakonfigurovat v té aplikaci – aplikace, u kterých to dává smysl, to umí (třeba Postfix klient, OpenSSH klient). A opět se to konfiguruje úplně stejně pro IPv4 i IPv6.

Ad1) Víte jak funguje poštovní server?
" a k čemu je pak takové jméno?"
Poštovní servery ověřují spoustu věcí.
Jedna z nich je PTR.
Pak máte SPF - seznam IP z kterých je možné odesílat.
Když to nesedí, tak skončíte ve SPAMu.

Ad2) víte jak funguje P2P?
Seeder pošle na tracker svojí IP (v případě IPv6 náhodnou a dočasnou) a port a info že je seed.
Leech se snaží připojit na náhodnou/dočasnou IPv6 a port.
Vidíte ten problém?

Ano, v ideálním světě by klienti komunikovali nepřímo bez FW a bez NAT. (A bez účasti velkého bratra. ) Což bohužel nejde.

"nakonfigurujte tu aplikaci – je to stejné pro IPv4 i IPv6"
Není to stejný.
Pro IPv4 stačí nastavit FW. Venkovní IPv4 aplikace vůbec znát nemusí.
Pro IPv6 je třeba nastavit FW i aplikaci.
Jak to udělám?

Jedna z nich je PTR.
Jenže to právě v případě IPv6 neplatí. Které poštovní servery ověřují PTR při komunikaci přes IPv6? A i kdyby se nakonec ukázalo, že to budou poštovní servery vyžadovat i pro IPv6, pořád to neznamená, že bude potřeba nastavovat PTR záznam pro všechny používané IPv6 adresy, bude stačit nastavovat je pro ty používané poštovním klientem.

Pak máte SPF - seznam IP z kterých je možné odesílat.
Ano, seznam IP – takže jméno není potřeba.

Vidíte ten problém?
Nevidím, teda pokud se to pořád vztahuje k PTR.

Ano, v ideálním světě by klienti komunikovali nepřímo bez FW a bez NAT. (A bez účasti velkého bratra. ) Což bohužel nejde.
Jde. S IPv6 jde komunikovat přímo, žádný NAT není potřeba. Teda s IPv4 to jde také, ale musíte mít to štěstí, že na obou stranách máte veřejné IPv4 adresy. Což je dnes docela luxus.

Není to stejný.
Je to stejné.

Pro IPv4 stačí nastavit FW. Venkovní IPv4 aplikace vůbec znát nemusí.
Pro IPv6 je třeba nastavit FW i aplikaci.
Firewall do toho vůbec nemotejte. Už jsem vám psal, že když tomu nerozumíte, nemáte ho vůbec zapínat.

Když chcete, aby server naslouchal na konkrétní IP adrese, nakonfigurujete to způsobem, jakým se konfiguruje daná aplikace. Třeba u nginx použijete direktivu listen, u Postfixu použijete direktivu inet_interfaces. Jak jsem už mnohokrát psal, je to pro IPv4 i IPv6 stejné – v těch direktivách uvedete IPv4 adresy, IPv6 adresy nebo jejich kombinaci.

Jak to udělám?
Nastudujete si základy fungování TCP/IP sítí.

Google IPv6 PTR overuje a bez platneho reverzniho zaznamu vam postu neprijme.

Puvodni problem je v tom, ze na postovnim serveru je povolena automonfigurace a privacy extensions, nacez postovni demon necha na operacnim systemu, aby vybral odchozi adresu. To je proste problematicka konfigurace. (Samozrejme, technicky vzato, muzete mit platny reverzni zaznam a k nemu i dopredny zaznam pro vsechny adresy v /64, ale neni to uplne bezny scenar. Server by mel mit adresu statickou a k ni i adekvatni reverzni a dopredny DNS zaznam.)

Tak už se to zlo validace PTR záznamů rozmáhá i v IPv6. Kdyby místo toho třeba povinně vyžadovali DMARC pro klienta komunikujícího po IPv6, dávalo by to daleko větší smysl.

Každopádně to pořád vyžaduje PTR záznam jen pro MSA. A nedává smysl pro MSA používat privacy extension, i když by to technicky šlo, jak píšete.

Právě pro ty kontroly odchozí IP adresy dává smysl poštovnímu klientovi (MSA) určit, ze které IP adresy se má připojovat – pro IPv4 i pro IPv6 (jak už jsem psal). Proto má třeba Postfix volby smtp_bind_address a smtp_bind_addres­s6.

To neni zadne zlo. To je vec, co vyplyva treba z RFC 1912 (sekce 2.1). Zlo jsou naopak lide, co nam tu vic jak ctvrtstoleti stara RFC stale ignoruji a odmitaji nastavovat veci poradne, protoze to je asi moc prace, ze?

Je to zlo, protože každé zařízení připojené k internetu opravdu nemusí mít jméno. To dávalo smysl v době, kdy byl internet malý a skoro se všichni znali. Ale k čemu je dobré, aby každá žárovka ve vašem domě měla své DNS jméno? A když je nebudete pojmenovávat a necháte ta jména vygenerovat automaticky, k čemu budou dobrá?

Jinak doporučuji někdy si to RFC 1912 přečíst. Zjistíte, že u použití PTR je „should“, ne „must“. Takže PTR záznamy nejsou povinné. Chyba je naopak spoléhat na něco nepovinného.

Mimochodem, svým zařízením s privátními IP adresami asi také veřejná jména nedáváte (protože to nejde). A internet se kvůli tomu nezbořil.

Kontrola, o ktere se bavime se dela na urovni MTA. A kazde zarizeni, o kterych tu zvatlate fakt s MTA naprimo komunikovat opravdu nemusi - ti, co to tak delaji opet jen prokazuji svou lenost. Od toho mame prave MSA, kdyz uz teda ma ta zarovka nutkavou potrebu posilat maily.

A should v terminologii RFC opravdu neni zadny generalni pardon, naopak - ten, kdo se od daneho pozadavku nejak odchyluje jen akceptuje mozne problemy. Aneb zadne RFC nikomu neprikazuje prijmou mail odkudkoliv. Zlo jsou v tomhle pripade lidi, co maji pocit, ze maily z jejich odflaknuteho paskvilu musi prijimat kazdy ;-)

Když se bavíte o kontrole prováděné MTA, neodkazujte na RFC 1912, které stanovuje obecná pravidla. A kontrola PTR u MTA je duplicitní k SPF, přičemž SPF vám dává daleko přesnější informaci.

Should v terminologii RFC má přesný význam, který najdete v RFC 2119. A v RFC 1122 v sekci 1.2.2 najdete, jaké pravidlo se má dodržovat při implementaci internetové komunikace.

I když je existující reverzní záznam pouze "should", je pro poštovní server určitě vhodné, aby tento záznam měl. Nevím, proč proti tomuto doporučení, i pro poštovní servery, tak usilovně vystupujete. Máte snad vlastní botnet, rozesílající spamy?

On to myslí tak, že nemá smysl přidělovat unikátní PTR každé adrese z těch miliard, kterou dostanete. Poštovní server obvykle používá jednu adresu a ta samozřejmě PTR má a je to tak v pořádku. Ovšem poštovní server nepoužívá autokonfiguraci, ale má staticky přidělenou právě tu jednu adresu, pro kterou existuje PTR.

Aby bylo jasno, nikomu neradím, že má provozovat MTA na IP adrese s chybějícím nebo špatným PTR záznamem. Bez správného PTR dneska přes IPv4 e-mail nepošlete – a vypadalo to, že u IPv6 to bude jiné, ale evidentně už se to používá i tam.

Co tvrdím je to, že to pravidlo je u moderních poštovních systémů nesmyslné. Kontrola PTR u MTA vznikla v době, kdy neexistovalo nic jako DMARC, DKIM, SPF. Byla to taková z nouze ctnost. Jak je to nesmyslné se ukázalo, když ISP začali nastavovat všem IP adresám automaticky generované PTR záznamy a antispamy se pak pokoušely uhodnout, jestli daný název je generovaný automaticky nebo ne.

Dneska máme daleko lepší prostředky pro kontrolu toho, zda uvedená IP adresa má právo posílat e-maily z dané domény. Máme SPF, které vyjmenuje povolené IP adresy pro danou doménu. Tím povolené IP adresy omezíte daleko víc – správný reverzní záznam může mít kde co, ale pomocí SPF vyjmenujete opravdu jen povolené MSA.

Dávalo by smysl používat kontrolu PTR jako fallback, když neexistuje DMARC nebo SPF. Klidně bych i řekl, že kdo chce posílat e-mail přes IPv6, musí mít DMARC – IPv6 novější technologie, někdo to musí alespoň minimálně nakonfigurovat, tak dejme jako pravidlo, že se musí věnovat i DMARC a DKIM a/nebo SPF. Ale ověřovat PTR v okamžiku, kdy mám pro danou doménu k dispozici DMARC nebo SPF, je nesmysl, protože ověření PTR řeší to samé, akorát mnohem hůř.

Botnet rozesílající spamy fakt nemám, to bych nedoporučoval vykašlat se na ověřování z doby parních strojů a místo toho používat moderní řešení.

Ty vaše představy o světě mě začínají děsit a bavit zároveň.

1. Antispam má každý server udělaný jinak.
Podchytit potřebuji všechny varianty. I tu že někdo kontroluje PTR na IPv6.

2. Právě jste se sám odkopal. Tvrdíte že IPv4=IPv6 a v dalším poštu že IPv4 potřebuje PTR, ale pro IPv6 by jste ho nepoužil.

3. FW nenasadit. Jako vážně?
Bavíme se o HW krabičce?

EDIT:
Dobrou noc všem:-)

1. 10. 2023, 23:29 editováno autorem komentáře

Podchytit potřebuji všechny varianty. I tu že někdo kontroluje PTR na IPv6.
Já jsem nikde nepsal, že PTR pro IPv6 pro odesílající poštovní server nastavovat nemáte. Já jsem psal o druhé straně, o těch, kdo to kontrolují.

Právě jste se sám odkopal. Tvrdíte že IPv4=IPv6 a v dalším poštu že IPv4 potřebuje PTR, ale pro IPv6 by jste ho nepoužil.
Netvrdím, že se to rovná. Tvrdím, že se to stejně konfiguruje. A když nakonfigurujete PTR pro IPv6 stejně, jako jste to konfiguroval pro IPv4, vznikne z toho nějaký problém? Nevznikne.

FW nenasadit. Jako vážně? Bavíme se o HW krabičce?
Ano, firewall nenasazovat. Firewall se nenasazuje, firewall se spravuje. A musí to dělat někdo, kdo tomu rozumí. Firewall, který jenom „zapne“ někdo, kdo tomu nerozumí, udělá víc škody, než užitku.

Firewall funguje tak, že oddělí bezpečnou síť od jiné, nebezpečné, a propouští jenom vybraný provoz. Domácí a SOHO sítě obvykle nejde považovat za bezpečné, protože tam nikdo nemá kontrolu nad tím, co se děje uvnitř té sítě – bez ohledu na to, zda tam firewall je nebo není. Normální zařízení nevystavuje k naslouchání žádné aplikace, které naslouchat nemají – takže běžné nastavení spotřebního firewallu je k ničemu, protože jen nepouští dál komunikaci, kterou by stejně nikdo nepřijal.

Kontrolou existence reverzního záznamu můžete vyřadit z dalšího zpracování spoustu mailů od spamerů, aniž byste plýtval dalšími prostředky poštovního serveru. Je sice pravda, že dnes má mnoho ISP generované PTR záznamy, takže kontrolou PTR projdou, ale nejsou to zdaleka všichni. Takže i pro IPv4 to má pořád smysl. A pro IPv6 těch generovaných reverzních záznamů ještě ubude. Proto bude mít kontrola reverzního záznamu určitě smysl i nadále.

"mnoho ISP má generované PTR záznamy"

Tak ty rozhodně validací neprojdou.
Nestačí mít nějaký záznam.
Jeho hodnota musí odpovídat MX v DNS.
Většinou mail.firma.cz.
Kor dnes když pro každou službu (mail, vpn, vdi,..) můžete mít vlastní IPv6 a nemusíte to řešit přes porty.

Nestačí mít nějaký záznam. Jeho hodnota musí odpovídat MX v DNS.

Tak to určitě ne. Neexistuje jediný důvod, proč by relay pro odchozí poštu měla být na stejném stroji jako příjemce pošty, a je zcela běžné, že to tak není.

Na to, jak se tu snažíte celou dobu vystupovat jako ohromný suverén a usazovat ostatní, prokazujete (opakovaně) dost hluboké neznalosti.

První odkaz v Google říká něco jiného.

MXtoolbox to kontroluje. Ten ale má kontrolu IPv6 takovou poloviční.
A tady to taky ověřují přímo pro IPv6:
https://www.mythic-beasts.com/ipv6/health-check
Doporučuji

První odkaz v Google říká něco jiného. MXtoolbox to kontroluje.
Nikoli. Pouze vy si pořád pletete odesílání a příjem e-mailů.

Fungovat musí oboje.
MX se používá při příjmu i odesílání.

Ale chybku tam mám už další.
MXTOOLBOX kontroluje reverzní DNS proti SMTP Baneru. Nikoli proti MX.

https://www.mythic-beasts.com/ipv6/health-check
To kontroluje proti MX.

PS:
Koukám ze Outlook.com má nějaké IPv6 u (_!_)

MX se používá při příjmu i odesílání.
Při příjmu se ovšem může kontrolovat maximálně to, zda pro danou doménu je kam poslat e-mail (nebo-li nepřijmeme e-mail od nikoho, komu nemůžeme poslat e-mail). To znamená ověření existence MX záznamu nebo A/AAAA záznamu. Ale nemůžete s ničím MX záznam porovnávat, protože je úplně normální, že pro danou doménu přijímají e-maily jiné servery než ty, které je odesílají.

To kontroluje proti MX.
Aha, takže vy jste na tu webovou stránku zkusil odeslat e-mail? Nebo jak přesně kontrolujete to odeslání?

A jak řešíte situace, kdy e-maily pro danou doménu odesílají jiné servery, než které je přijímají?

Tak ty rozhodně validací neprojdou.
Nestačí mít nějaký záznam.
Jeho hodnota musí odpovídat MX v DNS.
Většinou mail.firma.cz.
Už zase si pletete příchozí a odchozí e-mail. Bavíme se o odesílání e-mailu. MX záznamy slouží pro příchozí e-mail. Je naprosto běžná situace, že se e-maily odesílají z jiných serverů, než které e-maily pro danou doménu přijímají. Například e-maily přijímáte přes externí službu, která filtruje spam – ale odesíláte je ze svých serverů.

Kor dnes když pro každou službu (mail, vpn, vdi,..) můžete mít vlastní IPv6 a nemusíte to řešit přes porty.
Příjem e-mailů přes porty nevyřešíte. E-maily se přijímají na adresách určených MX nebo A/AAAA záznamy, vždy na portu 25. Neexistuje způsob, jak byste odesílatelům mohl signalizovat, že mají poštu předávat na jiný port. Je možné si to individuálně domluvit, že třeba nějaký spřátelený server vám bude poštu předávat na jiný port, ale pro obecný příjem pořád potřebujete port 25.

Kontrolou existence reverzního záznamu můžete vyřadit z dalšího zpracování spoustu mailů od spamerů, aniž byste plýtval dalšími prostředky poštovního serveru
V čem přesně je kontrola PTR úspornější, než kontrola SPF?

> V čem přesně je kontrola PTR úspornější, než kontrola SPF?

Neříkejte, že si to zrovna Vy nedovedete představit. Prostě je to kontrola navíc. Například takový postfix má kontrolu na korektní reverzní záznam zabudovanou, stačí ji zapnout. SPF kontrolovat neumí, musí to předat něčemu, co to umí.

Mate to vyse, SPF ma jen asi 32% domen. Pri "vasem" reseni by clovek mel nejprve overit existenci SPF s cca 68% pravdepodobnosti, ze zadne SPF neexistuje a pak teprve jako fallback sel overovat PTR. Tedy ve vetsine situaci v realnem svete o DNS dotaz navic... SPF navic musite korektne rozparsovat, coz samo o sobe take zere zdroje navic - neni to jen o tom DNS dotazu, ale treba urceni toho, ze IP/hostname patri do polozek, ktera je SPF zaznamem povolena, SPF zaznamy se navic muzou pomoci include retezit (dalsi DNS dotazy, dalsi parsovani). Ten check u SPF je proste komplexnejsi a narocnejsi nez kontrola toho, ze mam PTR a k tomu odpovidajici A/AAAA zaznam - tedy tak, jak se ta kontrola obvykle implementuje. Vazne chcete tvrdit, ze kontrola SPF je uspornejsi? To jen dokazujete, ze o fungovani SPF toho sam moc nevite :-)

Danny: Pro ověření PTR potřebujete minimálně dva dotazy. A pár DNS dotazů navíc ani rozparsování odpovědi snad poštovní server nezabije. Dělá jiné věci, které jsou daleko náročnější.

Udelat dva DNS dotazy (na PTR+A/AAAA) a porovnani retezcu je rozhodne mene narocne, nez zpracovat vsechny TXT (ktere nemusi byt jen k SPF, uklada se tam i hromada dalsich veci... on specialni SPF-type DNS zaznam je od RFC 7208 deprecated, ze?), rozparsovat TXT co se tyka SPF... vyresit vnorene includy, vyresit treba preklad z a: ci aaaa: na adresu... tech operaci tam je proste vic a tedy logicky narocnejsi budou.

Ano, to zpracovani SPF je zdanlive nenarocne - ale pokud to delate ve velkem a ne na svem usmudlanem privatnim mailserveru s trafficem pet mailu denne, tak uz to znat proste je. A porad se bavime o tom, ze v 68% pripadu se zadneho SPF zaznamu nedockate. Takze dava smysl rovnou udelat kontrolu na PTR/A+AAAA match. Snazite se vybruslit z toho, ze SPF zas tak moc rozsirene taky neni, ale statistiky jsou neuprosne, ty svou retorikou neumlatite.

Není to rozšířené, protože místo validace SPF/DKIM radši validujeme PTR/A+AAAA, protože je to rychlejší. Sice to nevypovídá nic o tom, zda dotyčný má právo z dané IP adresy odesílat e-maily, stejně pak musíme validovat SPF/DKIM, ale co. Je to jak legendární chyba při dělení v plovoucí řádové čárce u Pentií – sice je to blbě, ale za to rychle.

Vase domenka, ze validujeme pouze PTR/A+AAAA je jen dalsi z vasich blabolu ;-) Nikoliv, touto kontrolou jen vyloucime stroje, se kterymi se nema smysl dal bavit - a takovych je spousta, mimo jine prave proto ze spamovat muzou a realne tak cini i zaplevelene koncove uzivatelske stanice, kde je vysoce pravdepodobne, ze to sedet nebude, v praxi to vesmes to nesedi. A teprve pokud tato kontrola projde, resi se dalsi a technicky narocnejsi kontroly.

Vite, ono je hezky, jak tu teoretizujete - ale provozni zkusenosti viditelne nemate, radsi se vratte ke svemu programovani v Jave a spravcum mailserveru do prace nefusujte... :-)

Danny: Vaše domněnka, co je má domněnka, je mylná.

Kontrola PTR je komplementarni kontrolou v realnem prostredi, kdy ani SPF, natoz (slozitejsi) DKIM a DMARC fakt nema kazdy Aneb ano, mame i teroreticky lepsi zpusoby, ale zdaleka ne kazdy je prakticky pouziva a umi pouzivat. Mate na to dokonce studii - ktera rika, ze SPF zaznam ma ~32% domen, u DKIM a DMARC je situace jeste horsi. V takovem prostredi tvrdit, ze kontrola na PTR muze jen blazen, co je odtrzeny od reality venku ;-) Domen bez SPF je majorita.

Tech technik na kontrolu je samozrejme vice a vzajemne se doplnuji a celkem casto prekryvaji. A jak uz tu nekdo zminil, ono treba uz jen kontrola na DKIM je vypocetne narocnejsi. Kdyz resite maily ve velkem objemu, tak samozrejme i toto je dulezity aspekt. A je naprosto legitimni chtit po spravcich MTA, aby se nechovali jako prasata a korektni PTR proste nastavene meli, neexistuje legitimni duvod, proc by tomu tak nemelo byt.

A ano, Google svou trzni silou muze takove veci vynutit a je dobre, ze to dela... ono ani vam rucicky neupadnou, kdyz si PTR nastavite. A v pripade IPv6 ta politika byla restriktivnejsi vzdycky, ono je to v realu presne opacne - vynucovali to tam mnohem drive.

Pricetne fungujici ISP vam na pozadani reverz samozrejme upravi dle potreb a generovani nejakeho defaultu s tim nijak nekoliduje, on ten reverz je uzitecny treba i pro potreby diagnostiky, kdy z toho reverzu nejakou informaci jde odvodit. A i pro IPv6 na to reseni existuji, jen se to samozrejme nedela "postaru" systemem obrovskeho zone-file... tak jak se to v praveku delalo na IPv4 (ala Bind a jeho $GENERATE).

2. 10. 2023, 07:06 editováno autorem komentáře

Kontrola PTR je komplementarni kontrolou v realnem prostredi, kdy ani SPF, natoz (slozitejsi) DKIM a DMARC fakt nema kazdy Aneb ano, mame i teroreticky lepsi zpusoby, ale zdaleka ne kazdy je prakticky pouziva a umi pouzivat.
Čemu přesně nerozumíte na tvrzení, že by se kontrola PTR používala jako fallback v případě, kdy doména nemá SPF ani DKIM?

neexistuje legitimni duvod, proc by tomu tak nemelo byt.
Důvod je ten, že už dávno neplatí, že by koncoví klienti měli svůj rozsah IP adres. Takže potřebují reverzní záznamy nastavovat pro IP adresy, které patří někomu jinému (jejich ISP). A jsou závislí na tom, zda a jak jim to ISP umožní.

ono ani vam rucicky neupadnou, kdyz si PTR nastavite
Já to fakt nastavovat nepotřebuju, protože to nastavené mám pokaždé, když to ISP umožňuje.

Pricetne fungujici ISP vam na pozadani reverz samozrejme upravi dle potreb
No právě, závisí to na ISP. Někdy musíte žádat e-mailem podporu, někdy na to dokonce mají formulář. Ani jedno není věc, která by se dala dobře zautomatizovat a která by dobře škálovala.

on ten reverz je uzitecny treba i pro potreby diagnostiky, kdy z toho reverzu nejakou informaci jde odvodit. A i pro IPv6 na to reseni existuji, jen se to samozrejme nedela "postaru" systemem obrovskeho zone-file...
Samozřejmě, že technicky je možné leccos, můžete reverzní záznamy generovat na požadavek. Akorát automaticky generované PTR záznamy jdou přesně proti tomu, proč to poštovní servery kontrolují. Aneb všichni se snaží, aby každá používaná IP adresa měla svůj reverzní záznam, přičemž kdyby taková situace nastala, bude kontrola PTR záznamů poštovními servery naprosto k ničemu.

Mimochodem, ani na informace z reverzních záznamů nemůžete spoléhat. Útočník si klidně na svou IP adresu může nastavit reverzní záznam, aby to vypadalo, že patří do nějaké důvěryhodné sítě. Takže když se na reverzní záznam chcete spoléhat, musíte si ho přeložit zase zpět.

Mimochodem, ani na informace z reverzních záznamů nemůžete spoléhat. Útočník si klidně na svou IP adresu může nastavit reverzní záznam, aby to vypadalo, že patří do nějaké důvěryhodné sítě. Takže když se na reverzní záznam chcete spoléhat, musíte si ho přeložit zase zpět.

Například postfix... stačí nastavit.

Jenze ten vas fallback nastane v prevladajicim mnozstvi situaci, kdyz mate SPF zaznam jen u 32% domen, tak celkem logicky na ten fallback dojde v 68% pripadu, tedy na ten vas fallback dojde v majorite pripadu. Navic jak mate napsano vyse - kontrola SPF je komplexnejsi a narocnejsi - protoze dost casto neskoncite jen u prezvejkani jednoho DNS TXT zaznamu a ze SPF k domene zjistite toliko to, ze se musite ptat dalsich DNS na dalsi zaznamy.

Predstavu, ze kazdy ma svuj IP rozsah jste si sem "vsunul" vy sam, je ptakovina - ja nikde nic takoveho nepsal. Naopak, nejbeznejsi use-case je prave to, ze vam PTR nastavi vas poskytovatel sluzby. A samozrejme nastavovani PTR (z pohledu poskytovatele sluzby) jde zautomatizovat pomerne snadno, o API jste jako programator doufam uz nekdy slysel. Implementaci najdete na internetu spoustu, UTFG... ;-)

A samozrejme nastavovani PTR (z pohledu poskytovatele sluzby) jde zautomatizovat pomerne snadno
Že to jde neznamená, že to implementované mají. Můžete mne odkázat na API pro přístupové sítě (tedy ne pro datacentra apod.) T-Mobile, Vodafonu a O2?

Ja nejsem vase rozhrani pro komunikaci s dodavateli vasich sluzeb. A ano, v residental sektoru sluzeb nikdo nic takoveho implementovat nebude, ten typ sluzby (a i jeji cenotvorba) neni k tomu urcena. Vymyslite si nesmyslne pozadavky jen proto, abyste si zdanlive obhajil, ze mate pravdu. Pritom ale placate nesmysly - no je videt, ze jste programator zavreny ve sve bubline teorii a s realnym provozem moc zkusenosti nemate.

Ono u spousty domen neni dobry duvod se za ne vydavat pri posilani podvodnych e-mailu a ani nejsou vyuzivany pro legitimni e-maily. Takze i kdyz je domen bez SPF 68 %, tak to samozrejme neznamena, ze tvori 68 % e-mailoveho provozu a neni tedy duvod se domnivat, ze je nejaky zasadni vztah mezi procentem domen s SPF a procentem uvazovanych fallbacku.

Ze se domena nevyuziva pro legitimni emailovy provoz neimplikuje, ze tato nemuze byt zneuzita pro rozesilani spamu. Ostatne to je jedna z dalsich kontrol, co muzete na MTA delat - ovsem to implikuje, ze u takove domeny, co neslouzi k emailove korespondenci mate v DNS naimplementovane doporuceni dle RFC 7505 (aka null MX).

Jsem ani nechtel tvrdit, ze neco takoveho implikuje. Musim na svem vyjadrovani jeste zapracovat.
Kazdopadne se shodneme, ze udaj 32 % domen s SPF je pro ucely teto debaty uplne k nicemu.

Pro ucel debaty je to dostatecne. Spusta domen proste SPF implementovane nema, a nebo mozna ma... ale tak nejak jakoze napul (coz jde dovodit z ~all v policy) :-)

"Vidíte ten problém?
Nevidím, teda pokud se to pořád vztahuje k PTR."

Ne. Řeč není o PTR ale o P2P.
Ještě jednou:
Seed pošle info na server z dočasné IPv6 adresy. "Jsem na portu 12345"
Server si uloží jeho port a adresu z které to přišlo do seznamu seederů. A předá jí na vyžádání leecherům.
Ale v době kdy ta adresa už nemusí platit.

Takže máme situaci, kdy chceme měnit odchozí adresy kvůli anonymizaci a zároveň odchozí adresa je stejná jak příchozí.
Jediná možnost je vypnout FW a nebo otevřít port pro všechny IP v rozsahu, což je skoro to samé.
Útočník může oťukávat všechny PC v sítí.
Což nechci.
Ale snad mi tu někdo poradí jak to nastavit.

> Ale snad mi tu někdo poradí jak to nastavit.
Neukazal jate nam moznosti Vaseho routeru ani topologii site, to se blbe radi.

Server si uloží jeho port a adresu z které to přišlo do seznamu seederů. A předá jí na vyžádání leecherům.
Ale v době kdy ta adresa už nemusí platit.
Privacy extension slouží pro „anonymizaci“ odchozích psojení. Používat je pro příchozí spojení je hloupost.

Jediná možnost je vypnout FW a nebo otevřít port pro všechny IP v rozsahu, což je skoro to samé.
Ne, s firewallem to nijak nesouvisí. Když na nějaké IP adrese a portu neposlouchá příslušný server, tak s tou IP adresou a portem nikdo nedokáže navázat spojení – a žádné vypínání firewallu tomu nepomůže.

Útočník může oťukávat všechny PC v sítí.
Ano, může. Přičemž ve výchozím nastavení PC to ničemu nevadí, výchozí nastavení zařízení musí být bezpečné. Protože se obvykle vyskytuje v síti, která žádnou bezpečnost nezaručuje (bez ohledu na to, jestli někdo „zapnul“ nebo nezapnul firewall).

Ale snad mi tu někdo poradí jak to nastavit.
Nezapínat privacy extension. Když to neumíte používat, nezapínejte to. Jak prosté.

Proc mate vlastne na Windows serveru povolenou autokonfiguraci?

Dobrá otázka.
Vzniklo to tak nějak živelně. Bez mé účasti.
Řeším jen poštu. Firewall dělá někdo jiný. A doménový řadič zas někdo třetí.
Začal jsem zkoumat proč se náhodně ztrácí maily a zjistil že každý je poslán z jiné adresy.
Vypnul jsem ty dočasné. Nechápu proč to má M$ On by default. 10 jich ubylo.
Stejně má čtyři IPv6ky.
Jednu si přiřadila síťovka. Ale zdá se že jí nepoužívá.
Druhou dostal od doménového řadiče.
Třetí dostal od providera. Přitom na routeru je DHCPv6 vypnutý.
Čtvrtou jsem nastavil ručně. Hezkou abych si jí snadno zapamatoval. Tím se u IPv4 vypne autokonfiguraca. Ale zdá se že IPv6 vesele jede dál. (Proto mě tak vytáčí, když někdo tvrdí,že IPv4=IPv6) MS vypnout IPv6 nedoporučuje. Používá jí pro vnitřní věci. Prý by to mohlo ohrozit bezpečnost.
Teď to funguje a víc adres je prý normální.
Tak se na to bojím sáhnout.

Ale ono se IPv6 konfiguruje prakticky stejně, jako IPv4 bez NATu. Vás vytáčí to, že se snažíte dělat věci, které jsou potřeba kvůli ohnutí IPv4, ale u IPv6 potřeba nejsou. Kdybyste nenastavoval nic speciálního s výjimkou toho, že jednu z IPv6 adres přidělených celé síti od ISP byste pro poštovní server nastavil jako statickou, fungovalo by vám to.

Ve Francii ci Nemecku by s vami asi uplne nesouhlasili. Nebo snad 70+% adoption je podle vas znamka pomaleho sireni? :-) Ale ano, holt v te nasi country for the future jsou lide lini a radsi vymysli vymluvy, proc neco nedelat.

IPv6 bude mít letos 25 let.
To je ve světě IT několik generací.
A přesto se dnes vyrábějí "chytré" věci které umí jen IPv4.
Například můj kotel, který plánuji používat 10 možná 20 let.

To jsou dost ostrá slova, že se někdo vymlouva.
Nasazení IPv6 mě stálo hodiny hledání proč nefungují maily a desítky hodin vzdělávání v IPv6.
Nikdo mi to nezaplatí. A ještě mi je tvrzeno, že IPv6 je stejné jak IPv4. Ve světě Linuxu možná. Ale M$ Win a některý HW (speciálně routery a FW) v tom mají velké rozdíly.
To že se doma snažím zprovoznit P2P beru jako zábavné praktické cvičení. To za práci nepočítám.
Ale narazil jsem i na další problémy. Například jsem musel předělat strukturu DNS protože IPv4 měla jen jednu adresu a služby se lišily podle portu. S IPv6 mám pro každou službu vlastní adresu. Znamenalo to změnit všechny adresy na všech zařízeních. A že tech notebooku, tabletů, mobilů. ...má každá střední firma hromadu po celé republice, tak to je další den práce.

Přínos? Jen můj dobrý pocit.
Plně chápu, když se na to někdo vykašle!

Ostatní věci naštěstí tak nějak fungují bez rozdílu mezi 6 a 4.

1. 10. 2023, 23:12 editováno autorem komentáře

Takže jste věc, která byla udělaná ne úplně dobře, předělal tak, aby byla udělaná lépe. Nikdo vás k tomu nenutil, ale konečně jste měl možnost to udělat lépe. A vám vadí, že jste měl možnost to udělat lépe? Když vám to vadí, proč jste to dělal?

Pro zprovoznění e-mailu stačilo zprovoznit statickou IP adresu. Což potřebujete v obou případech, i pro IPv4 i pro IPv6. A i na Windows se to dělá v obou případech stejně. Jediný rozdíl je možná v tom, že jste pro IPv4 tu „statickou“ IPv4 adresu nastavoval dynamicky přes DHCP, zatímco u IPv6 je zvykem nastavit ji opravdu staticky, aby to zařízení nebylo zbytečně závislé na nějaké další síťové službě.

Jak už jsem psal, největší potíž při přechodu z IPv4 na IPv6 je odnaučit se dělat ty spousty zbytečností, které IPv4 vyžaduje a IPv6 ne.

Přešel jsem na IPv6. Udělal jsem to lépe než to šlo s IPv4. Nevadí mi to. Mám z toho dobrý pocit. Ale za ten si nic nekoupím. Vadí mi, když mi někdo tvrdí, že 4=6 a v zápětí "6 je lepší než 4".
Už jste se odkopal podruhé.

"zatímco u IPv6 je zvykem nastavit ji opravdu staticky"
To jsem udělal. A přesto to nefungovalo.
Navíc jsem tím ztratil jednu výhodu IPv6.
Dočasné adresy. Takže teď skoro platí 4=6.

"IPv4 i pro IPv6. A i na Windows se to dělá v obou případech stejně "
NE. NEDĚLÁ.
Kolik poštovních serverů provozujete?
A jak velkých?
Vaše teoretické rady se rozcházejí s praxí.

"Jak už jsem psal, největší potíž při přechodu z IPv4 na IPv6 je odnaučit se dělat ty spousty zbytečností, které IPv4 vyžaduje a IPv6 ne."

Jsou i další potíže. A některé se doktonou i uživatelů. Například když do průzkumníka zadáte \\IPv6 tak vám Win řeknou že server nebyl nalezen. Což je matoucí zpráva. On ho nenajde protože neumí dvojtečku v názvu.
Potřebujete IPv6-literal.com aby to fungovalo.

Z pohledu admina se můžu rozhodnout pro SLAAC. Znalosti IPv4 jsou mi pak na nic a musím se to celé naučit znovu.

IPv4≠IPv6

Uzivatelu se to dotkne jen v situaci, kdy administrator je diletant a nedokaze provozovat DNS v lokalni infrastrukture ;-) Opravdu netusim, proc bych mel mucit sve uzivatele a nutit je nekam zadavat IPv6 adresu rucne...

A ano, specifikace UNC historicky nepocita s tim, ze by v adrese byla dvojtecka (pouziva se jinde). Ono jedou napsane specifikace se meni dost tezko, pokud u toho soucasne nechcete rozbit neco jineho, ze? A zrovna specifikace UNC je hodne stara vec... a kompabilita v tomhle svete se drzi dlouho.

A ano, IT je o tom, ze se cely zivot budete ucit neco noveho... :-) Nikdo netvrdi, ze to je stejne - ale spousta veci proste podobna je, nektere veci se naopak zjednodusuji - staci si porovnat obsah hlavicek IPv4 versus IPv6. I se SLAAC rozhodne spoustu znalosti z "legacy" sveta zuzitkujete. Doporucoval bych si zopaknout OSI model, protoze cele vase fnukani je jen o treti vrstve, znalosti nabyte o vyssich i nizsich vrstvach neni problem recyklovat, ze? ;-)

Souhlas. Doplním že DNS se mi načte později než se vytvoří spojení s VPN. Na GPRS to byla cca minuta. A někdy se nenačetlo vůbec. Win se někdy dotazují špatného serveru. Například když si BFU nastavil 8.8.8.8 aby ho nikdo nemohl sledovat :-D
Nebo někdo použil stejný název jako já \\share.
Tak jsem začal disky mapovat na IP adresu.
S IPv6 to nejde.
Nebo může mít DNS výpadek.
A nebo mohlo dojít ke změně a já se potřebuji dostat na starou adresu. Nebo nechci platit za registraci domény a zdržovat se s nastavením a jdu přímo na IP.
Zadávat IPv6 nikdo nemusí. Uživatel jen klikne na odkaz. Který pod Linuxem funguje a pod Windows ne.
A nefnukam. Jen se hádám s Jirsakem.

Například když do průzkumníka zadáte \\IPv6 tak vám Win řeknou že server nebyl nalezen. Což je matoucí zpráva. On ho nenajde protože neumí dvojtečku v názvu.
To, že neumíte zadat IPv6 adresu do URL, to je váš problém, ne problém IPv6.

Z pohledu admina se můžu rozhodnout pro SLAAC. Znalosti IPv4 jsou mi pak na nic a musím se to celé naučit znovu.
Co se na tom chcete učit?

Jenze on mluvi o UNC zapisovane v pruzkumnikovi, tam IPv6 adresa "klasickym" zpusobem (tedy skrze hranate zavorky) jako URL v prohlizeci zapsat nejde. Aspon si to nastudujte, nez zas budete placat tyhle nesmysly.

OK, UNC je komplikované. Ale URL jako v prohlížeči Windows Průzkumník samozřejmě umí – pro přístup k „lokálním“ souborům (včetně SMB) použijete protokol file:, pro WebDAV protokol https:, pro FTP protokol ftp: …

Expert na teoreticke moznosti zapomel na jednu praktickou malickost. Naucit to koncove uzivatele... muzete za dlouhych zimnich veceru sirit osvetu mezi BFU, beztak zjevne nevite, co s volnym casem... tak byste byl aspon k necemu uzitecny ;-)

Děkuji za podporu. Ale prosím slušně.
Jsme na ROOT.CZ a lze pochopit že místní neznají zaludnosti M$ světa.
Nesnižujte se na úroveň Jirsaka.

Ja jsem dnes uz prakticky vyhradne Linuxak, co ty zaludnosti M$ sveta profesne opustil uz nekdy v roce 2004. A ze tomu Jirsak nerozumi je mozne, ale pak by mel mlcet a nevyjadrovat se za kazdou cenu k vecem, o kterych nema sam ani paru.

ale pak by mel mlcet a nevyjadrovat se za kazdou cenu k vecem, o kterych nema sam ani paru.
Kdyby se tímhle řídili všichni v diskusi, tahle diskuse by vůbec nevznikla…

Danny: „Nejde“ je něco jiného než „uživatelé neumí“. A hlavně – jak jste také sám psal – uživatelé nemají nikam psát IP adresy, už nějaký ten pátek existuje DNS, které slouží pro to, aby lidé mohli psát zapamatovatelné a srozumitelné názvy.

Jisteze, skrabat levou rukou za pravym uchem se take muzete... ze? :-) Nicmene diskuze byla o omezenich v UNC. Namisto priznani sveho omylu jste vytahl neco nesouvisejiciho v podobe alternativnich reseni. Snad udrzite aspon telni tekutiny, kdyz ne puvodni myslenku.

Jisteze, skrabat levou rukou za pravym uchem se take muzete... ze? :-)
Ano, můžete. Dává to stejný smysl, jako nutit uživatele někam zadávat IP adresy.

Ano, UNC má to omezení, že tam IPv6 adresu přímo nejde zadat. Můžete nad tím bědovat, nebo můžete najít alternativní řešení.

Snaha o alternativniho reseni nic nemeni na faktu, ze u UNC jste ve sve argumentaci proste strelil dost vedle, ze? ;-)

Danny: Je pozoruhodné, jak často se snažíte do někoho si kopnout a místo toho ze sebe uděláte hlupáka. Takže teď na ten svůj odkaz klikněte, pak si přečtěte ten můj komentář, na který odkazujete. To, co je kurzívou, jsou citace. A teď přijde to klíčové – vidíte tam někde, že bych psal o UNC? Nevidíte, že? Píšu tam o URL. A URL je něco jiného, než UNC. Tak snad jste si ten pocit vítězství užil, a v trollení si tu klidně pokračujte, ale já už vám záminky poskytovat nebudu.

Vy jste o UNC v tom bode nepsal, protoze jste nepochopil kontext a popletl jste si to s URL... hlupak jste vy sam... ;-) Radsi fakt zalezte do sve diry k programovani v Jave a nefusujte do prace sysadminum... :-)

Danny: Drtivá většina sysadminů ví, že do Průzkumníka mohou napsat UNC i URL. A když nebudou vědět, jak zapsat UNC, tak použijí URL. A pak jste vy…

Ještě jednou zdůraznim že pod M$ Windows to nefunguje. V Linuxu ano.

PS:
Vaše nutkání mít poslední slovo je až obsedantní.
Dá se to léčit.
Není to urážka. Jen dobře míněná rada.

V Linuxu vám funguje Průzkumník Windows a jde v něm zadat UNC s dvojtečkami. OK.

A nefunguje nahodou zapis \\[IPv6] tj. \\[::] ?

Nefunguje, viz vyse odkazana specifikace. UNC se rozebira na strane 27.

Samozřejmě, že se za běhu aplikace mění IP adresy. Když nastartuje systém, spouští se spousta aplikací. Teprve pak se začnou přidělovat IP adresy. Některé se přidělují třeba přes DHCP, to chvilku trvá. Přes DHCP se adresa půjčuje jen na určitý čas, po té platnost výpůjčky vyprší a IP adresa se může změnit. Vy můžete kdykoli zavolat ip addr add. To by se podle vás ve všech těchto případech měly všechny aplikace zastavit a pouštět znovu? Proč?

Pro IPv4 to umím. A myslel jsem že IPv6 bude stejně snadný. No není.
No, nevypadá to, že byste to uměl. S IPv4 musíte obvykle nastavit NAT. Pak musíte nastavit přesměrování portů skrze ten NAT. Pak na firewallu zakážete veškerý provoz a povolíte jen vybraný, přičemž musíte dávat pozor, aby vám to sedělo s NATem.

S IPv6 zakážete veškerý provoz a povolíte IP adresy nebo porty, které chcete mít povolené (když teda máte potřebu něco zakazovat). Ano, máte pravdu, není to stejně snadné jako s IPv4. Je to podstatně snazší.

DHCP i "ip addr add" přidělují IP adresu k zařízení.
Které má MAC adresu.
Proč to sem pletete když se bavíme o aplikaci?

Bartolo: Protože IP adresa se přiděluje vždy zařízení.

Uf. Další moje chybka. Win mění IPv6 adresu i pro běžící aplikace. Dnes jsem to ověřil.
Všechny okna i prohlížeče měli stejnou adresu.
Po hodině se všem změnila na novou.

2. 10. 2023, 16:02 editováno autorem komentáře

Protože není nic jako „IP adresa aplikace“. Je IP adresa (nebo adresy) zařízení. Aplikace při navazování odchozího spojení obvykle nechá volbu zdrojové IP adresy na operačním systému, ale může si i vynutit použití konkrétní IP adresy (toho využívají aplikace umožňující definovat, které zdrojová IP adresa se má použít – třeba SMTP klient, ssh… Jedna aplikace tak může v jednom okamžiku klidně navázat víc spojení, a každé z nich může mít jinou zdrojovou IP adresu. Třeba webový prohlížeč, když se bude na jedné záložce připojovat k webovému serveru v internetu a na druhé záložce k webovému serveru v interní síti.

Takže nová spojení se nenavazují z více IP adres, ale vždy jenom z jedné. To, že ještě dobíhají spojení se starou IP adresou, to je logické.