Názory k článku Doména .CZ spouští jako první automatickou správu DNSSEC klíčů
-
Filip JirsákStříbrný podporovatelTo automatické zavedení „chráněné“ jenom použitím TCP a notifikačním e-mailem se mi nelíbí. Silně mi to připomíná DV certifikáty, kdy na začátku zavřeme oči, doufáme, že ověříme toho správného, a pak už se tváříme, že je všechno v pořádku, protože přece máme ověřený certifikát. Doufal jsem, že s DNSSEC to bude jinak, že bude možné tomu opravdu důvěřovat.
Chápu, že je snaha DNSSEC co nejvíc rozšířit, ale nemělo by to být za cenu snížení bezpečnosti.
Předpokládám, že ta blokace na úrovni registru (v doménovém prohlížeči) se dělá přes „Blokovat všechny změny“, žádnou samostatnou volbu pro DNSSEC jsem tam nenašel.
-
Filip JirsákStříbrný podporovatel
Máte nějaký konkrétní attack vector nebo je to jenom handwaving?
To je vážně myšlená otázka? Vektory útoku jsou přesně ty samé, jaké jsou proti nepodepsanému DNS – a jsou to ty samé, kvůli kterým se zavádí DNSSEC. Třeba únos TCP spojení, což může udělat každý router po cestě. Pokud byste dokázal získat spolehlivě údaje z DNS bez DNSSEC, pak by přece DNSSEC bylo zbytečné.Je pravda, že nějaký klient někde na WiFi asi bude k útoku na DNS náchylnější, než třeba certifikační autorita, která ty DNS dotazy snad dělá z více míst a výsledky porovnává. CZ.NIC bude někde mezi. Certifikačním autoritám se vytýká, že u DV certifikátů spoléhají na to, že jim nikdo nepodvrhne falešnou DNS odpověď – a že je tedy potřeba tyhle nejisté DV certifikáty nahradit kombinací DNSSEC a dalších technologií, u kterých přesně víme, co je potřeba splnit, aby to bylo bezpečné. A teď najednou začnete nasazovat DNSSEC tímhle nebezpečným způsobem.
Nejhorší na tom je, že se tím rázem sníží důvěryhodnost celého DNSSEC.
Pokud chcete secure to secure bootstrap, tak si nastavte DNSSEC už dnes a bootstrap bude probíhat komplet zabezpečeně.
Jasně. Ale to udělá někdo, kdo o DNSSEC ví a pohlídá si to. V nebezpečí jsou ty domény, jejichž vlastník se o DNSSEC z nějakého důvodu nestará. Teď se výrazně zvýšilo riziko, že se do DNS dostanou klíče útočníka. Z pohledu vlastníka domény je to jedno, jestli má doménu nepodepsanou nebo ji má podepsanou útočníkem. Z hlediska klienta to ale jedno není, protože pro mne teď DNSSEC přestává být zárukou toho, že odpověď nikdo cestou nezměnil a poslal ji právoplatný majitel domény, a už mi zaručuje jenom to, že odpověď nikdo cestou nezměnil. To není špatné, ale podle mne je to zbytečné oslabení. Zejména s ohledem na to, že DNSSEC má ambici vytlačit DV certifikáty s odůvodněním, že to vydání DV certifikátů není dostatečně zabezpečené. -
Filip JirsákStříbrný podporovatel
Konkrétní útok je například únos spojení, kterým se dotazujete na ty DNS záznamy (CDNSKEY a MX pro zaslání notifikačního e-mailu). Pokud mám DNS server v datacentru, může takový únos proběhnout třeba na routeru toho datacentra. Pokud útočník (třeba motivovaný zaměstnanec datacentra) takovýhle útok provede, může upravit DNS a přesměrovat třeba HTTPS komunikaci na svůj server. Protože ovládá DNS, nechá si pro ten svůj server vystavit i platný důvěryhodný DV certifikát. Dříve by platilo, že při pokusu o přístup k takovému serveru nedostanu odpověď podepsanou DNSSEC, tak bych měl zbystřit a pokud je to něco důležitého, ověřit si, zda skutečně komunikuju s tím správným serverem. Teď ale v tom samém případě můžu dostat i správně podepsanou DNSSEC odpověď, která mi tudíž bude k ničemu.
Že bude útočit nějaký ISP není úplně běžná situace, ale já když komunikuju třeba s bankou, nechci spoléhat ještě na všechny ISP po cestě, o kterých nevím ani to, kolik jich je. DNSSEC umožňuje to, že se musím spoléhat jen na registrátora a registr, tedy jsem chráněn proti útokům v celé síťové infrastruktuře. S tím nebezpečným bootsrapem se celý DNSSEC degraduje na ochranu poslední desítky (ani ne poslední míle) – aby mi náhodou někdo na stejné WiFi síti nebo na stejném switchy nepodstrčil UDP paket s falešnou DNS odpovědí.
-
Tohle je hodně špatně položená otázka. Vy máte dokázat, že žádný attack vektor který snižuje důvěryhodnost toho secure není. A ne vyžadovat aby vám na attack vektor někdo přišel. Jinak předvádíte handwaving místo důkazu bezpečnosti.
Teoretický útok existuje - spojení mezi mým DNS serverem a vaším serverem někdo unést může, jak psal již pan Jirsák. A může pak nastavit vlastní klíče. V budoucnu pak bude moct unést spojení a přesvědčit klienta (dalším únosem spojení) který bude věřit DNSSEC+DANE, že on má ten správný certifikát, i když jeho certifikát nebude podepsaný důvěryhodnou kořenovou autoritou. -
Ondřej CaletkaZlatý podporovatelJakákoli akce má v sobě nějaké útočné vektory. Vždy je třeba zvážit rizika a míru jejich pravděpodobnosti. Už dnes například může útočník přiřadit k doméně keyset třeba hacknutím registrátora, nebo technikou Man-in-the-Browser, nebo dalšími podobnými metodami, kterými se dnes třeba kradou peníze z webových bankovnictví.
Zavádění keysetu na základě nepodepsaného DNS je samozřejmě problém, ovšem konkrétní realizace se sedmidenním soustavným dotazováním představuje podle mého názoru dostatečnou úroveň bezpečnosti, kterou bych řadil na rovnost právě útokům na registrátora. A rozhodně je to způsob výrazně bezpečnější, než třeba DV validace certifikátů. -
kterou bych řadil na rovnost právě útokům na registrátora
Tím ale říkáte, že když by se nám podařilo přesvědčit české registrátory aby si zvedli svoji bezpečnost* tak bude toto slabším článkem.*) je to trochu utopie, ale na druhou stranu je v zájmu cz.nic se o něco podobného snažit ve chvíli kdy to bude jeden z nejslabších článků bezpečnosti
-
Filip JirsákStříbrný podporovatel
Problém je v tom, že to riziko je nenulové. Tím pádem to snižuje bezpečnost celého DNSSEC. Vždy je potřeba zvážit nejen rizika, ale také přínosy. A v tomto případě je přínos (výměnou za to riziko) nulový – vůbec nebylo potřeba implementovat to tak, že bude NIC.CZ aktivně vyhledávat nezabezpečené servery, které mají příslušný záznam. Když je možné to zablokovat přes Doménový prohlížeč, dalo se to udělat přesně opačně – přes Doménový prohlížeč to povolit. Tím by se to riziko výrazně snížilo.
třeba hacknutím registrátora
To je doufám nesrovnatelně menší riziko.A rozhodně je to způsob výrazně bezpečnější, než třeba DV validace certifikátů.
Výrazně? Dotazovat se DNS přes TCP mohou certifikační autority klidně už teď, posílat notifikační e-mail na hostmastera také, a sedmidenní opakované dotazování by nebyl problém zavést. Certifikační autority naopak používají dotazování z více míst. Řekl bych, že obojí brání spíše náhodným únosům domény, ale útočníka, který by měl tu doménu jako cíl, to nezastaví. -
Ondřej CaletkaZlatý podporovatel
Problém je v tom, že to riziko je nenulové.
Každé riziko je nenulové. U postupu podle RFC 8078 asi dosud nemohou existovat žádná data o incidentech, takže můžeme jen míru rizika jen odhadovat.
> třeba hacknutím registrátora
To je doufám nesrovnatelně menší riziko.Naopak, hacknutí registrátorů je jev, ke kterému dochází relativně často, minimálně v jednotkách případů ročně. Čas od času takový incident dokonce vyplave na povrch.
Výrazně? Dotazovat se DNS přes TCP mohou certifikační autority klidně už teď, posílat notifikační e-mail na hostmastera také, a sedmidenní opakované dotazování by nebyl problém zavést. Certifikační autority naopak používají dotazování z více míst.
Myslím, že speciálně ta sedmidenní lhůta by byl velký problém. Dotazování z více míst přinejmenším Let's Encrypt, coby největší DV CA, nedělá, notifikační e-maily taky neposílá, zatímco CZ.NIC ano.
Řekl bych, že obojí brání spíše náhodným únosům domény, ale útočníka, který by měl tu doménu jako cíl, to nezastaví.
Útočník, který bude mít doménu jako cíl, může klidně zfalšovat ověřený podpis a předelegovat doménu jedním dopisem do CZ.NIC. Je to možná ještě jednodušší, než zkoumat, odkud CZ.NIC zkoumá
CDNSKEYzáznamy a snažit se unést IP provoz. -
Filip JirsákStříbrný podporovatel
Každé riziko je nenulové, ale tady je to riziko zbytečné. Nebo snad existuje nějaký důvod, proč aktivně hledat CDNSKEY záznamy na serverech bez DNSSEC? Vždyť stejného výsledku by se dalo dosáhnout tím, že vlastník domény někde jednou klikne v administraci. Náročnost pro uživatele by se zvýšila nepatrně, zato bezpečnost významně.
Mimochodem, sedmidenní lhůta by pro CA nebyl žádný problém. České CA vydávají osobní certifikáty na fakturu – předpokládám, že když nezaplatíte, certifikát revokují. Tady by šlo postupovat stejně – certifikát vydat hned, a pokud se během sedmi dnů nepodaří opakovaná validace, certifikát odvolat.
-
Ondřej CaletkaZlatý podporovatel
Není zbytečné. Kdyby bylo zbytečné, tak by nikdo RFC 8078 nepsal a CZ.NIC by ho neimplementoval. Evidentně je zde převládající názor, že možnost výhoda
v možnosti zavádět DNSSEC bez účasti uživatele toto nepatrné riziko vyvažuje.Kdyby například bootstraping byl navázán na nějaké tlačítko, třeba v Doménovém prohlížeči, dostali by se k němu jen ti, kdo mají doménu vázanou na validované mojeID. Kdyby šlo o tlačítko, které by měl implementovat registrátor, žádný ho implementovat nebude, nebo bude za kliknutí na něj vybírat nesmyslné poplatky. CZ.NIC by se registrátory teoreticky mohl pokusit donutit, ale ani to by nejspíš nefungovalo, protože věci protlačené silou obvykle dobře nefungují.
-
Filip JirsákStříbrný podporovatel
Teď se k tlačítko blokace změn v Doménovém prohlížeči také dostanou jen ti, kdo mají doménu vázanou na validované mojeID.
K tomu nucení registrátorů – ono to bez nich stejně nepůjde, a jejich obcházení, pokud by se v něm pokračovalo, se jednou vymstí.
věci protlačené silou obvykle dobře nefungují
Což platí i o nasazování DNSSEC. -
Když teď nad tím zpětně přemýšlím, tak by bylo pěkné, kdybyste zároveň publikovali (třeba TXT) záznam o tom, jakým způsobem byl DNSSEC bootstrapnut. Pak by měl klient možnost ověřit o jaký typ DNSSEC jde (stejně jako má teď možnost rozlišit, jestli SSL certifikát je EV, OV nebo DV). Pokud by se takovéto řešení navíc standardizovalo, tak by mohl dnssec validátor, nebo prohlížeč zobrazit úroveň zabezpečení.
Vlastně pokud má DNSSEC suplovat PKI v některých aspektech, tak by asi měl nést informaci o tom, jak bezpečně byla ověřena delegace.
-
V tomto případě určitě nelze dokázat, že žádný attack vektor neexistuje. Naopak, pokud by se vám to povedlo, znamená to, s největší pravděpodobností, že máte v tom důkazu někde chybu... Ale lze to považovat za pravděpodobnou hypotézu, pokud tomu různé okolnosti nasvědčují a dokud se nepodaří dokázat opak, na což stačí alespoň jeden takový attack vektor. Ostatně, není to nic jiného než léty ověřená "vědecká metoda".
-
Já si nemyslím, že je to špatně položená otázka. Můžeme se bavit, o konkrétních rizicích a zmírnění/eliminaci jejich dopadů, ale těžko se dá diskutovat na základě prohlášení typu "panebože, ale to je nebezpečné" (hyperbola).
Prostě se domníváme, že riziko toho, že dojde k MITM útoku na všechny nameservery bootstrapované (insecure->secure) domény, je v této implementaci zanedbatelné, a dopady falešného bootstrapu nejsou horší než dopady toho, že někdo takovýmto způsobem ovládá celý DNS provoz na všech nameserverech bootstrapované domény. Tj. i kdyby k útoku došlo, tak dopady podvržení DS záznamů jsou mírnější než dopady všech ostatních útoků, které se na takovou doménu dají v případě tohodle druhu kontroly dělat.
Také je samozřejmě možné, že jsme na nějaký attack vector nepřišli, a v tom případě je opět důležité se bavit konkrétně, a nikoli obecně. Zatím jsem se ovšem v celé dlouhé diskuzi dočetl o tom, že existuje riziko MITM všech DNS dotazů na všechny nameservery napadené domény po dobu minimálně sedmi dní.
-
Filip JirsákStříbrný podporovatel
Zatím jsem se ovšem v celé dlouhé diskuzi dočetl o tom, že existuje riziko MITM všech DNS dotazů na všechny nameservery napadené domény po dobu minimálně sedmi dní.
Až na tu dobu 7 dní je to podle mne úplně stejné riziko, jako riziko, před kterým má chránit DNSSEC. Znamená to, že DNSSEC je zbytečnost, protože stejného výsledku dosáhnu, pokud se budu dotazovat přes TCP všech nameserverů napadené domény?Tu dobu sedmi dní nepovažuju za nijak zásadní zvýšení bezpečnosti. To je obrana proti omylům, když by někdo někam získal na chvíli omylem neoprávněný přístup. Ale pokud někdo získá přístup záměrně (třeba ovládá nějaký router), těch 7 dní pro něj nebude žádná překážka.
-
Kolemjdoucí (neregistrovaný)
Jsem správce vlastích DNS serverů a DNSSEC nám registrátor neulehčuje. Za distribucí vlastního keysetu chce 300. To samé za každou změnu.
Pokud to s DNS myslíte vážně, tak máte alespoň dva , lépe tři vlastní autoritativní servery a každý v jiném AS. Přenosy zón pak provádíte buď přes TSIG nebo VPN.. Útok na podvrženi záznamů ze třech různě umístěných serverů po tak dlouhou dobu mi přijde až nereálný.
Myslím, že v tom hledáte zbytečný problém, protože většina konzumentů obsahu se spoléhá na své ISP a Ti mnohdy nemají ani zapnutou validaci DNSSEC.Drtivá většina úspěšných útoků je úspěšná jen díky naprosté liknavosti a ignoraci zodpovědných lidí. Pokud si vaši společnost vybere skupina opravdových hackerů či státem dotovaných, tak podlehnete. Je to jen otázka času a investovaných prostředků.
Pavel P.
-
Ondřej CaletkaZlatý podporovatel
Co vás u daného registrátora drží? Všichni normální registrátoři registrují keyset zdarma, převod domény jinému registrátorovi je také zdarma a okamžitě. Navíc keyset nemusí být registrovaný u stejného registrátora jako doména.
-
kolemjdoucí (neregistrovaný)
Dnes už nic, v tuto chvíli už máme jiného registrátora, KEYSETy nastavené ručně.
Převod byl komplikovanější, protože řada zákazníků měla domény hostované u tohoto registrátora se správou přes web jejich účtu.
Pro změny v jejich DNS jsem pak mohl použít náš účet tamtéž.Já jsem použil naši situaci, která byla platná před několika měsíci, že může být důvod k delegaci skrze doménu.
-
Filip JirsákStříbrný podporovatel
Já jsem použil naši situaci, která byla platná před několika měsíci, že může být důvod k delegaci skrze doménu.
Což tady nikdo nezpochybňoval. Zpochybňuju to, že je možné udělat delegaci přes nezabezpečenou doménu, aniž by bylo nutné to potvrdit jiným bezpečným způsobem. -
Kolemjdoucí 22:38
A jak se váš DNSSEC odliší od DNSSEC domény založené původně pro SEO, mající jen jeden DNS server, v lepším případě dva nic moc oddělené DNS servery? A jak pak budete svým uživatelům vysvětlovat, že vaše doména je ta dobrá a tamta je ta špatná, když jsou obě zabezpečeny stejnou technologií? Dnes se brojí proti http protokolu, ale myslím, že se velice brzy přijde na to, že míra zabezpečení DV certifikátů není o moc lepší.Mě vadí to, že DNSSEC + DANE vypadalo velmi nadějně, ale tohle znamená, že já jako uživatel nemohu dát plnou důvěru v DNSSEC + DANE, protože nečinnost administrátora mohla způsobit, že klíče vlastní někdo jiný. Navíc kvůli pomalému zavádění DNSSEC se může stát, že se nepřijde na to, že vlastník klíče nemá, protože bude celá doména nepodepsaná, jen na ni bude existovat delegace.
-
Ondřej CaletkaZlatý podporovatel
Předpokládám, že ta blokace na úrovni registru (v doménovém prohlížeči) se dělá přes „Blokovat všechny změny“, žádnou samostatnou volbu pro DNSSEC jsem tam nenašel.
Ano, přesně tak.
-
Petr M (neregistrovaný)
Proto je tam ten týdenní monitoring a mail.
Pochopil jsem to tak, že se pošle info majiteli domény. Pokud je to OK, po týdnu se použije, co je. Pokud ne, tak to majitel domény opraví, tím dojde ke změně a doména vypadne.
Majitel má možnost se dozvědět z mailu, že někdo možná něco fejknul a nastavit to ručně, korektně a bezpečně, nebo to jenom během toho týdne upraví odpočet od změny se restartuje...
A když se o doménu její majitel nezajímá / nestará, tak to holt má blbý.
-
Filip JirsákStříbrný podporovatel
E-mail nemusí majiteli domény dojít – zejména když bude útočník schopen podvrhnout CZ.NICu svou vlastní verzi zóny. Týdenní monitoring znamená, že musí útočník udržet tu svou vlastní verzi domény servírovanou CZ.NICu týden – myslím si, že je to ta méně obtížná část, obtížnější bude CZ.NIC vůbec na svůj server přesměrovat.
-
Filip JirsákStříbrný podporovatel
V tom případě mi asi uniká celý smysl DNSSEC. Myslel jsem si, že DNSSEC má sloužit právě k tomu, aby nemohl někdo podvrhnout odpověď na trase mezi DNS serverem a klientem.
-
Filip JirsákStříbrný podporovatel
Mohl byste naznačit postup? Dejme tomu, že kamarádovi hostuju na svém počítači jeho autoritativní server pro doménu
example.cz. Mám tedy možnost kdykoli přesměrovat komunikaci z jeho DNS serveru na svůj. Jak zařídím, abych z mého serveru mohl posílat odpovědi na dotazy z jeho domény, které budou podepsané DNSSEC a které projdou validací (např. DNSSEC/TLSA Validator je označí zeleně)? -
Pokud jste útočník, který je schopen in-path útočit na všechny autoritativní servery konkrétní zóny, tak je to efektivně stejné, jako by DNS servery provozoval útočník. Bootstrap z insecure->secure jste pak schopný udělat poměrně jednoduše, protože kontrolujete veškerý DNS obsah té domény. Taky budete schopný si vystavit certifikát pro TLS, atp. To, že doména jirsak.cz má email v doméně jirsak.org je podružné, protože obojí má stejnou sadu jmenných serverů.
Takže jak jsem již psal na začátku, bootstrap DNSSECu bude v takovou chvíli váš nejmenší problém, a pravděpodobně by takový útočník způsobil jen to, že doména bude Bogus, a nikoli Secure.
-
Filip JirsákStříbrný podporovatel
To ale odpovídáte z pohledu vlastníka domény. Já jsem ale psal, že tam problém není – problém je z pohledu klienta. Pokud jako klient dostanu nepodepsanou odpověď, vím, že tomu nemám věřit. Jenže nově můžu dostat i podepsanou odpověď, které se nedá věřit – a nemám jak jí odlišit od důvěryhodné podepsané odpovědi.
Vystavení DV TLS certifikátu bych zrovna nedával jako vzor, DV certifikáty mají dost podstatné chyby, a očekává se, že DNSSEC bude klíčová technologie, která umožní problémy DV certifikátů vyřešit. Ale můžeme vzít právě certifikační autoritu vystavující DV certifikáty jako modelový příklad. Pokud by taková certifikační autorita chtěla opravdu ručit za svůj podpis na DV certifikátech, musí si dát do podmínek, že bude podepisovat jedině certifikáty podepsané DNSSEC – protože jinak není schopna garantovat, že zjišťuje údaje z DNS od skutečného vlastníka a ne od podvodníka. Jenže teď by jí taková podmínka byla k ničemu, protože by nedokázala rozlišit, zda vlastník opravdu má doménu podepsanou DNSSEC, a nebo ji původně podepsanou neměl, došlo k únosu domény a podepsal ji útočník.
Jenom pod čarou upřesním, že útočník obvykle nemusí útočit na všechny autoritativní servery konkrétní zóny, obvykle mu bude stačit ovládnout komunikaci master serveru a slave servery už si podvrženou zónu stáhnou samy.
-
Prostě ve svém svatém zaslepení nejste schopný uznat, že by někdo jiný než Vy mohl mít pravdu. Na tuto zprávu nemusíte odpovídat, není určena pro Vás, stejně jen dokola zopakujete to, co jste již řekl několikrát.
Takže to zopakuji jen pro ostatní - pokud někdo může manipulovat s DNS záznamy od všech nameserverů po cestě (tj. TCP) po poměrně dlouhou dobu (7 dní), tak je bootstrap DNSSECu z insecure na secure ten nejmenší problém dané domény, protože těch útoků, které se manipulací DNS záznamů udělat je více, a jsou závažnější - například bude poměrně jednoduché celou tu doménu unést.
Z pohledu držitele domény je obrana docela jednoduchá:
a) podepsat DNSSECem už nyní, a nastavit si první klíč manuálně, tak aby bootstrap pomocí CDNSKEY proběhl v módu secure->secure
b) diverzifikovat cesty a poskytovatele DNS serverů. Nemít jen jednoho, ale mít alespoň dva.
c) notifikační email nastavit na jinou doménu, která ja hostovaná na jiných nameserverech.Z pohledu dalších konzumentů DNSSEC domén se situace opět neliší - špatně zabezpečená doména bude nedůvěryhodná bez ohledu na to, jestli bude podepsaná nebo ne. Některé Attack Vectory byly popsány již výše, možná bych ještě zmínil hacknutí správce zóny (několik útoků na high-profile cíle v nedávné době), a většina z nich je jednodušší než dělat DPI na DNS, abych manipuloval jen s DNS provozem konkrétní domény.
Ale samozřejmě takového (state-level) útočníka, který podepíše všechny nepodpsané domény DNSSECem, snad možná i uvítáme s otevřenou náručí :)
-
Filip JirsákStříbrný podporovatel
Pravdu samozřejmě může mít někdo jiný. Stejně jako si někdo jiný může myslet, že „z pohledu držitele domény…“ je relevantní odpověď na námitku „To ale odpovídáte z pohledu vlastníka domény. Já jsem ale psal, že tam problém není – problém je z pohledu klienta.“
diverzifikovat cesty a poskytovatele DNS serverů. Nemít jen jednoho, ale mít alespoň dva.
Tohle není obecně použitelné řešení. Domény se obvykle mezi servery synchronizují také protokolem DNS a to z jednoho hlavního serveru. Takže pokud se útočníkovi podaří ovládnout komunikaci toho hlavního serveru, ostatní servery ochotně převezmou zmanipulovaná data.Z pohledu dalších konzumentů DNSSEC domén se situace opět neliší - špatně zabezpečená doména bude nedůvěryhodná bez ohledu na to, jestli bude podepsaná nebo ne.
Jenže DNSSEC nechrání doménu, DNSSEC chrání DNS odpovědi na trase mezi serverem a klientem. Což je věc, kterou jinak vlastník domény nemůže ovlivnit (pokud někdo bude provozovat nezabezpečenou WiFi a někdo tam podvrhne UDP paket s DNS odpovědí, není to „špatně zabezpečená doména“ ani nic, co by mohl majitel domény ovlivnit jinak, než DNSSEC nebo jiným podepisováním odpovědí). Takže situace se z pohledu konzumentů DNSSEC liší zásadně. Pokud jako konzument DNS důvěřuju všem ISP po cestě, nepotřebuju žádné DNSSEC. Pokud ISP nedůvěřuju, mohl jsem se dříve spolehnout na DNSSEC. Nyní už to neplatí, protože DNSSEC je nyní důvěryhodné jedině tehdy, pokud důvěřuju i všem ISP, kteří mohli ovlivnit bootstrap..Ale samozřejmě takového (state-level) útočníka, který podepíše všechny nepodpsané domény DNSSECem, snad možná i uvítáme s otevřenou náručí :)
Právě že se trochu bojím, jestli tohle už není pravda. Nevadí, že se sníží bezpečnost, hlavně když porostou procenta… -
Filip JirsákStříbrný podporovatel
U DV ta CA validuje zase jen na základě DNS. Podle mne mělo DNSSEC ověřit, že DNS odpověď vytvořil server, který je podle nadřazené zóny oprávněn zodpovídat dotazy pro danou doménu, a že tu odpověď cestou nikdo nezměnil. Teď už ale pro
.czzajišťuje jen to druhé. -
NULL (neregistrovaný)
Ale to podle mě nemá,už jenom protože NDS může provozovat kdekdo viz. [2] (lokální DNS) a jak pak ověřit kdo může co kam dávat a kde měnit? Tam je to pokud vím delegováno hierarchicky, to už dohledat jde a proto ten podpis a "čachry" s klíči
[1] https://datacentrum.wedos.com/a/175/co-je-jak-funguje-dnssec.html
[2] https://www.dnssec.cz/page/444/jak-funguje-dnssec/ -
Filip JirsákStříbrný podporovatel
Když píšu o DNS, myslím tím samozřejmě oficiální DNS strom s kořenem provozovaným ICANN. Pokud někdo provozuje alternativní DNS strom, je na něm, aby svým klientům řekl, jak jej mají validovat. Kdo co kam může dávat a měnit má řešit registr a registrátor – např. pokud si (zprostředkovaně) u NIC.CZ zaregistruju doménu
example.cz, má mi registrátor umožnit nějakým způsobem měnit záznamy týkající se této domény (delegaci jmenného serveru, DNSSEC klíče), a NIC.CZ a registrátoři mají zajistit, že to nebude moci změnit nikdo jiný, než já způsobem, který jsem si s registrátorem dohodl. -
Filip JirsákStříbrný podporovatel
Já vím, jak funguje DNSSEC. Pokud se vám nezdá něco v mém komentáři, napište konkrétně co. Takhle si tu ten odkaz můžeme vyměňovat donekonečna.
-
NULL (neregistrovaný)
Aha, ok. Nezdá se mi tohle:
"Když píšu o DNS, myslím tím samozřejmě oficiální DNS strom s kořenem provozovaným ICANN. Pokud někdo provozuje alternativní DNS strom, je na něm, aby svým klientům řekl, jak jej mají validovat."Řekl bych že "alternativní DNS strom" jsou běžné a právě i v nich lze pomocí DNSSEC dobře validovat záznamy. Ale také v tom "oficiální DNS strom s kořenem provozovaným ICANN" kde je (bez urážky) IMO stejná situace jako s důvětou v CA pomáhá DNSSEC, ale jak se píše v linku [1] výše:
Co naopak DNSSEC neřeší
...
podvodné přesměrování či podobný útok na úrovni IP adres – z DNS systému se sice bezpečně dozvíte správnou IP adresu, na kterou se potřebujete spojit, ale DNSSEC nezabrání tomu, aby vás při následné komunikaci s cílem “man-in-the-middle“ nenasměroval jinam
...protože ani z principu IMO nemůže. Spíš je to něco jako potvrzení připojené alá JWT např.
-
Filip JirsákStříbrný podporovatel
O podvodném přesměrování ale nebyla řeč. Jde o to, že DNSSEC může při odpovídající implementaci zajistit důvěryhodné odpovědi na DNS dotazy – tj. mohu si být jistý, že odpověděl ten, kdo podle registrátora odpovídat má, a že odpověď nebyla cestou změněna. Toho se dá využít třeba pro ověření SSL certifikátů – z DNS si stáhnu důvěryhodný otisk certifikátu a porovnám ho s tím, co my poslal server. Je to bezpečnější řešení, než DV certifikáty, které (bez DNSSEC) spočívají v tom, že se autorita zeptá přes nezabezpečené DNS a všichni doufají, že dostane nezfalšovanou odpověď. Jenže pokud může útočník jen ovládnutím nějakého uzlu síťové infrastruktury ovládnout doménový server a vložit do nadřazené domény svůj klíč, jsme zase tam, kde jsme byli – spoléháme na to, že v síťové infrastruktuře žádný útočník není. Pak ale nepotřebujeme DNSSEC… Jasně, pokud správce domény chce, může používat DNSSEC bezpečným způsobem. Jenže já jako uživatel se nedozvím, zda ta konkrétní odpověď podepsaná DNSSEC je důvěryhodná DNSSEC odpověď, nebo je to jen DNSSEC odpověď naroubovaná na nedůvěryhodné DNS.
Sice to funguje jako taková zvrácená výzva pro ty, kteří ještě DNSSEC na serverech nemají („zaveďte si DNSSEC, jinak to udělá někdo jiný za vás“), ale je to podraz na ty, kteří DNSSEC mají, protože to jejich důvěryhodné DNSSEC sráží na úroveň toho DNSSEC vyčarovaného z ničeho.
-
Filip JirsákStříbrný podporovatel
Netuším, na co se ptáte. DNSSEC může sloužit k tomu, abych ověřil, že odpověď na DNS dotaz vytvořil ten, kdo je k tomu oprávněn, a že tato odpověď nebyla cestou změněna. V
.czje momentálně zaručen jen ten druhý předpoklad. Když jsou splněny oba ty předpoklady, můžu použít třeba TLSA záznam a ověřit, že certifikát, který mi server poslal, opravdu patří k dané doméně (a nemusí mne vůbec zajímat, jaká autorita ten certifikát vydala). Když je splněn jenom ten druhý předpoklad, je mi TLSA záznam k ničemu, protože pokud útočník dokáže přesměrovat moji komunikaci na svůj server, dokáže s velkou pravděpodobností přesměrovat i komunikaci NIC.CZ a tedy DNSSEC klíč může být ve skutečnosti klíčem útočníka. -
NULL (neregistrovaný)
>> Filip Jirsák Dnes 15:47
"O podvodném přesměrování ale nebyla řeč. "
>> NULL (neregistrovaný) ---.freepoint.cz Dnes 15:55
Filip Jirsák Dnes 12:06
"
V tom případě mi asi uniká celý smysl DNSSEC. Myslel jsem si, že DNSSEC má sloužit právě k tomu, aby nemohl někdo podvrhnout odpověď na trase mezi DNS serverem a klientem
">> Filip Jirsák 100 Dnes 16:29
"Netuším, na co se ptáte."
Já se na nic neptám. Jenom ti ukazuji, že o podvodném přesměrování byla řeč, je řeč a pořád o tom píšeš ty a začal jsi ji ty. K tomu se pak taky vážou v kontextu mé příspěvky kde ti nabízím odpověď, že IMO není v kompetenci a možnostech DNSSECu kontrolovat průběh komunikace a ani to dělat nemá, má jenom zajistit ověření u nadřazených serverů, že DNS záznam nebyl podvržen, tedy že na všech nadřazených DNS serverech se klíče shodují a zaručovat to má to, že je tam dává někdo (registrátor a majitel domény) "ručně - a dokládám to linky [1] a [2] s tím, že klíč je poslán i v kladné odpovědi.
-
Filip JirsákStříbrný podporovatel
Já jsem o žádném podvodném přesměrování nepsal. Zkuste si to vyhledat v diskusi, první příspěvek, kde se slovní spojení „podvodné přesměrování“ vyskytuje, je váš komentář z 15:29.
Nepsal jsem ani nic o kontrole komunikace. Já jsem psal o podvržení DNS odpovědi. A to je přesně to, k čemu má DNSSEC sloužit – když na klientovi (tedy ideálně až v koncovém zařízení) ověříte DNSSEC podpis, máte jistotu, že jste dostal správnou odpověď (akorát teď není úplně jasné, co je „správná odpověď“).
Klasický případ, který se uvádí, je, aby vám někdo na WiFi síti nemohl podvrhnout odpověď třeba na dotaz na google.com a nepřesměroval vás tím na svůj server. A také se často uvádí, že validovat by měl buď resolver v koncové síti, nebo ideálně až resolver v koncovém zařízení. Tedy že se nemá validace nechávat na resolveru ISP, protože pak může útočník odpověď modifikovat ještě mezi resolverem u ISP a vaším zařízením. Pokud by DNSSEC zajišťovalo jenom to, že všechny servery budou vracet stejnou odpověď, tyhle příklady by byly nesmyslné.
DNSSEC neověřuje u nadřazených serverů, že DNS záznam nebyl podvržen. U nadřazených serverů se zkontroluje akorát to, že otisk klíče, kterým byla podepsána DNS odpověď, je u dané domény uveden jako platný klíč. Nebo-li že ten, kdo odpověď podepsal, má právo za danou doménu odpovědi podepisovat. A teď řešíme akorát to, zda právo podepisovat za danou doménu má mít jenom oprávněný vlastník dané domény, nebo pokud doména není podepsaná, zda si to právo může přisvojit i útočník (aniž by majitel domény udělal cokoli špatně).
-
NULL (neregistrovaný)
Filip Jirsák Dnes 17:53
Já jsem o žádném podvodném přesměrování nepsal.Filip Jirsák Dnes 12:06
"
V tom případě mi asi uniká celý smysl DNSSEC. Myslel jsem si, že DNSSEC má sloužit právě k tomu, aby nemohl někdo podvrhnout odpověď na trase mezi DNS serverem a klientem
"NULL: 15:29
podvodné přesměrování či podobný útok na úrovni IP adresŘekl bych, že pokud ti má někdo "podvrhnout odpověď na trase mezi DNS serverem a klientem" tak by něco jako "podvodné přesměrování či podobný útok na úrovni IP adres" měl použít.
Filip Jirsák Dnes 17:53
"Nepsal jsem ani nic o kontrole komunikace. Já jsem psal o podvržení DNS odpovědi."Jenomže pokud píšeš "nemohl někdo podvrhnout odpověď na trase mezi DNS serverem a klientem" tak to rozhodně neznamená nic jako "Nepsal jsem ani nic o kontrole komunikace." protože když nekontroluješ komunikaci, tak ti někdo může podvrhnout odpověď. Možná by jsi měl příště specifikovat jaký útok máš na mysli, protože když napíšeš podvrhnutí komukace tak je jich asi milión a pak jednu po druhé trvdti že tuto jsi nemyslel nemá moc cenu.
Každopádně platí IMO pořád to samé. DNSSEC nemá zabezpečovat komunikaci ani její možné podvržení, viz link [2] - má IMO ověřit že DNS záznam na DNS serveru je validní === podepsaný pomocí hierarchie a "manuálního" ověření.
-
Filip JirsákStříbrný podporovatel
Podvrhnutím odpovědi na trase mezi DNS serverem a klientem myslím to, že klient pošle dotaz „jaký je A záznam pro jméno google.com“ a dostane odpověď „A záznam pro doménu google.com je 17.142.160.59“ (což je momentálně jedna z adres pro apple.com, google.com tam rozhodně není). Nemusíte těch dalších způsobů vyjmenovávat milion, ale jeden další způsob podvržení odpovědi na trase mezi DNS serverem a klientem by mne fakt zajímal.
Pod kontrolou komunikaci si představím, že můžu ovlivnit, který paket projde a který neprojde, že můžu změnit jeho obsah. K podvržení DNS odpovědi ale úplně stačí mít informaci o paketu s dotazem a pak na dané síti vytvořit falešnou odpověď – dřív, než dorazí ta opravdová. Na to nemusíte kontrolovat komunikaci, ani dělat podvodné přesměrování nebo podobný útok na úrovni IP adres, na to stačí být třeba na stejném hubu jako zařízení, na které útočíte, a odeslat jeden UDP paket s DNS odpovědí. (NIC.CZ to útočníkům trochu komplikuje tím, že používá pro uvedené dotazy TCP. Jenže kdyby to stačilo, nebylo potřeba vymýšlet celou tu šarádu kolem DNSSEC, stačilo by říct „tak používejte TCP“.)
DNSSEC nemá zabezpečovat komunikaci ani její možné podvržení, viz link [2] - má IMO ověřit že DNS záznam na DNS serveru je validní === podepsaný pomocí hierarchie a "manuálního" ověření.
Nemohl byste se aspoň trochu zamyslet nad tím, co píšete? K čemu by vám byla informace, že někdo tvrdí, že záznam na serveru je validní, kdyby se k vám ten validní záznam nedostal? K čemu by vám byla informace, že někdo tvrdí, že je záznam na serveru validní, když byste nevěděl, jestli tu informaci cestou někdo nezměnil? Vy byste poslal dotaz „jakou adresu má google.com?“ Server by měl validní záznam, že google.com má adresu 172.217.23.206 a vám by se vrátila odpověď „google.com má adresu třeba 127.0.0.1 nebo jakoukoli jinou, kterou někdo cestou změnil – ale na serveru je ten záznam validní“. Internet je nezabezpečený komunikační kanál, takže validní informace někde na druhém konci světa je vám úplně k ničemu, pokud ji nedokážete přenést k sobě tak, abyste detekoval její případnou změnu. Což vždycky znamená (pokud budeme ignorovat kvantovou kryptografii) elektronický podpis a jeho ověření (třeba zřetězené) vůči něčemu, co znám odjinud (v případě DNS jsou to otisky klíčů kořenové zóny). -
NULL (neregistrovaný)
Nemusí to být jenom na trase, může to být třeba ovládnutím DNS serveru nebo u klienta v OS, SW na x místech y způsoby, pořád je to podvržení obsahu.
Zamyslel jsem se a je to jak už ti to bylo napsáno. IMO:
buď někdo zmanipuluje úplně všechno kolem tebe, pak už je DNSSEC tvůj nejmenší problém. V opačném případě si ověříš při dotazu podpisy skrz DNSSEC z více DNS a při případné změně záznamu znova -nebo poznáš manipulaci. Ten někdo by musel zmanipulovat hned router u tebe (nebo MITM někde na jediné cestě) hned na začátku a podvrhovat úplně všechno, i ostatní autority - tomu ale těžko zabráníš bez CA a HTTPS, resp. SSL.
A to že je někde na druhém konci internetu validní záznam je ti samozřejmě taky k něčemu, ne všechny vektory útoků jsou totiž MITM a unášení komunikace - DNSSEC ti potvrdí, že ti odpovídá DNS server s podpisy a ne nějaká vějička . .
A jak jsem ti psal už na začátku a z funkce DNSSECu je to zřejmé, DNSSEC umožňuje několikacestné ověření pomocí podpisů a v linku [1] je to jasně napsáno: Nezaručuje transport, jenom posílá informace které se dají použít k ověření. Dále je tam psáno že to má podmínky i u klienta. Prostě DNSSEC není final victory weapon, ale odstraňuje další slabiny a do budoucna určitě přispěje k dalšímu většímu zabezpečení.
A jak už ti píšu po několikáté, bezpečný transport je věcí SSL, TLS, případně HTTPS apod.
IMO očekáváš od DNSSECu něco co nezaručuje a vymýšlíš způsob jak to nezaručuje. Proč? -
Není to jen TCP a notifikační email. Jsou tam další dvě věci - ochranná lhůta a pravidelná kontrola nameserverů. Tedy jsou pro omezení rizika implementovány minimálně 4 metody, z nichž alespoň dvě jsou doporučeny v příslušných RFC. Útočníka, který má pod kontrolou týden všechny nameservery dané domény, včetně emailových schránek jejích správců, si sice umím představit, ale zavedení DNSSEC na takovéto doméně je asi nejmenší problém.
-
Filip JirsákStříbrný podporovatel
zavedení DNSSEC na takovéto doméně je asi nejmenší problém.
To je pořád dokola. Tohle je pohled držitele domény, který řeší, jestli jeho doména bude zabezpečená nebo nezabezpečená. Já se na to dívám z pohledu DNS klienta. Dříve mi podepsaná DNS odpověď říkala: Pokud neselhal registrátor nebo registr a pokud vlastník nemá hacknutý DNS server nebo účet u registrátora, je tato DNS odpověď validní a nikdo s ní cestou nemanipuloval. Teď mi ta podepsaná odpověď říká: pokud nikdo nemohl manipulovat s DNS odpověďmi, je odpověď validní. Což je ovšem to samé, co se dozvím i bez DNSSEC. -
NULL (neregistrovaný)
Mno ... IMO mohli, ale byla to spíš feature než nějaký obvyklý standart. A až se posadí takový standart, tak na to začnou reagovat i OS.
To je pak otázka, jak něco nasadit do provozu, když to ještě nikdo nepoužívá protože to není nasazené a protože to nikdo nepoužívá, tak to nemá smysl nasazovat?
Myslím že s takovým přístupem by nebyla ani ta pověstná slepice ani to vejce. -
Petr M (neregistrovaný)
Já se na to dívám tak, že DNSSEC je jistota, že <b>po zaregistování keysetu</b> nikdo nepřesměroval spojení jinam. Nikdy nebyla jistota, že někdo, kdo teoreticky měl možnost, zaregistroval svůj keyset dřív, než majitel.
Teď je otázka, co se stane, když se z toho mailu majitel nezabezpečené domény dozví, že mu někdo přihodil nějaký keyset... Řekl bych, že si uvědomí, že o jeho doménu se někdo "zajímá" a pro sychr si ji zabezpečí sám.
-
Filip JirsákStříbrný podporovatel
Nikdy si keyset k doméně nemohl zaregistrovat nikdo jiný, než majitel (nebo někdo jím pověřený).
Samozřejmě může udělat chybu registr nebo registrátor, mohou majiteli uniknout autentizační údaje pro správu domény. To je ale obecný problém registrace DNS, tímhle způsobem by bylo možné i změnit vlastníka domény. Zkrátka v případě domén se musíme spolehnout na to, že registr, registrátor i vlastník domény postupují správně. Jenže teď může nastat případ, že registrátor ani vlastník domény neudělají nic špatně, přesto se do registru dostane záznam, který tam být nemá. A navíc je to záznam týkající s DNSSEC.
E-mail majiteli vůbec nemusí přijít, nemusí se dostat ke správné osobě. A i když se dostane do správných rukou a dotyčný bude vědět, co to znamená, má jen dvě možnosti – zprovoznit DNSSEC nebo zablokovat veškeré operace s doménou. To první nemusí být snadné – asi to má nějaký důvod, proč DNSSEC ještě nemá. To druhé má jiné vedlejší efekty.
-
Filip JirsákStříbrný podporovatel
Nikoli. Případy, kdy je doména podepsaná, ale informace o tom není v registru, tahle změna sama od sebe neřeší – je potřeba přidat
CDSneboCDNSKEYzáznam. Navíc pokud je doména podepsaná, ale není o tom záznam v registru, asi to má nějaký důvod – třeba se v dané doméně podepisování teprve testuje. V případech, kdy je doména podepsaná ale není v registru, tyhle změny pomohou snad v jediném případě – kdy registrátor dané domény nepodporuje přidání keysetu do registru. Na takové registrátory by ale měl CZ.NIC vyvíjet tlak jakožto provozovatel registru, ne je obcházet…Jinak RFC7344 jako standardní způsob, jak dostat záznamy o DNSSEC do registru, je užitečná věc – třeba jako ten v článku uvedený příklad, kdy Cloudflare nemusí vědět nic o CZ.NIC, ale dokáže tam publikovat příslušné záznamy. To je fajn, ale mělo by to být bezpečné.
Pokud někdo podepíše doménu, tak snad k ní má přístup, ne?
Tohle už právě neplatí. Tu doménu může nově podepsat kdokoli, kdo na sebe dokáže přesměrovat dotazy CZ.NICu naCDNSKEYzáznamy. Takže například ISP, u kterého je hostovaný DNS server příslušné domény.Nebo se to dá říct ještě jinak. DNSSEC má bránit určitým typům útoků. Jenže CZ.NIC se teď rozhodl, že ta obrana DNSSEC je vlastně zbytečně silná, a že úplně stačí dotazovat se pomocí TCP spojení, poslat notifikační e-mail a dát sedmidenní ochrannou lhůtu. Takže když jsem klient a ptám se na nějaké nedůležité DNS názvy, asi vlastně vůbec nepotřebuju DNSSEC a stačí, když se budu dotazovat přes TCP…
-
> Takže když jsem klient a ptám se na nějaké nedůležité DNS názvy, asi vlastně vůbec nepotřebuju DNSSEC a stačí, když se budu dotazovat přes TCP...
To je pořád ta samá písnička... Plácáte nesmysly a ještě si v tom hovíte.
Musíte použít TCP, musíte poslat email správcům DNS serverů, musíte se dotazovat sedm dní v týdnu několikrát denně, dotazovat se všech DNS serverů a všech jejich IP adres, nikdy vám přitom nesmí přijít jiná odpověď... Opravdu tohle radíte dělat jako ekvivalent k DNSSEC??? Místo jednoho dotazu jich dělat desítky a čekat na každou odpověď týden? :)))
-
Filip JirsákStříbrný podporovatel
Jak už jsem psal, notifikační e-mail, který vůbec nemusí adresátovi dorazit, nepovažuju za dostatečnou ochranu – zvlášť když je velice pravděpodobné, že půjde na stejnou doménu nebo stejný server, který se tím má „ověřit“. Dotazování se všech DNS serverů a všech IP adres také není žádná obrana, protože všechny DNS servery berou obvykle záznamy z jednoho zdroje. Stejně tak nepovažuju za dostatečnou ochranu tu lhůtu sedmi dnů – ta ochrání před případem, kdy by někdo získal neoprávněný přístup náhodou, ale nebrání před útočníkem, který ten přístup chce získat.
Ale to všechno už jsem psal. Takže nesmysly tu plácáte vy, protože moje námitky jste nijak nevyvrátil a jenom opakujete velmi zavádějící tvrzení. Nebo snad chcete tvrdit, že doručení e-mailu je 100% spolehlivé? Že když správce DNS serveru, který nemá nasazené DNSSEC, dostane e-mail DNSSEC … CDNSKEY … RFC7344 …RFC8078 … považujeme přítomnost těchto záznamů za žádost o zveřejnění těchto klíčů v zóně .cz, tak hned bude vědět, o co jde? Nemluvě o tom, že ten e-mail může dostat vlastník domény, který z toho nepochopí ani to, že se to týká DNS. Chcete snad tvrdit, že většina provozovatelů DNS serverů používá djbdns a zónové soubory synchronizují přes rsync, takže nemají žádný master server, jehož ovládnutí stačí k manipulaci se zónou na všech podřízených serverech?
Představte si, že má někdo třeba VPS, na něm master DNS server, web server a poštovní server, má na tom hostovanou svou doménu. Slave DNS servery má někde jinde. Připadá vám to jako neobvyklá konfigurace? Před tím VPS musí být nějaký router. Na tom routeru někdo (třeba jeho správce) nastaví přesměrování portů 25 a 53 na svůj server. E-maily bude přeposílat dál, jenom notifikační e-mail od CZ.NIC hodí do koše. Z původního DNS serveru si zkopíruje zónu, vytvoří její novou verzi, do které přidá CDNSKEY záznam a pošle notifikaci slave serverům, že si mají udělat update.
Jak budou v takovém okamžiku fungovat ty pojistky kolem CDNSKEY záznamu? Zabrání útočníkovi v úspěšném provedení útoku? Všimněte si, že útočníkovi stačilo, že ovládá jedno jediné zařízení – a je to zařízení, které nemá ve své moci vlastník domény.
-
kolemjdoucí (neregistrovaný)
Těžko se představuje, že si zaplatím někde v neznámu něco virtuálního a svěřím tomu své master DNS.
Nevím jak vy, ale já mám DNS pod vlastní kontrolou na vlastním stroji a sekundární servery si synchronizují záznamy přes VPN.
Pokud máte kontrolu nad provozem k serveru někoho, koho chcete poškodit (zmiňoval jste kamaráda) tak je mnohem snazší poslat žádost na změnu DNS-SETu a nasadit vlastní DNS servery a poté nebo místo toho provést převod domény a autorizaci provést na tom odchyceném emailu, jak jste již zmiňoval. Doménu provozovat ještě rok, provést její prodloužení a pak ji nabídnout původnímu vlastníku za tučný poplatek.Zamyslete se hluboce a pak nám všem, kteří s vámi názor nesdílíme, napište, co by měl útočník z toho, že by zabezpečil cizí DNS záznam přes svůj keyset a musel by stále přesměrovávat provoz.
Je to časově náročné (rozuměj drahé) a užitek (rozuměj zisk) je 0 0 prd.Pavel P.
-
Filip JirsákStříbrný podporovatel
Nevím jak vy, ale já mám DNS pod vlastní kontrolou na vlastním stroji
A máte k nim i vlastní linku až do NIC.CZ? Celou dobu se tu bavíme o DNSSEC, a DNSSEC je ochrana síťové komunikace. Takže psát o zabezpečení DNS serveru je sice hezké, ale v této debatě je to irelevantní. Než budete zase ostatním doporučovat, že se mají hluboce zamyslet, radši si ujasněte, která technologie k čemu slouží.nasadit vlastní DNS servery
Správné privátní klíče pro podpis domény pomocí DNSSEC získáte jak? Víte, přesměrovat komunikaci, to umí každý router po cestě. Ale získat privátní klíče k doména, to už je jiná liga. Proto bylo vynalezeno DNSSEC.co by měl útočník z toho, že by zabezpečil cizí DNS záznam přes svůj keyset a musel by stále přesměrovávat provoz.
Pokud si myslíte, že únos vaší domény nehrozí, nepotřebujete DNSSEC. DNSSEC ale vzniklo pro to, že se toho někteří obávají. Ono je totiž třeba pro útočníka obtížné, pokud nekontroluje nějaký prvek na trase, přesměrovat vaši komunikaci s webovým serverem na svůj server. No ale pokud dokáže vašemu prohlížeči poslat svou vlastní odpověď pro požadavek na překlad zaslaný vaším prohlížečem, nemusí nic takového řešit, protože váš prohlížeč se sám připojí na jeho server. Možná byste chtěl argumentovat, že v takovém případě to ale pořád ještě zachrání HTTPS. Jenže k vystavení DV certifikátu už dnes stačí ovládat DNS, a v budoucnosti se snad dočkáme toho, že bude stačit DANE záznam.Takže pokud útočník nechce spoléhat na to, že oběť doménu vůbec neřeší a svoje přihlašovací údaje k internetovému bankovnictví klidně svěří ruské doméně, je podvržení DNS odpovědi jeden z reálných vektorů útoku. A v některých případech, kdy je něco závislé jen na DNS, bývá požadováno ověření domény přes DNSSEC. Třeba se s tím počítá pro DANE, nedivil bych se, kdyby to v budoucnosti vyžadovaly certifikační autority pro automatické ověření, že jste vlastník domény.
-
kolemjdoucí (neregistrovaný)
Základem bezpečné komunikace jsou bezpečné koncové body komunikace, takže to opravdu není irelevantní mít zabezpečený DNS server. Bez uzardění argumentujete tím, že stačí kontrolovat jeden router k master serveru a slave serverům podvrhnete data pro přenos, což při se vám při dobrém nastavení nepodaří.
To hluboké zamyšlení, na které se odkazujete, mělo vám posloužit na to, abyste se vyjádřil, jaký zisk bude mít neustálé udržování přesměrování dotazů a podpis zóny někoho jiného. Zkuste si své odpovědi na mé dotazy přečíst ještě jednou a (možná) zjistíte, že odpovídáte úplně na něco jiného, než na co jsem se ptal.
Jako první vám psal p. Surý, kterého si nesmírně vážím, že mnohem snazší než se snažit po týden přesměrovávat provoz je přeregistrace domény na jiného vlastníka.
Já vám napsal, že druhé snazší řešení je jednorázová změna DNSSETu autorizovaná jednou odchyceným emailem, než se snažit týden přesměrovávat veškerou komunikaci na všechny DNS servery.Mějte hezký den.
-
Filip JirsákStříbrný podporovatel
Základem bezpečné komunikace jsou bezpečné koncové body komunikace, takže to opravdu není irelevantní mít zabezpečený DNS server.
Chtělo by to pečlivěji číst. Nikdo nepsal, že je irelevantní mít zabezpečený DNS server. Psal jsme, že je to irelevantní v diskusi o zabezpečení komunikace (což je přesně to, co dělá DNSSEC).Bez uzardění argumentujete tím, že stačí kontrolovat jeden router k master serveru a slave serverům podvrhnete data pro přenos, což při se vám při dobrém nastavení nepodaří.
Při dobrém nastavení už má doména dávno DNSSEC, takže je zbytečné řešit zavedení DNSSEC z nezabezpečené domény. Tady ale řešíme domény, které DNSSEC ještě nemají – a těch, kdo by byl přenos zónových souborů nějak zajištěn, bude minimum. Ukažte mi nějakého provozovatele DNS serverů pro zákazníky (tj. registrátoři, webhosteři DNS hosteři), který umožňuje přenos zónových souborů přes VPN.To hluboké zamyšlení, na které se odkazujete, mělo vám posloužit na to, abyste se vyjádřil, jaký zisk bude mít neustálé udržování přesměrování dotazů a podpis zóny někoho jiného. Zkuste si své odpovědi na mé dotazy přečíst ještě jednou a (možná) zjistíte, že odpovídáte úplně na něco jiného, než na co jsem se ptal.
Pochopil jsem vás tak, že se ptáte, k čemu by bylo dobré unést doménu a pak jí ještě podepsat. Na obojí jsem vám odpověděl.Jako první vám psal p. Surý, kterého si nesmírně vážím, že mnohem snazší než se snažit po týden přesměrovávat provoz je přeregistrace domény na jiného vlastníka.
Ano, jak je to z pohledu vlastníka domény jsem se dozvěděl mnohokrát. Nedozvěděl jsem se, jak je to z pohledu klienta DSSEC – jak teď mohu důvěřovat např. certifikátu získaného přes DANE a ověřeného přes DNSSEC.Já vám napsal, že druhé snazší řešení je jednorázová změna DNSSETu autorizovaná jednou odchyceným emailem, než se snažit týden přesměrovávat veškerou komunikaci na všechny DNS servery.
Ovšem nějak jste zapomněl uvést, jak způsobíte to vytvoření žádosti o změnu DNSSETu. Ten e-mail slouží až k potvrzení změny, kterou ale musíte nějak iniciovat. -
kolemjdoucí (neregistrovaný)
Nebudu slovíčkařit, ale já nebyl ten, který psal o virutalizovaném DNS server u na pochybném hostingu.
Většina DNS hostingů podporuje nebo dokonce vyžaduje TSIG. Tím, že mám své servery pod vlastní kontrolou tak mohu použít VPN. O obojím jsem psal 23. 6. 2017 ve 22:38.
Ptal jsem se k čemu mi bude vynaložit tak velké náklady abych týden přesměrovával provoz všech autoritativních serverů DNS, když mohu celou doménu unést (změna vlastníka, změna dns serverů) s podstatně nižšími náklady.
Celé zabezpečení (i https a jiné) je jen o tom, komu se rozhodnete důvěřovat a komu ne.
DNSSEC má u nás spoustu domén, u kterých o nich vlastník nemá vůbec tušení, že něco takového mají. Udělal to za ně správce a mají i jejich keyset.
Domén s vlastním keysecem odhaduji na max 10% a to z grafu https://www.root.cz/clanky/vice-nez-polovina-domen-v-cz-je-zabezpecena-dnssec/ protože za velké skoky mohou registrátoři.Odeslat požadavek je jednoduché, stačí zavolat (např. u vás k Web4U) a říci, že chcete změnit NSS pro doménu a autorizaci mají poslat na váš email. Pokud uvedete do telefonu dostatečný důvod a řadu dalších informací, které lze ale získat i bezplatně, tak většinou uspějete. Nejslabším článkem bude vždycky člověk.
mimochodem byste měl opravit alespoň tento nedostatek na vaší doméně
Primary Name Server Not Listed At Parent
a přidat podporu šifrování na poštovním serveru, protože pak není potřeba přesměrovat email, ale pro potvrzení ho stačí jen odchytit...
barbucha.*******.org Does not support TLSPS: Váš příspěvek z 23. 6. 2017 10:27 je technicky velmi zajímavý a líbí se mi takováto varianta, teď jde jen o to, kdy se něco takového uvede do praxe.
-
Filip JirsákStříbrný podporovatel
Ptal jsem se k čemu mi bude vynaložit tak velké náklady abych týden přesměrovával provoz všech autoritativních serverů DNS, když mohu celou doménu unést (změna vlastníka, změna dns serverů) s podstatně nižšími náklady.
Náklady na přesměrování provozu jednoho master serveru je jedno DNAT pravidlo na routeru. To mi nepřipadá nijak závratné. A nedovedu si představit ten způsob provedení změny vlastníka nebo změnu DNS serverů, která by byla ještě jednodušší.To, že selže registrátor, se snad neděje každý den. Navíc tady se bavíme o DNSSEC, které není imunní vůči selhání registrátora. Vůči napadení síťové komunikace by DNSSEC imunní být mělo, protože to je jediný jeho smysl.
Celé zabezpečení (i https a jiné) je jen o tom, komu se rozhodnete důvěřovat a komu ne.
Ano, to je klíčové. A celé zabezpečení DNSSEC má jen jediný smysl – aby bylo možné (ohledně DNS) ze seznamu těch, kterým musíme důvěřovat, vyškrtnout ISP. Akorát teď se to změnilo, že nejdřív zavřeme oči, chvíli budeme ISP důvěřovat, ale když máme otisky klíčů v nadřazené doméně, vzpomeneme si, že jsou ISP vlastně hrozně nedůvěryhodní, a začneme používat DNSSEC.mimochodem byste měl opravit alespoň tento nedostatek na vaší doméně
Primary Name Server Not Listed At Parent
V nadřazené doméně mám tolik záznamů, kolik mi jich Web4U dovolí zadat. Mám v plánu převést domény k jinému poskytovateli, který podporuje DNSSEC i u jiných TLD než .cz, tak uvidíme, co pak bude možné. Nechávat tam jenom jeden pool serverů se mi nechce.a přidat podporu šifrování na poštovním serveru, protože pak není potřeba přesměrovat email, ale pro potvrzení ho stačí jen odchytit...
barbucha.*******.org Does not support TLS
Certifikát poštovního serveru bude v TLSA záznamu chráněný DNSSEC, a jsme přesně tam, o čem celou dobu píšu. A jinak jsem nikdy neměl dost odvahy uvádět u domény jako e-mail vlastníka e-mail z dané domény, takže v mém případě by bylo potřeba ten e-mail přesměrovat nebo přečíst trochu někde jinde… -
kolemjdoucí (neregistrovaný)
Jste stále zahleděn jen na ten jeden DNS vašeho kamaráda, kterému kontrolujete linku, odpoutejte se už od toho...
K tomu poštovnímu serveru: když si hostujete stejným serverem všechny své domény, tak je to úplně jedno, jestli jako kontakt necháte email na stejné doméně (.cz) nebo uvedete další (.org), odchyt se provede na stejné lince proti stejné adrese.
Doménový hosting, který má 4 z 5 DNS serverů ve stejném AS je na stejné úrovni jako hosting se dvěma DNS servery v různých AS.Pokud chcete udělat něco pro zlepšení vašich DNS záznamů, tak zkuste použít nějaký test spolehlivosti. Celkem slušný je např. https://mxtoolbox.com/domain/
Ještě Vám poskytnu další informace k věcem, co tento test nezobrazuje:
použijte NSEC3 místo NSEC, jinak lze postupnými DNS dotazy zjistit veškeré záznamy ve vaší doméně
pro stroje zabezpečené certifikáty z let's encrypt raději použijte doménu, která má DNSSEC, ale ona vlastně není vaše...Mějte hezký den.
-
Filip JirsákStříbrný podporovatel
Jste stále zahleděn jen na ten jeden DNS vašeho kamaráda, kterému kontrolujete linku, odpoutejte se už od toho...
Řešíme tu bezpečnost. Nějaké řešení není bezpečné tehdy, když existuje jeden případ, kdy je to bezpečné – je bezpečné jedině tehdy, když neexistuje žádný případ, kdy to bezpečné není. Navíc vůbec nejde jen o takovýhle případ. Každý DNS server je umístěn v síti nějakého ISP. A opravdu nevidím žádný důvod, proč by ten ISP měl mít možnost podepsat mou doménu. Vždyť přesně proti tomu má DNSSEC chránit…K tomu poštovnímu serveru: když si hostujete stejným serverem všechny své domény, tak je to úplně jedno, jestli jako kontakt necháte email na stejné doméně (.cz) nebo uvedete další (.org), odchyt se provede na stejné lince proti stejné adrese.
Jenže kontakt k té mé doméně je na doméně gmail.com.Doménový hosting, který má 4 z 5 DNS serverů ve stejném AS je na stejné úrovni jako hosting se dvěma DNS servery v různých AS.
Ale doménový hosting, který má 4 z 5 IP adres anycastové IP adresy se servery na všech kontinentech, je na tom lépe.Pokud chcete udělat něco pro zlepšení vašich DNS záznamů, tak zkuste použít nějaký test spolehlivosti. Celkem slušný je např. https://mxtoolbox.com/domain/
Pod spolehlivostí si představuju spíš to, jak časté jsou výpadky. Tohle je test konfigurace DNS. A jako u každého testu je také potřeba správně interpretovat výsledky, protože co je někde chyba může být jinde nepodstatný detail nebo dokonce záměr. -
kolemjdoucí (neregistrovaný)
už nehodlám déle debatovat, na jednu stranu vám vadí že jeden ISP je schopen vám podvrhnout doménu a na druhou stranu vám nevadí, že je schopen si číst a případně i odesílat vaši kompletní emailovou korespondenci.
Většina uživatelů používá rekurzivní servery svých ISP a ten jim může servírovat kde co.K poštovnímu serveru polopatisticky:
kontakt u cz domény vede na doménu org a MX záznam cz domény i org domény vede na stejný poštovní server => je zbytečné mít u cz domény kontakt z domény org, protože email přijde na to samé místo.teoreticky ano, ale prakticky má google taky anycast a když mu vypadly servery v Evropě, tak si půlka Evropy ani nevrzla. Je hezké, že DNS je hostované po celém světě ale pak jde také o stroje, které služby té domény web, mail atd) provozují a o jejich dostupnost.
zkuste někdy místo chytání se slovíčka číst mezi řádky "pro zlepšení vašich DNS záznamů",
např nahradit zastaralý SPF záznam TXT záznamem, doplnit DMARC i když nemáte DKIM, odstranit rozpor mezi údaji v nadřazené a vaší zóně, zprovoznit TLS na SMTPjá v tom spíš jak záměr vidím to, že jste jen něco nedotáhl nebo nevěděl, snad krom toho, že nemůžete u vašeho správce domény vložit do setu více DNS serverů, ale i tak je to chyba
berte tu diskusi pozitivně - uděláte něco pro své obohacení a nesnažte se za každou cenu obhajovatMějte hezký den
-
Filip JirsákStříbrný podporovatel
na jednu stranu vám vadí že jeden ISP je schopen vám podvrhnout doménu a na druhou stranu vám nevadí, že je schopen si číst a případně i odesílat vaši kompletní emailovou korespondenci.
Ano, považuju doménu za důležitější než e-mail. Mimo jiné je e-mail na doméně závislý, takže nemůže být doméně méně důležitá.Většina uživatelů používá rekurzivní servery svých ISP a ten jim může servírovat kde co.
Ano, zatímco ISP koncového uživatele je zlý a může manipulovat s DNS, ISP u kterého je hostován DNS server je hodný a klidně mu svěříte svou doménu. Často to přitom může být jeden a ten samý ISP…kontakt u cz domény
Akorát že moje doména není cz…teoreticky ano, ale prakticky má google taky anycast a když mu vypadly servery v Evropě, tak si půlka Evropy ani nevrzla.
Nikoli teoreticky, ale prakticky. To, že není něco bezpečné na 100 %, neznamená, že není lepší mít něco zabezpečené na 90 % místo na 40 %. Ostatně na 100 % není bezpečné nic.Mimochodem, ten problém Googlu byl dost jiný. Netýkalo se to Evropy, ale jen ČR (a SR, odkud Google směřuje provoz do ČR), a problém nebyl ve výpadku serveru, problém byl s routováním. Občas se takovýhle výpadek někomu přihodí, ale dochází k nim podstatně méně často, než k výpadkům jednotlivých serverů nebo o k výpadkům datacenter.
pak jde také o stroje, které služby té domény web, mail atd) provozují a o jejich dostupnost
Akorát že to se vůbec netýká DNS.zkuste někdy místo chytání se slovíčka číst mezi řádky "pro zlepšení vašich DNS záznamů"
Vy si zase zkuste odpustit poučování, které je mimo téma a o které nikdo nestojí. Nevíte nic o tom, proč to tak je, opakujete dokonce výtky, které už jsem vám vysvětlil. Úpravy si s dovolením budu dělat podle toho, jak to mám v plánu, a ne podle toho, co si myslí nějaký anonym v diskusi. Například proto, že nepodstatné věci řeším najednou až se toho nahromadí víc. -
kolemjdoucí (neregistrovaný)
rychle zapomínáte, přečtěte si co jsem o DNS psal, proč různé AS atd, tak mi nevnucujte, že musím mít pro všechny DNS jednoho ISP. Jako klient si (pokud není víc linek k dispozici) nevyberu, kdo mě připojí, ale kam si dám servery už si vybrat můžu.
Doménové jméno jirsak.cz
Registrace od 14.10.2003
Poslední aktualizace 04.04.2015
Datum expirace 14.10.2017
Držitel SB:INETCZ-Q0YQ29-43980 Jakub Jirsák
Administrativní kontakt
FILIP-JIRSAK Filip Jirsák
Určený registrátor REG-WEB4U Web4U s.r.o. od 17. září 2006 13:35
Zabezpečeno pomocí DNSSEC Ano
StavKontakt u CZ domény, není váš? Psal jsem něco jiného?
Ohledně Google zase slovíčkaření, měl jsem speciálně kvůli vám napsat výpadek služeb Google. Zmíněn byl kvůli vychvalovanému AnyCastu.
K čemu mi bude doména, když na ní nebudu nic provozovat?
Dostupnost služeb domény (web, mail) na DNS přímo závisí, takže se to DNS týká.
K čemu mi bude, že všichni budou vědět, na který server mi mají poslat mejl, nebo na kterém si mají zobrazit můj web, když ani jedno nepojede?Vaše problémy nejsou moje, a nesnažte se mě osočit mě, že vás poučuji.
Je smutné, že tady kalíte vodu a teoretizujete o DNSSEC, ale vlastní (tedy ve vašem vlastnictví) doména zabezpečena DNSSEC není.
To, že cz doména není vaše, jsem tu už psal dnes ráno, ale jste tam jako Administrativní kontakt a podle názvu keysetu jste zjevně zaváděl i DNSSEC. -
Tak ještě jednou od někoho jiného. Zjevně neumíte číst to co napíše Jirsák.
Není to o tom jak si to vyřeší Jirsák, nebo jak si to vyřeší kolemjdoucí. Jde o to, že existuje spousta domén, které jsou z různých důvodů pod jedním ISP (nebo tam mají alespoň všechny DNS mastery). Pro mne jako uživatele bylo do teď DNSSEC potvrzení, že DNS odpověď (pro L2 doménu) pochází od někoho kdo je oprávněný manipulovat se záznam v registru. Tímto o tuto důvěru přicházím, protože nemám jako uživatel šanci poznat, která doména získala DNSSEC delegaci správným způsobem, a která tímhle bootstrapem.Tím se dostáváme přesně na úroveň současné implementace PKI, kdy jako uživatel o doméně nevím, jestli smí být podepsaná WoSignem, Symentecem, StartSSL, nebo jinou agenturou, a tak nějak tuším, že se co půl roku najde způsob jak z některé agentury vylákat certifikát bez toho abych L2 doménu vlastnil. (Často použití takového certifikátu nemá dlouhého trvání, ale na cílený útok to bohatě stačí. To je přesně to, na co nadává většina kritiků PKI.
Pokud máme PKI nahradit něčím principielně lepším, tak ten princip nesmíme hned na začátku porušit. -
kolemjdoucí (neregistrovaný)
Ale vždyť je odpověď v článku:
Po uplynutí sedmi dnů CZ.NIC zaregistruje nový keyset ve tvaru AUTO-<náhodný řetězec>, přiřadí jej k doméně a informuje e-mailem držitele domény a prostřednictvím zprávy EPP protokolu také registrátora domény.
Do procesu registrace je zařazen registrátor (technicky zdatnější organizace), držitel i správce nss.
Jak běžný koncový uživatel ve svém tabletu / mobilu / počítači pozná, že brouzdá po serveru, jehož DNS je zabezpečena přes DNSSEC nebo jej vůbec nemá? Nijak, nezajímá ho to.
Erudovaný si může doinstalovat plugin od CZ.NIC
Pokud čas ukáže, že je autoregistrace špatnou cestou, tak jsou tyto domény dohledatelné a je možné z nich zase DNSSEC odebrat. -
Filip JirsákStříbrný podporovatel
Vaše odpověď je úplně mimo – bavíme se o zavádění DNSSEC, takže nedává smysl argumentovat uživateli, které DNSSEC vůbec nezajímá. Pokud vidíte jenom tyhle uživatele, běžte si domluvit s CZ.NICem, proč vůbec nějaké DNSSEC podporuje.
Běžný koncový uživatel je například také certifikační autorita, která ověřuje oprávnění pro vydání DV certifikátu. Taková autorita může pro DNSSEC domény použít jednoduchý DNS dotaz s ověřením DNSSEC, zatímco pro domény bez DNSSEC bude mít komplikovanější postup, kterým se bude snažit předejít podvržení DNS odpovědi.
Dohledatelná bude možná ta první autoregistrace, ale určitě nedohledáte, co vše se na na jejím základě událo později.
-
> pokud je doména podepsaná, ale není o tom záznam v registru, asi to má nějaký důvod – třeba se v dané doméně podepisování teprve testuje
Pokud v rámci testu vloží CDNSKEY záznamy (jinými slovy požádá nadřazenou zónu o vložení těch klíčů) tak je asi v pořádku, že je výsledkem testu úspěšné reflektování těchto záznamů v nadřazené zóně. Nakonec, k tomu ty záznamy slouží. Pokud chce něco testovat a zároveň nechce, aby to fungovalo, může si hrát na intranetu.
-
Filip JirsákStříbrný podporovatel
pokud je doména podepsaná
Pokud v rámci testu vloží CDNSKEY záznamy
Podepsaná doména je něco jiného, než doména s CDSKEY záznamy. Opravdu je potřeba tohle vysvětlovat?Nepovažuju za pravděpodobné, že by většina těch podepsaných zón, které nemají klíč v nadřazené doméně, v dohledné době použila CDNSKEY záznam. Nemyslím si, že by to byly zóny, kde někdo chce zprovoznit DNSSEC, a čeká jenom na to, až mu to registrátor umožní. Pokud by opravdu chtěl DNSSEC zavést, může přejít k jinému registrátorovi. A pokud na to naopak nespěchá a přecházet nechce, nebude preventivně podpisovat zóny několik let předem. Myslím si, že ty podepsané zóny bez publikovaného klíče jsou dvojího typu – buď jsou podepsané „omylem“, protože to někdo někde zapnul, ale provozovatel o DNSSEC neví nebo to nechce řešit, takže klíč do nadřazené domény nedal – a nevystaví ani CDSKEY záznam. Další skupina budou ty zóny, kde se DNSSEC testuje, a kde by si zařazení klíče do nadřízené zóny po dokončení testování zařídili stejně, i kdyby museli někde kliknout na nějaké tlačítko. Pak už zbývají zóny jako Cloudflare, kde opravdu půjde zavést DNSSEC i tehdy, když to majitel domény nijak neřeší. Jenže v tomhle případě se dal bootstrap udělat bezpečně přes DNSSEC zabezpečenou doménu poskytovatele DNS služeb – jmenné servery té domény, která má být zabezpečena, jsou
*.ns.cloudflare.com, takže by bylo možné CDNSKEY záznam ověřovat i na nich. -
Ondřej CaletkaZlatý podporovatel
Jenže v tomhle případě se dal bootstrap udělat bezpečně přes DNSSEC zabezpečenou doménu poskytovatele DNS služeb – jmenné servery té domény, která má být zabezpečena, jsou *.ns.cloudflare.com, takže by bylo možné CDNSKEY záznam ověřovat i na nich.
Můžete to trochu rozvést? Jak se dá zabezpečeně ověřit
CDNSKEYzáznam v nepodepsané zóněněkde.cz, která je hostovaná na DNS serverech v podepsané zóněcloudflare.com? -
Filip JirsákStříbrný podporovatel
V registru je uvedeno, že
někde.czmá jmenné serveryfiona.ns.cloudflare.comarudy.ns.cloudflare.com. První dotaz by byl naCDNSKEYzáznam v doméněněkde.cz. Pokud by byl podepsaný DNSSEC a validní, není potřeba nic dál řešit. Pokud by podepsaný nebyl, pokračovalo by se dotazem třeba naTXTzáznamyněkde.cz._cdnskey.fiona.ns.cloudflare.comaněkde.cz._cdnskey.rudy.ns.cloudflare.com, ve kterých by musel být ten samý otisk, jako v původnímCDNSKEYzáznamu proněkde.cz. Bylo by to řešení přesně pro tyhle případy, kdy je doména hostovaná u nějakého poskytovatele DNS služeb, který DNS záznamy spravuje hromadně.Když se používají keysety a dá se předpokládat, že bude poskytovatel DNS služeb používat jeden nebo několik málo keysetů, dalo by se to i zjednodušit tak, že by třeba pod
TXTzáznamy_cdnskey.fiona.ns.cloudflare.com_cdnskey.rudy.ns.cloudflare.combyl seznam otisků všech validních keysetů, které používají zóny vedené na těch serverech (tj. pokud by se keyset našel na tomhle seznamu, byl by považován za ověřený. Pokud by se tam keyset nenašel, protože vlastník domény např. používá svůj keyset, musel by ho ověřit jiným způsobem.) -
Ondřej CaletkaZlatý podporovatel
To je zajímavý nápad, tak by to skutečně mohlo fungovat. Ale nikde jsem zatím o návrhu takového způsobu ověření nečetl, takže by asi bylo lepší ho místo v komentáři zde napsat do příslušné pracovní skupiny v IETF ;)
-
Filip JirsákStříbrný podporovatel
Kdybychom se o tom tady celou dobu nedohadovali, tak by mne nic takového nenapadlo ;-)
-
j (neregistrovaný)
Se bavim, doslova kralovsky ... a v tomhle pripade s Jirsakem souhlasim.
Takze neschopnej (pripadne vsehoschopnej) NIC, misto aby jednoduse naridil registratorum povine umoznit v ramci poplatku za domenu i vlozit klice (idealne vcetne nejakyho API), tak vymejsli cypovinu na tema "si ty klice, odnekud, a vibuhkoho, postahujem" ...
BTW: Tech registratoru ktery to bud neumej vubec nebo za to chteji prachy a delaj to rucne ... neni zrovna malo.
ČLÁNKY DO MAILU