Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
Meta převezme sociální síť pro umělou inteligenci (AI) Moltbook. Tvůrci Moltbooku – Matt Schlicht a Ben Parr – se díky dohodě stanou součástí Meta Superintelligence Labs (MSL). Meta MSL založila s cílem sjednotit své aktivity na poli AI a vyvinout takovou umělou inteligenci, která překoná lidské schopnosti v mnoha oblastech. Fungovat by měla ne jako centralizovaný nástroj, ale jako osobní asistent pro každého uživatele.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cznetstat -nl a tam uvidíte, zda na portech 53 něco naslouchá. Transfer zóny iniciuje sekundární DNS server, takže sekundární DNS server na portu tcp/53 naslouchat nemusí. Sekundární (v terminologii bindu) server se dotazuje v pravidelných intervalech primárního, zda nedošlo ke změně (to pozná podle zvyšujícího se sériového čísla u SOA. Tj. transfer domény se neprovede hned po změně. Existují způsoby, jak může primární server dát o změně sekundárním serverům vědět, ale to je rozšíření, které by se případně muselo nakonfigurovat.
Jan 26 14:58:59 localhost named[4790]: client ipsekundarnihoDNS#63694: transfer of 'mojedomena.tld/IN': AXFR started Jan 26 14:58:59 localhost named[4790]: client ipsekundarnihoDNS#63694: transfer of 'mojedomena.tld/IN': AXFR endedTrochu nechápu ta vysoká čísla portů a vzhledem k tomu, že i já i sekundární DNS je za NATem, tak se není čemu divit. Jak jsem psal, také případné problémy může působit NS záznam v mojí zóně pro sekundární server. Pokud zadám ns2.mojedomena.tld, a přidám A záznam na IP sekundárního serveru, tak asi bude problém v tom, že reverzní záznam se bude překládat na doménu toho sekundárního serveru, nikoli na mojí. Když zkusím NS záznam ns2.mojedomena.tld a přiřadím CNAME na doménu sekundárního srveru, tak je to ale myslím proti nějakému RFC, protože NS záznamy by měly mít ekvivalentní A záznam. TAk mě napadlo ještě zkusit přímo NS záznam doména sekundárního serveru, ale to BIND ignoruje, protože to nejsou data této zóny. Tak už nevím, co je správně. Co se týče informování sekundárního serveru primárním, tak mám v primárním serveru v master zóně nastaveno notify yes. Vím, že ještě existuje rndc a key, ale to zatím nepoužívám, nejdříve to musí chodit takto. Díky za radu a za čas.
Tohle ale podle mne znamená, že se transfer zóny provedl. Nějak se v tom ztrácím, v čem je vlastně problém… Obecně by měl NS záznam obsahovat doménové jméno DNS serveru, přičemž toto doménové jméno může být z libovolné domény. Takže ve vašem případě můžete pro sekundární server použít buď nějaké jeho jiné doménové jméno (pokud nějaké má), nebo mu nastavit třebaJan 26 14:58:59 localhost named[4790]: client ipsekundarnihoDNS#63694: transfer of 'mojedomena.tld/IN': AXFR started Jan 26 14:58:59 localhost named[4790]: client ipsekundarnihoDNS#63694: transfer of 'mojedomena.tld/IN': AXFR ended
ns2.mojedomena.tld, pak by ale měl být A záznam o ns2.mojedomena.tld ve vašem zónovém souboru, a navíc musí být jako tzv. glue záznam v nadřazené doméně, tj. v tld (u správců domén nejvyšší úrovně je zadávání glue záznamů běžná věc, pokud ve skutečnosti vytváříte doménu třetího nebo dalšího řádu, musíte o vytvoření glue záznamu muste požádat správce nadřízené domény).
ipsekundarnihoDNS#63694očekával bych
ipsekundarnihoDNS#53.
Nemyslím, že by v tom reverzní záznamy podřízeného serveru hrály nějakou roli. Jednak by to znamenalo, že každý podřízený server může obhospodařovat jen jednu doménu, jednak RFC snad žádné master a slave servery nerozlišuje, to je terminologie bindu.To mi právě vrtalo hlavou a asi jsem příliš důvěřoval nějakému online checkeru zón, který jsem tu někde v diskusi viděl, ten psal, že by s tím mohl být problém. Už to chápu, děkuji.
Tiskni
Sdílej:
