Z aktualizovaného seznamu chyb (pdf) procesoru AMD EPYC 7002: #1474 - procesor se po 1044 dnech od posledního resetu zasekne [reddit].
Fossil (Wikipedie) byl vydán ve verzi 2.22. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
David Malcolm se ve svém příspěvku na blogu vývojářů Red Hatu rozepsal o vylepšeních statické analýzy (volba -fanalyzer) v GCC 13.
Byla vydána nová stabilní verze 23.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Stoat. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Příspěvek na blogu CZ.NIC upozorňuje na nový útok na weby v Česku. Na honeypotech na Turrisech byla zaznamenána nová aktivita útočníků - probíhající útok na FTP servery, které se vyskytují na stejné IP adrese, jako aktivní WEB server.
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi 2023.05. Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Linux Foundation Europe představila projekt RISE (RISC-V Software Ecosystem), jehož cílem je urychlit vývoj open source softwaru pro architekturu RISC-V.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu pro jednodeskové počítače na platformě ARM, byl vydán ve verzi 23.05. Přehled novinek v Changelogu.
Minulý týden proběhla openSUSE Conference 2023. Mimo jiné bylo oznámeno přejmenování systému MicroOS Desktop. MicroOS Desktop GNOME byl přejmenován na openSUSE Aeon a MicroOS Desktop Plasma na openSUSE Kalpa.
Thom Holwerda z OSnews si všímá, že vývoj operačního systému MINIX je prakticky mrtvý. Jeho hlavní autor, Andrew Tanenbaum, formálně odešel do důchodu v roce 2014 a příspěvky do kódu v následujících letech vůbec ustaly. Stav projektu shrnuje diskuze z roku 2020. Sice vyšlo najevo, že Intel používal MINIX v Management Engine, ale změny nezveřejňoval.
Dobrý den, není mi jasné, jak nastavit reverzní zonu u autoritativního DNS serveru pokud obsahuje více zón.
Na jedinou veřejnou IP adresu je registrováno více domén.
//named.conf ... zone "domena1.cz" { type master; file "domena1.named"; }; zone "domena2.cz" { type master; file "domena2.named"; }; zone "72.75.77.in-addr.arpa" { type master; file "public.rev"; };
Záznamy v souboru public.rev se mají shodovat s doménou1 nebo doménou2? Na základě čeho vybírám doménu použitou v reverzním souboru?
// public.rev ... 1 IN PTR server.domena1.cz. 2 IN PTR petter.domena1.cz. 3 IN PTR polane.domena1.cz. // a nebo: //1 IN PTR server.domena2.cz. //2 IN PTR petter.domena2.cz. //3 IN PTR polane.domena2.cz. //proč?
Děkuji za vysvětlení.
Tomáš
Řešení dotazu:
napr pro prideleny ceckovy rozsah aaa.bbb.ccc.xxx bude reverzni ccc.bbb.aaa.in-addr.arpa a v nem 1 IN PTR server1.domena1.cz. 2 IN PTR server2.domena1.cz. 3 IN PTR server1.domena2.cz. 4 IN PTR server2.domena2.cz. ...
Děkuji moc za pomoc. Je mi jasné na co se používají reverzní záznamy. Nevím jak složit reverzní soubor na serveru, na jehož jedinou IP adresu je registrováno více domén.
Použil jste příklad:
napr pro prideleny ceckovy rozsah aaa.bbb.ccc.xxx 1 IN PTR server1.domena1.cz. 2 IN PTR server2.domena1.cz. 3 IN PTR server1.domena2.cz. 4 IN PTR server2.domena2.cz.
ale my máme pouze jediný server s jedinou veřejnou IP adresou. Tedy:
//domena1.named ... domena1.cz. A 72.75.77.1
//domena2.named ... domena2.cz. A 72.75.77.1
toto asi nebude dobře, že?
1 IN PTR server1.domena1.cz. 1 IN PTR server1.domena2.cz.
Nevím jak bude vypadat reverzní soubor pro 72.75.77.in-addr.arpa
Máte v podstě tři možnosti:
IP adresa -PTR-> jmeno -A-> tataz IP adresa
jmeno -A-> IP adresa
" s PTR nutna neni).Násobný A záznam opravdu ničemu nevadí, ale o tom tady řeč nebyla.
A záznamy a reverzní záznamy si mají odpovídat. Tj. existuje-li k nějakému jménu záznam s určitou hodnotou, měli bychom toto jméno dostat reverzním lookupem té adresy. A samozřejmě i naopak. Že se to dnes v masovém měřítku porušuje kvůli pochybným SEO-poučkám typu "web by měl být dostupný i bez www", to je věc jiná.
When in doubt, ask sleuth. :-)
a A ip1 A ip2nevadí, ale násobný A záznam ve stylu
a A ip1 b A ip1vadí a měl by se použít záznam CNAME.
Násobný záznam je ale jen to první. To druhé by AFAIK mělo jít, bude-li reverzní záznam násobný; aspoň jsem tedy nikde v RFC nenašel nic, co by takovou konstrukci zakazovalo.
On je obecně problém, že zatímco se RFC týkající se DNS celkem podrobně zabývají situací, kdy je potřeba jedno jméno přeložit na víc adres (včetně toho, jak v tom případě mají vypadat reverzní záznamy), opačnou situací (více jmen na jednu adresu), která je dnes podstatně častější, se nezabývají prakticky vůbec.
U každého záznamu použijte to jméno, které má A záznam s příslušnou hodnotou. Tedy tak, aby si A záznamy odpovídaly s reverzními.
Mezi "přímými" a "reverzními" doménami není obecně žádná korespondence 1:1. Domény pro reverzní záznamy odpovídají síťovým rozsahům a adresám z jednoho rozsahu mohou odpovídat jména z mnoha různých domén.
Pokud máš server s jednou/nebo více adresami z rozsahu od nějakého ISP, pak musíš požádat o reverzní záznam tohoto ISPNebo o classless delegaci.
Tiskni
Sdílej: