Názory k článku Jak se projevilo snížení TTL v zóně .cz
-
L (neregistrovaný)
Odkial mate tie casy? U mna je to pre niektore domeny rozne, dns tools to ma rovnako ako ja.
;; ANSWER SECTION:
cz. 897 IN SOA a.ns.nic.cz. hostmaster.nic.cz. (
1495150738 ; serial
900 ; refresh (15 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
900 ; minimum (15 minutes)
) -
Kenny (neregistrovaný)
Řekl bych, že autor článku má TTL z autoritativních DNS, zatímco vy je máte z nějakého rekurzivního DNS (cache).
Když si budete opakovaně spouštět příkaz, kterým jste dostal tu odpověď, tak si všimněte, že se TTL každou sekundu sníží nebo dokonce budete dostávat různě "náhodné" TTL (to když se dotazujete do nějaké víceserverové cache a každý dotaz jde na jiný server, např. Google DNS).
Když potřebujete znát skutečné TTL, tak si nejdřív musíte zjistit nameservery pro danou zónu (např. dig ns cz.) a následně se dotázat přímo některého serveru (např. dig @a.ns.nic.cz. soa cz.).
-
Viz příspěvěk od Kenny výše.
Příkazemdig +multiline soa cz.
dostanete odpověď od Vámi používaného rekurzivního resolveru. Pokud Váš resolver (nebo Vašeho poskytovatele připojení) používá cache (standardní stav), bude se hodnota TTL samozřejmě měnit, snižovat, protože po dalším dotazu je už v jeho cache a postupně zastarává.
Abyste získal právě TTL=3600s, musíte se zeptat přímo některého z našich autoritativních DNS serverů, např. příkazem
dig +multiline soa cz. @a.ns.nic.cz
Tazatel tedy neudělal nic zásadně špatně, jen si ověřil data z rekurzivního DNS serveru, kdežto já přímo z autoritativního.
-
Hlavně že sám píšete bez diakritiky :-) Háčky a čárky jsou jen komplikace, viz např. https://www.zive.cz/bleskovky/neni-applecom-jako-applecom-specialista-ukazal-jakou-hruzu-muze-zpusobit-idn-phishing/sc-4-a-187218/default.aspx
-
Filip JirsákStříbrný podporovatelHáčky a čárky jsou jen komplikace
Nejsou, v české abecedě nenajdete žádný znak s háčkem, čárkou nebo kroužkem, který by vypadal stejně, jako jiný znak české abecedy. Ten odkaz popisuje problém s konfliktem znaků z různých znakových sad – u domény.czale nikdy nikdo neuvažoval, že by se používala jiná sada znaků, než znaky pro češtinu. A i případné konflikty mezi doménami s diakritikou a bez ní lze triviálně řešit tak, že obě varianty budou mít povinně stejného majitele. -
MarSik (neregistrovaný)
> A i případné konflikty mezi doménami s diakritikou a bez ní lze triviálně řešit tak, že obě varianty budou mít
> povinně stejného majitele.To je asi jediné řešení, se kterým bych souhlasil. Jenže pak nastane druhá fáze.. některá velmi rozdílná slova se liší jen diakritikou. A garantuji Vám, že se okamžitě začnou ozývat ti, kteří budou i to výše popsané pravidlo chtít zrušit.
-
Filip JirsákStříbrný podporovatel
Ozývat se mohou. Ale i to se dá řešit – buď čistě soukromě, domluvím se s majitelem té hlavní (ASCII) domény, a pokud mu to nebude vadit, oddeleguje tu mojí variantu na můj server a já budu platit půlku doménového poplatku. A nebo se to dá řešit na úrovni registru, že majitel té hlavní domény bude mít právo kdykoli nějakou její „oháčkovanou“ variantu osamostatnit.
-
hovadina (neregistrovaný)
Vždyť to je přece úplna hovadina. Poplatek za CZ doménu je asi 180kč/rok. Půlka je 90kč. Za ty prachy ti nikdo ani na email neodpoví.
Naopak by se na tom mohli pakovat spekulanti. Mají jednu doménu, jejíž název po doplnění diakritiky může vytvořit několik dalších zajímavých domén. Takže pak by mohli jednu doménu prodat třeba 3x.
zive.cz = zíve.cz = živě.cz = živé.cz -
Nedávno proběhl další pravidelný průzkum veřejného mínění a uživatelé si diakritiku (IDN) v doméně .CZ nepřejí. Takže realita je přesně opačná: CZ.NIC se řídí tím, co mu přikáží jeho členové a ti se v tomto případě řídí také průzkumem veřejného mínění.
-
Palo (neregistrovaný)
Ale castokrat je to problem vhodne polozenej otazky. Co takto napriklad automaticky (za rovnaku cenu) registrovat vsetky hackove varianty. Takze napriklad domena www.clanky.cz by bola vlastne zaregistrovana ako 'www.[cč][lľ][aá][nň]k[yý].cz' respektive by sa normalizovala pred odpovedou (é -> e, ř -> r, ...) a potom by sa vyhladalo. Vsetci by boli stastny.
-
a (neregistrovaný)
Na prvni pohled rozumny napad, ale je videt, ze tomu nerozumite tolik z technickeho hlediska. Neni jen nase "abeceda", znakova sada. Najdete si treba starsi clanky (a k nim diskuse) zde na rootu.
Nekdo posilal neco jako "generator homonym".PS: jaky smysl by mela ta diakritika, kdyby stejne neslo si zaregistrovat živě.cz a zíve.cz pro ruzne subjekty? To pak lepsi zustat u soucasneho bez diakritiky.
-
Palo (neregistrovaný)
No ved presne o to ide. Ludia mozu napisat živě.cz, živé.cz, zívě.cz a vzdy sa dostanu na to iste miesto. Kto chce pisat diakritiku moze a registratori nebudu musiet registrovat 200 domen na vsetky kombinacie pretoze podzme si na rovinu ze zive.cz nebude chciet aby niekto iny vlastnil domenu zivě.cz ktora ta presmeruje na jeho portal.
-
a (neregistrovaný)
Vidite, jeste jenom kousek od vedle ze Slovenska, a uz jste nepostrehl moji hricku v cestine ...zive, jako ten bulvar; a zive..jako byt ospaly.
Abych vysvetlil ty 2 hlavni problemy:
a) technicky: narocnost na lookup kontrolou na vsechny "permutace" ve VSECH diakritikach (nejen cz)
b) zahranici: jak ma nejaky cinsky registrator vedet, ze k zive.cz je podobne zíve.cz ? Pocitac to tezko "vidi". Nektere znaky jsou opravdu vizualne naprosto stejne. Najdete si ten generator homonym.TL,DR: je to blbost, nastesti se na tom shodne vetsina odborne verejnosti. Hodilo by se to jen registratorum (castecne, zase zvysene naklady za kontroly) a podvodnikum.
Tak, jak nikdo nepozaduje, aby si mohl registrovat verejnou IPv4 312.118.11.266, se proste v DNS pouziva latinka.
Priste by nekdo mohl chtit, aby DNS resolvery prekladaly hlasovy zaznam slovackeho nareci
-
Palo (neregistrovaný)
Ale nikoho nezaujimaju hricky. Proste aj pri jemnom preklepe to nevadi. Pripadne zafunguje cesky napisana domena a VZDY vas zavedie na to iste miesto.
a) staci riesit cesku ostatne proste ako doteraz zahlasia chybu - nic hrozne
b) registruju sa stale domeny LEN bez diakritiky
Zjavne hladate ako sa to neda bez toho aby ste skusili pochopit co myslim. -
a (neregistrovaný)
> Ale nikoho nezaujimaju hricky. Proste aj pri jemnom preklepe to nevadi.
Zajimaji, phishery a domenove vyderace.
Mam treba stranky o spani a registruji si zi've.cz, ma ted (vetsi portal) zive.cz smulu, ptze ja budu mit tuto variantu? Nema to smysl, pokud domenam v latince prigenerujete vsechny ty permutace, pak nejde odlisit moje zi've.cz a bulvar z^ive^.cz, tj muzeme zustat u latinky zive.czPokud nekdo zcela nezbytne potrebuje psat hacky carky do URL kam nepatri, mohl by byt plugin do prohlizece, ktere vam to konvertuje.
Jdu radsi na slunicko, tato diskuse nema smysl. hezky den,
-
Filip JirsákStříbrný podporovatel
vsechny "permutace" ve VSECH diakritikach (nejen cz)
Mohl byste uvést aspoň jeden důvod, proč by v TLD.czměly být povolené jiné než české znaky?nastesti se na tom shodne vetsina odborne verejnosti
Nikoli, odborná veřejnost je pro nasazení IDN v TLD.cz. Když se podíváte na ty průzkumy, výsledek „proti IDN“ způsobují neinformovaní lidé.se proste v DNS pouziva latinka
Vůbec ne. V DNS se používá IDN, jenom v pár doménách – např. v tradičně konzervativním Česku – se používají jen ASCII názvy. -
Filip JirsákStříbrný podporovatel
Co třeba takové přehlásky?
Které české znaky s přehláskou vypadají stejně, jako jiný český znak? -
Nedostanou. DNS je jenom spodní vrstva celého aplikačního stacku. Analogicky byste pak mohl chtít, aby ke každé IPv4 adresa byla automaticky přiřazeno několik IPv6 adres, a měly by všechny fungovat.
Problémem s internet naming se zabývá i IETF v rámci DNSBUNDLED BoF (viz https://datatracker.ietf.org/doc/draft-yao-bundled-name-problem-statement/) a osobně si myslím, že bundlovaní jmen je natolik komplikované, protože zasahuje do mnoha míst stacku, že se to nikam nedostane.
-
A v klientovi použitého protokolu poznáte, že zrovna v případě
živě.cz. IN CNAME zive.cz.se klientská strana má řídit cílovým doménovým jménem, ale v případězive.sk IN CNAME zive.cz.má použít původní doménové jméno?Prosím přestaňte házet "řešení od stolu" a nejprve se nad tím zamyslete. Internet naming (včetně aliasů) je bohužel dost komplikovaná záležitost a DNS je v tom jenom maličký střípek.
-
Ad 1) Nevím, jak to souvisí s diskuzí, ale ACK.
Ad 2) V Kerberu to platí pro SPN, ale platí to i pro realm? (Nevím, ptám se)Každopádně tím, že existují protokoly, které používají cílové jméno z DNS (SMTP/MX, Jabber/PTR), ještě není důkazem toho, že DNS Bundling funguje. DNS Bundling není dobrá cesta bez ohledu jak se na to díváte, protože nic moc neřeší. Mnohem horší jsou ty vyšší vrstvy bez ohledu na to, jestli konkrétní protokol zabalíte do TLS nebo ne.
-
Díky za upřesnění. Pokud tomu dobře rozumím tak CNAME redirection pro realm nefunguje, tj. identita, kterou se hlásím musí být stejně v kanonickém tvaru.
Pokud tomu tak není, tak bych potřeboval nějakou trochu složitější ukázku.
Já ale přece nikde netvrdím, že to bude fungovat bez DNS. Já jenom tvrdím, že to nebude a ani nemůže fungovat jenom na základě DNS, protože je potřeba, aby name bundling řešily i vyšší protokoly.
Zároveň si uvědomte, že pouhé nasměrování aliasu někam je "málo", protože to ve chvílích autokonfigurace vyššího stacku může mít různé (bezpečnostní, právní) implikace. Tj. nakonec se stejně dostanete do bodu, kdy vlastník cíle musí mít možnost řídit, jaké jmenné aliasy na něj ukazují. Ať už pomocí nějakého "reverzního CNAME" nebo explicitní konfigurací.
Už jenom to, že by docházelo k automatické konfiguraci na úrovni DNS může mít takové vtipné důsledky, kdy výchozí konfigurace např. webového serveru ukazuje na nějaký #nfsw obsah, a pouhým přidáním
zíve.cz IN CNAME zive.cz.by při překlepu takový obsah zobrazilo.Pokud by o to byl zájem, tak můžu na tohle téma zprasit^H^H^Hcovat nějakou přednášku/workshop.
-
Sten (neregistrovaný)
CNAME redirection pro samotný realm nefunguje, protože realm se neresolvuje přes DNS a ani nemusí odpovídat existující doméně (root.cz by třeba mohl mít realm „IINFO“). Ten TXT záznam se používá pro realm autoconfig, kdy se z doménového jména hledá realm, který je potřeba použít. Uživatel zadá jméno bez realm a Kerberos klient jej sám doplní. Když uživatel realm zadá, musí být v kanonickém tvaru.
Přednáška by byla zajímavá (i když možná by stačil nějaký článek). Z bezpečnostního hlediska to v nejhorším jen nebude fungovat, ne? Ale ty právní problémy mě k tomu nenapadly.
-
Nevymyslím teď z hlavy hned nějaký konkrétní útok, ale asi bychom se mohli shodnout, že každá další komplexita přinesená do systému má vysokou šanci zvýšit attack surface.
Ještě jeden draft, který teda Yao taky nechal vyhnít[*]: https://tools.ietf.org/html/draft-yao-bundled-name-problem-statement-02
* - což jenom potvrzuje moji teorii, že ani Číňani, které to pálí asi zdaleka nejvíce (potřebují mapování traditional <-> simplified) to nejsou schopni posouvat dostatečně rychle kupředu.
-
Sten (neregistrovaný)
Nenapadá mě, jaký bezpečnostní problém by tam mohl být, který útočník nemůže vyvolat už teď tím, že vytvoří stejný CNAME na své doméně. Nic jiného tohle nedělá. Ani ten draft neuvádí jiný bezpečnostní problém.
Mimochodem ten draft zmiňuje, že doména .cat by tohle mapování měla používat.
-
> výchozí konfigurace např. webového serveru ukazuje na nějaký #nfsw obsah, a pouhým přidáním zíve.cz IN CNAME zive.cz. by při překlepu takový obsah zobrazilo.
To už je trošku edge case, ale různé problémy by byly nejspíš na spoustě webů. Co může takový webserver udělat, když mu přijde request s neznámou doménou:
a. Vrátí správný obsah. Na první pohled OK, ve skutečnosti to ale není to, co chceme. Vznikne tak duplicitní obsah pro vyhledávače, uživatelé budou mít oddělené cookies (přihlásím se na živě.cz, otevřu link na zíve.cz a najednou nejsem přihlášen), uložená hesla atd.
b. Vrátí obsah jiné domény, protože je jako defaultní – tj. Vámi zmíněný případ s NSFW.
c. Vrátí 404 – OK, ale asi ne v souladu s Palovým záměrem.
d. Vrátí stránku typu „Welcone to nginx“ – o trošku horší než 404, ale podobné.
e. Udělá redirect na kanonickou variantu. IMHO jediné řešení, které je správné a zároveň v souladu s Palovým záměrem. Bohužel ale asi bude poměrně vzácné. Stane se to asi spíše náhodou, pokud bude web dělat redirect s napevno zadanou absolutní URL, třeba z HTTP na HTTPS.Co tu zatím nkdo nezmínil, více domén druhého řádu sníží efektivitu HSTS, pokud to admin nebude řešit fakt důkladně pomocí ohacků typu načtení obrázku ze všech domén. A taky by pro všecny varianty musel mít certifikáty. Pokud bych chodil na web airbank.cz přes áířbáňk.cz (tady je mimochodem 31 variant doplnění české diakritiky), tak první požadavek nejspíš poputuje přes plain HTTP, i pokud jsem na webu již někdy byl.
-
Palo, jak už jsem říkal - přestaňte chrlit povrchní "řešení od stolu" (DNS server udělá...). Ručím Vám za to, že pokud takhle vyplivnete nápad, tak už ho před Vámi vymyslel nejméně jeden člověk a dlouze se nad tím diskutovalo.
Viz https://tools.ietf.org/id/draft-sury-dnsext-cname-dname-00.html a https://tools.ietf.org/html/draft-yao-dnsext-bname-06 a související diskuze v dnsext a dnsop WG + ten BoF, který jsem zmiňoval výše. Opravdu doporučuji se do toho začíst, a přijít zpátky až se v problematice budete lépe orientovat.
-
anon (neregistrovaný)
@Palo: ty tu co riesis za blbosti? diakritika je blbost
Argument ze ked je niekto tela a napise do URL diakritiku a (podla dns) dostane od prehliadaca error ze stranka neexistuje tak si to hodi do google.com, zoznam.sk apod a ten ho hned presmeruje na spravnu adresu.
Vyrabat novy problem len preto ze niekto ma uchylku na diakritiku je dobry fail.Schvalne mi ukaz dnes jedneho cloveka ktory nevie ze stranky sa pisu bez diakritiky?
-
xxxxx (neregistrovaný)
A co ssl/https/DANE/.... pak by zase lidé řvali, že jim to nejde.
Pokud už něco, tak rozhodně ne automaticky, ale na vyžádání. A i to má obrovské problémy.
Za chvíli by začali (_oprávněně_ za daného stavu) řvát jiní, že tam chtějí konverzi i pro slovenské, pak polské (Slezsko), pak cyriliku a hlaholiku (logické, patří to přímo do naší historie), pak i znaky pro rusínštinu (také součást historie). A pak že rusínština a hlaholice atd je nesmysl překládat do latinky a přesto to k nám patří, tak povolit přímo (a budou mít pravdu). A tak až donekonečna. Jo, a také jidiš. A také němčinu (její znaky a bude se hádat, která konverze je správná). Jo a také ...
-
Petr M (neregistrovaný)
Jenomže IDN se neomezuje na IS8859-2, CP-1250 ani na "WCHAR" obecně. Používá UTF-8 a když ho povolíš, tak najednou myslíš, že koukáš na "AB" v latince a ono je to ALFA a V v azbuce. A o tom je ten průšvih.
Další problém je, že odjedu na služebku nebo na dovolenou a pokud si dotyčný nezaregistruje i alternativu bez IDN, mám s místní klávesnicí smůlu.
-
Adam KaliszStříbrný podporovatelAsi můžete i tak použít vyhledávač nebo unicode U+#### číslo. Taky přenastavit klávesnicí nemusí být takový problém, většina lidí cestuje se svým zařízením nebo ve firmě používají přinejmenším podobné vybavení. Těch případů, kdy byste byl skutečně nahraný si dokáží vykonstruovat několik, ale právě vykonstruovat....
-
Filip JirsákStříbrný podporovatel
Nedávno proběhl další pravidelný průzkum veřejného mínění a uživatelé si diakritiku (IDN) v doméně .CZ nepřejí. Takže realita je přesně opačná: CZ.NIC se řídí tím, co mu přikáží jeho členové a ti se v tomto případě řídí také průzkumem veřejného mínění.
K úplnému popisu reality chybí doplnit ještě několik maličkostí: v těch průzkumech to rozhodují neinformovaní lidé. Když se vezmou v úvahu jen odpovědi lidí, kteří tvrdí, že mají o problému dostatek informací, výsledek je opačný – tedy pro zavedení IDN. A CZ.NIC se zrovna nepřetrhne v osvětě ohledně IDN a nemá potřebu rozptylovat obavy lidí (třeba že by IDN mohl zaregistrovat jen majitel odpovídající ASCII domény) – pokud vím, jediný veřejný počin je proti-IDN web www.háčkyčárky.cz. -
MarSik (neregistrovaný)
> K úplnému popisu reality chybí doplnit ještě několik maličkostí: v těch průzkumech to rozhodují neinformovaní
> lidé. Když se vezmou v úvahu jen odpovědi lidí, kteří tvrdí, že mají o problému dostatek informací, výsledek je
> opačnýNějaký zdroj, kterým byste to doložil?
A kdo je podle Vás dostatečně informovaný? Člen IETF? Zaměstnanec registrátora? Technický správce domény? Sysadmin zodpovědný za WWW prezentaci?
-
Filip JirsákStříbrný podporovatel
Nějaký zdroj, kterým byste to doložil?
Píšu o těch průzkumech, které si CZ.NIC nechává každé dva roky dělat. Konkrétně v tom z roku 2016 je to v bodu 4.1 na straně 7 – z informovaných je to 54 % pro IDN, 38 % proti, 8 % neví. U vlastníků domén je to dokonce ještě o 3 procentní body víc ve prospěch IDN.A kdo je podle Vás dostatečně informovaný?
Ne podle mne, psal jsem „odpovědi lidí, kteří tvrdí, že mají o problému dostatek informací“. Předpokládám, že to rozdělení je na základě odpovědí, které jsou v obou výše uvedených zprávách na straně 10 dole, v té druhé je to výslovně okomentováno: „Polovina respondentů se považuje za dobře informované o problematice diakritických znamének v doménových názvech. Platí, že významně větší podpora používání diakritických znamének je patrná mezi informovanými respondenty.“ -
@Jirsák
tím háčkyčárky.cz samozřejmě myslíte tohle, že? https://www.xn--hkyrky-ptac70bc.cz/
sorry, ale takovéhle domény si strčte víte kam, dobré akorát pro phishing. -
Cuba (neregistrovaný)
IDN je zlo. Ale jestli nutně potřebujete ěščřžýáí, pak:
a) provozujte si jej v doménách třetího a vyššího řádu na vlastním resolveru tak, jak to má třeba Ondra Caletka: https://ondřej.caletka.cz
b) provozujte si jej na doménách, které IDN podporují (ale budete čelit problémům) - domény .com nebo .eu umí háčky čárky.
ČLÁNKY DO MAILU