Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Zrovna v práci rozcházím DNSSEC na našich doménách, takže si s tím hraju a snad jsem to dostatečně pochopil, jak to všechno funguje.
Takže jak oveřit cz doménu, případně nic.cz, na způsob
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
chtěl bych si prostě do souboru stáhnout ten klíč a dig nejake-podepsana-domena.cz -k soubor_s_klicem.txt a napsalo by to: "jo, sedí to draku, seš borec."
Takže jdem na to. Stáhnout klíč k zóně cz. Já jsem našel tohle
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
trusted-keys {
"cz." 257 3 5
"AwEAAdo9fGLzCyxz1yTlsHCT7JpHrg0q/yOlvDNg39n/gAUzg6H/5X9p
jW6mpecJuZirIcPcRw5E7E8uR8g2ztH4uztoc/7ss01s3rTnEgXfilbd
psEdXEuxIfhq+w6zL6PvCcE3qRSzsrc2//x/SXjWp8yeT4YY3W3kvB4Z
g5ld0a8bAHBYo4ZY9x7a3qnqOhqunXSG8EfRPD9koUMgWCjdnFNR89L1
5Bkzh+q1J7phTHIY5akKf3YnIB/5BnKmGBC7DimK4uSBLiBA3DLxHnvL
ffMT5XtKKHuQ/uZ4IxHWqR2cpHz/6e2WaQvOVILwd0gk9lTCildBGjC7
eNxOMnitkuM=" ;
};
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAklLqIYACgkQ9OZqfMIN8nMsAACfakQ/hGFxBV40Q3s4a319GllJ
vjYAoIkObXhITrjxEgLWm06o7prNzKkG
=6ixI
-----END PGP SIGNATURE-----
Teď paranoici ověří ještě PGP (to samozřejmě po stažení ze serveru ověří ještě telefonicky nebo jinou bezpečnou cestou) - já jsem jenom stáhnul z PGP serveru, chtěl jsem to jenom otestovat, takže nepotřebuju HIGH-SECURITY.
Důležité pro BIND je ta část trusted-keys, ta se prdne do configu bindu (ale o tom napíšu případně v jiným blogu, pokud bude u mě čas a od vás zájem). Pro dig je ale zapotřebí klíč v jiném tvaru a to ve tvaru jako RR. Konverze klíče je jednoduchá. Nechá se řádka se jménem domény, k ní připojí na jeden řádek ten base64-public-key řetězec, odstraní se uvozovky a přidá se class a type, takže to bude vypadat takhle:
cz. IN DNSKEY 257 3 5 AwEAAdo9fGLzCyxz1yTlsHCT7JpHrg0q/yOlvDNg39n/gAUzg6H/5X9pjW6mpecJuZirIcPcRw5E7E8uR8g2ztH4uztoc/7ss01s3rTnEgXfilbdpsEdXEuxIfhq+w6zL6PvCcE3qRSzsrc2//x/SXjWp8yeT4YY3W3kvB4Zg5ld0a8bAHBYo4ZY9x7a3qnqOhqunXSG8EfRPD9koUMgWCjdnFNR89L15Bkzh+q1J7phTHIY5akKf3YnIB/5BnKmGBC7DimK4uSBLiBA3DLxHnvLffMT5XtKKHuQ/uZ4IxHWqR2cpHz/6e2WaQvOVILwd0gk9lTCildBGjC7eNxOMnitkuM=
Tohle vložte do nějakýho souboru, např. /root/cz.zone.dnskey a zkuste příkaz dig a cz. +dnssec +sigchase +trusted-key=/root/cz.zone.dnskey a mělo by to zobrazit:
;; NO ANSWERS: no more We want to prove the non-existance of a type of rdata 1 or of the zone: We have a NSEC for this zone :OK OK the NSEC said that the type doesn't exist prove_nx: OK type does not exist ;; An NSEC prove the non-existence of a answers, Now we want validate this NSEC ;; NO ANSWERS: no more Launch a query to find a RRset of type DNSKEY for zone: cz. ;; DNSKEYset that signs the RRset to chase: cz. 2344 IN DNSKEY 256 3 5 BQEAAAAB6BRpKprzQGAzXMnjJ/tonZ9mDptBvLJkWpGrbq/a+IAvJK42 gXugpK+G3j81CaByYKFDUw/m3nPw/TFj5RKBFC7zBsRuQBMl+n12Wb/5 G/UJz0ECnNVaUR4JkaS4mt82Iw0n3SmCZ2Gsydy4fM/IRt19BiUssJXr VrF2nUKdOcs= cz. 2344 IN DNSKEY 257 3 5 AwEAAdo9fGLzCyxz1yTlsHCT7JpHrg0q/yOlvDNg39n/gAUzg6H/5X9p jW6mpecJuZirIcPcRw5E7E8uR8g2ztH4uztoc/7ss01s3rTnEgXfilbd psEdXEuxIfhq+w6zL6PvCcE3qRSzsrc2//x/SXjWp8yeT4YY3W3kvB4Z g5ld0a8bAHBYo4ZY9x7a3qnqOhqunXSG8EfRPD9koUMgWCjdnFNR89L1 5Bkzh+q1J7phTHIY5akKf3YnIB/5BnKmGBC7DimK4uSBLiBA3DLxHnvL ffMT5XtKKHuQ/uZ4IxHWqR2cpHz/6e2WaQvOVILwd0gk9lTCildBGjC7 eNxOMnitkuM= cz. 2344 IN DNSKEY 256 3 5 BQEAAAABrrSyyx1pWNihPWAsBgiEo/ulA3h6+M+NbvM6vueeG9CmQ502 AHWjuThGV0Cp3j8YzUOHYi2HEG2ZOVDs8IoCWlBGOuWrMCjaAlzPaVs7 MgFiRl0D9LO7VU0GjVjI9UAHNjvojm0H7E20v953c1HrjrVL9cVKZ9bS 1aw8KN9zw1E= ;; RRSIG of the DNSKEYset that signs the RRset to chase: cz. 2344 IN RRSIG DNSKEY 5 1 3600 20090801141953 20090718153652 7978 cz. vWx6wN2f4JfFU0iuTBEYBFx1imE+uR1HaD0BMgQWIeHFTc94hZ+Jl5tI nH7kWtQQtb4iTzCWx2kWOCrwLGv6Yw7Ef7ilazRpdSIzZeR9iI/mXWCC HYG3PPUzyGnp53SweJUfZIgIZhKLh644pzcR+iwCBRAhBzCxFTeDhT8R X8/bMyFgiClwoTbE3H7Of3gRB7OBTeKZkhEEBT/deU/ZHv7So70P/fbF TrswgEat31kvUEZfCoBDxNHBr0u5DYC8rKmJsVaza5wEWzoBQDG0/aFL BtZLuli/czvqCclueK+RVs2dOU66YBAAfc2cmQIMxqUamoftHSY1eJy8 BEz5kA== cz. 2344 IN RRSIG DNSKEY 5 1 3600 20090802122050 20090720010712 47420 cz. EGQk/RX8xA2/4klqSFIdDDfiGFBHbV4bDc8cw6sYwlqHhSw2yMpNYCR2 SqCx7fe60ACaZY3ww7a9GZkQcoXG0SAA6pIwCS5EcoeDcMZFwcCWWODJ x4jp5hE5u03lreXKXdvbd0gn1JDykZEN7cqIc8X4taccUb+tCQIdb2LI QtU= Launch a query to find a RRset of type DS for zone: cz. ;; NO ANSWERS: no more ;; WARNING There is no DS for the zone: cz. ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING NSEC RRset for cz. with DNSKEY:47420: success ;; OK We found DNSKEY (or more) to validate the RRset ;; Ok, find a Trusted Key in the DNSKEY RRset: 7978 ;; VERIFYING DNSKEY RRset for cz. with DNSKEY:7978: success ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
Projděte si ten výpis, jsou tam hlášky o ověřování atd. Myslim, že nejdůležitější je na konci to ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS. Sice to není "jo, sedí to draku, seš borec.", ale i tak je to úspěch, ne?
Jako další si můžete zkusit ověřit nic.cz dig a nic.cz. +dnssec +sigchase +trusted-key=/root/cz.zone.dnskey - tam už se toho vypíše ještě víc, zaplní to dokonce celý můj terminál s 88 řádkama.
;; RRset to chase: nic.cz. 740 IN A 217.31.205.50 ;; RRSIG of the RRset to chase: nic.cz. 740 IN RRSIG A 5 2 1800 20090803151301 20090720151301 65273 nic.cz. grsGYleJXAF7qIinDfJLQReg0JyF3eemFFbJ7t0TWW+6jevirxQ6nt7c 23Jp9qqs7OVq8tXVH/fik1tFdcDtz5RYhP1YnrRRC6Z6IzZejtAAtPyJ UpTy5yalIcuTVd5zbFP+xg3l29HWH9nWBvIFcCwietbf5Eg7Fhmt1+R6 kSA= Launch a query to find a RRset of type DNSKEY for zone: nic.cz. ;; DNSKEYset that signs the RRset to chase: nic.cz. 2540 IN DNSKEY 257 3 5 BQEAAAABt3LenoCVTV0okqKYPDnnVJqvwCD9MKJNXg8fcOCdLQYncyoe hpwM5RK2UkZDcDxWkMo7yMa35ej+Mhpaji9si4xXD+Syl4Q06LFiFkdN /5GlVlrIdE3GW7zC7Z4sS14Vz8FbYfcRmhsh19Ob718jGZneGfw2UPbv kyxUR8wD7mguZn02fQ6tjj/Ktp4uSW9tpz3bjGMo2rX+iZk4xgbPaesA OlR/AaHdatGZsWC9CPon8mnLZeu6czm8CBDgBmnf3PE8c5+uyWj1Pw4p p0VQmnX5UrnuGpErg7qXhJm7wY2CRVRMcLX3zmjVWXW1uT9JFh2G+/pZ zxnASfKKltZpuw== nic.cz. 2540 IN DNSKEY 256 3 5 BQEAAAABuvhW3RkuG5J044g2/2tPv4+ShnNloLgvzc6y/zR8u8eim0LB DB6kE0FtULHkNbhy7UQR2I6talstFCo55/fKPeXfwJCo6/DnmV8ONnYj 91/OwQJdLBD67gw3R5GnzJ6t4WqDsY5VZ+YpUZMyrJ8WvmjE062/BA91 HLWC51xyLj0= nic.cz. 2540 IN DNSKEY 257 3 5 AwEAAcNkfvS/b/+0Du0eVViVBnxb5Rt2jDAiv+NLqX53ka03NbYiq2Rv c7IZ+zhfo40PwDCIuJ7/CMXvOkkX7GAnC5CQWZ4jGoA//xtxJ/HIAFkf ThmK5oQqAsdtgjFliRo1QFsXLMbqQlyc0H5xT5Vqlh72U0JlRJUnYtVe F4AThcvwpUI0Rqwt4l80iDwFxes04c1AcBJZKigFX9hlcQi/LyEFOSb+ QP6+K/d/A+p2JydozxV+dRqHIl0oH/hU0FJy9U3VW50yUsPHWeeAdbCJ c+GWSpiGtFIsikTZYzZOWzHt5yiGRlOw1TU9gsl0mjcEM+GZxomPijbV jN2+d9r4Hgc= ;; RRSIG of the DNSKEYset that signs the RRset to chase: nic.cz. 2540 IN RRSIG DNSKEY 5 2 3600 20090803151301 20090720151301 27979 nic.cz. tIurm2oF2BjtTXj5qtvr5XjV2zAh/T51xWIx6S4B2zzdKvXIFnsF8O9F KSlApsPRx6/f6+LXhCcf37M9m+Lazf6pIX3QHnuzEWqjeJmOfv0rOwnP DLOeGGGdy1uEgsEJmggcWaLrAK+5bLG+v0dR9ZaZDLtnXyheV/TG1h15 YXWTYm8tykHXaCjzLd+RRhLh2utjvhPko3J07pSGMCHo02kYJZsGMNDU brSnL6jKFQi/lQQDs/qo5A2OCR9YStWwtmhenaiRlRnRX+BrryU6UnsP sdZ/T2uPz9J9n8b+skaTww42lv2+2+Bg9iSfTygPoWy0k0WMjYXWex2f UEB7zA== nic.cz. 2540 IN RRSIG DNSKEY 5 2 3600 20090803151301 20090720151301 59916 nic.cz. skxUg4W8GxSVMW4HpZLs+iQqmTCOZrmZQwFRXCw7wIubfRMCWKh+Y4qt D1rZOG3rS3Km+KvkfItuMNiFavWVU7BhbSs5Dio5rI4DciBC9OoJpAQ9 9l/eyigD6FU1b8uqFPI/kIZNoCchJ0I59M/uPI/gcnYMKPu3g6LMnHcK HWGXNVkdl1QIdVnJBrx7nZ3wtOrVI5yGz4mlhtClie0VHKpd6nfm7sAW udtfYafynOYJZdgq9jkUtgu9Y22JRpdBqhK614QQPycO5nxuC2eXmeRD Bh429KOEKG1MaLlBMPUv14nkm6AjfZR9nlp85A30K5BaDv/0CXRNZpzm 7A9F6w== nic.cz. 2540 IN RRSIG DNSKEY 5 2 3600 20090803151301 20090720151301 65273 nic.cz. D52Y8zIdxzbA0UfIoH27mkWwb2acyYBGYVOUBpKsVJqpAsAUJPeot7sK jRqodrjx9LSFoe7Tsq7iQPvn66xPxeg35OqN1DoxvqMq8OuVB96BV2YQ QBFg7xqXMBv4ceOZvW+yAGU9KSwHOVVnum2h+mG1ZVAVmxiRPt0h6tyw kTo= Launch a query to find a RRset of type DS for zone: nic.cz. ;; DSset of the DNSKEYset nic.cz. 740 IN DS 27979 5 1 FF11E740A0254EC63C738A47E52ABF3AD91D8C43 nic.cz. 740 IN DS 59916 5 1 144130216E45C4EC2BB8595E817916E8B060D87B ;; RRSIG of the DSset of the DNSKEYset nic.cz. 740 IN RRSIG DS 5 2 1800 20090731210251 20090719130651 47420 cz. ps4NJ6IomhSqeE9/9u+99kG/B4gmf3q0txnTl4k9cLKC+ahec+wcAFFn WNPEYJ3AOlNe8qQDnuSFuDeJDvLSa5gFOzC7OE/BHignBPOq9D5dAFL+ 4QkYpLx6mxELf4qp8b70ML2EHXVJWJ+O6I1AKBSmtvdQLDw2TJk4gaOT Ewo= ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING A RRset for nic.cz. with DNSKEY:65273: success ;; OK We found DNSKEY (or more) to validate the RRset ;; Now, we are going to validate this DNSKEY by the DS ;; OK a DS valids a DNSKEY in the RRset ;; Now verify that this DNSKEY validates the DNSKEY RRset ;; VERIFYING DNSKEY RRset for nic.cz. with DNSKEY:27979: success ;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset ;; Now, we want to validate the DS : recursive call Launch a query to find a RRset of type DNSKEY for zone: cz. ;; DNSKEYset that signs the RRset to chase: cz. 2115 IN DNSKEY 257 3 5 AwEAAdo9fGLzCyxz1yTlsHCT7JpHrg0q/yOlvDNg39n/gAUzg6H/5X9p jW6mpecJuZirIcPcRw5E7E8uR8g2ztH4uztoc/7ss01s3rTnEgXfilbd psEdXEuxIfhq+w6zL6PvCcE3qRSzsrc2//x/SXjWp8yeT4YY3W3kvB4Z g5ld0a8bAHBYo4ZY9x7a3qnqOhqunXSG8EfRPD9koUMgWCjdnFNR89L1 5Bkzh+q1J7phTHIY5akKf3YnIB/5BnKmGBC7DimK4uSBLiBA3DLxHnvL ffMT5XtKKHuQ/uZ4IxHWqR2cpHz/6e2WaQvOVILwd0gk9lTCildBGjC7 eNxOMnitkuM= cz. 2115 IN DNSKEY 256 3 5 BQEAAAABrrSyyx1pWNihPWAsBgiEo/ulA3h6+M+NbvM6vueeG9CmQ502 AHWjuThGV0Cp3j8YzUOHYi2HEG2ZOVDs8IoCWlBGOuWrMCjaAlzPaVs7 MgFiRl0D9LO7VU0GjVjI9UAHNjvojm0H7E20v953c1HrjrVL9cVKZ9bS 1aw8KN9zw1E= cz. 2115 IN DNSKEY 256 3 5 BQEAAAAB6BRpKprzQGAzXMnjJ/tonZ9mDptBvLJkWpGrbq/a+IAvJK42 gXugpK+G3j81CaByYKFDUw/m3nPw/TFj5RKBFC7zBsRuQBMl+n12Wb/5 G/UJz0ECnNVaUR4JkaS4mt82Iw0n3SmCZ2Gsydy4fM/IRt19BiUssJXr VrF2nUKdOcs= ;; RRSIG of the DNSKEYset that signs the RRset to chase: cz. 2115 IN RRSIG DNSKEY 5 1 3600 20090801141953 20090718153652 7978 cz. vWx6wN2f4JfFU0iuTBEYBFx1imE+uR1HaD0BMgQWIeHFTc94hZ+Jl5tI nH7kWtQQtb4iTzCWx2kWOCrwLGv6Yw7Ef7ilazRpdSIzZeR9iI/mXWCC HYG3PPUzyGnp53SweJUfZIgIZhKLh644pzcR+iwCBRAhBzCxFTeDhT8R X8/bMyFgiClwoTbE3H7Of3gRB7OBTeKZkhEEBT/deU/ZHv7So70P/fbF TrswgEat31kvUEZfCoBDxNHBr0u5DYC8rKmJsVaza5wEWzoBQDG0/aFL BtZLuli/czvqCclueK+RVs2dOU66YBAAfc2cmQIMxqUamoftHSY1eJy8 BEz5kA== cz. 2115 IN RRSIG DNSKEY 5 1 3600 20090802122050 20090720010712 47420 cz. EGQk/RX8xA2/4klqSFIdDDfiGFBHbV4bDc8cw6sYwlqHhSw2yMpNYCR2 SqCx7fe60ACaZY3ww7a9GZkQcoXG0SAA6pIwCS5EcoeDcMZFwcCWWODJ x4jp5hE5u03lreXKXdvbd0gn1JDykZEN7cqIc8X4taccUb+tCQIdb2LI QtU= Launch a query to find a RRset of type DS for zone: cz. ;; NO ANSWERS: no more ;; WARNING There is no DS for the zone: cz. ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING DS RRset for nic.cz. with DNSKEY:47420: success ;; OK We found DNSKEY (or more) to validate the RRset ;; Ok, find a Trusted Key in the DNSKEY RRset: 7978 ;; VERIFYING DNSKEY RRset for cz. with DNSKEY:7978: success ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
Tady je opravdu úplně vidět, jak se dělá nejdřív validace nic.cz a pak ověří v zóně cz klíče zóny nic.cz. A dál by se měly klíče od zóny cz ověřit v kořenech, ale tam tuším ještě nejsou, ale nám to nevadí, protože klíč pro cz je trusted.
Takže teď si můžete sami ověřovat pomocí digu zóny, případně tak testovat, že vám to funguje.
Teď jsem si vyzkoušel na naší zóně i jeden podvrh. DNSSEC používá také NSEC záznamy, pomocí kterých ukazuje na další DNS záznam a dokáže tak potvrdit neexistenci nějakého záznamu. Opravdu to funguje, ale to ukážu až při konfiguraci DNSSEC v serveru.
Mám jednu otázku. Nepochopil jsem z návodů, co přesně mám předat do parent zóny - dsset nebo keyset. Tyhle soubory vzniknou při dnssec-signzone a v návodech se píše, že se mají předat do parent zóny. V jednom článku někdo napsal, že posílá administrátorům parent oba, ať se rozhodnou, co potřebují. Taky si ten člověk stěžuje, že to neni nikdy přesně zmíněné, jestli dsset nebo keyset nebo oba. Ale rád bych to věděl přesně. Takže pokud víte, tak pište do komentářů. Tak teď jsem ještě v RFC4641 - DNSSEC Operational Practices našel následující odstavec, což mi případá, že předat by se měl DSSET, ale lepší je předat také KEYSET a mít v parent zóně oba druhy. Pochopil jsem to správně?
4.4.2. Storing Keys or Hashes? When designing a registry system one should consider which of the DNSKEYs and/or the corresponding DSes to store. Since a child zone might wish to have a DS published using a message digest algorithm not yet understood by the registry, the registry can't count on being able to generate the DS record from a raw DNSKEY. Thus, we recommend that registry systems at least support storing DS records. It may also be useful to store DNSKEYs, since having them may help during troubleshooting and, as long as the child's chosen message digest is supported, the overhead of generating DS records from them is minimal. Having an out-of-band mechanism, such as a registry directory (e.g., Whois), to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting. The storage considerations also relate to the design of the customer interface and the method by which data is transferred between registrant and registry; Will the child zone administrator be able to upload DS RRs with unknown hash algorithms or does the interface only allow DNSKEYs? In the registry-registrar model, one can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], which allows transfer of DS RRs and optionally DNSKEY RRs.
Tiskni
Sdílej:
No jo, v .cz už je skoro všechno v pohodě. To v .org jsem musel dát záznam do ISC DLV, protože tam ještě nepřijímají DS zánamy...