abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 17:33 | Komunita

Společnost Purism informuje o aktuálním vývoji chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů. Telefon už umí telefonovat. Librem 5 by měl být k dispozici v lednu 2019. Předobjednat jej lze za 599 dolarů.

Ladislav Hagara | Komentářů: 10
včera 09:00 | Bezpečnostní upozornění

Společnost Qualys zveřejnila výsledky bezpečnostního auditu procps-ng. Nalezeno bylo 7 bezpečnostních chyb (CVE-2018-1120, CVE-2018-1121, CVE-2018-1122, CVE-2018-1123, CVE-2018-1124, CVE-2018-1125 a CVE-2018-1126). Dvě z nich jsou zneužitelné k lokální eskalaci práv. Příslušné záplaty jsou již k dispozici v upstreamu.

Ladislav Hagara | Komentářů: 1
18.5. 06:44 | Nová verze

Byla vydána třiadvacátá alfa verze svobodné historické realtimové strategie 0 A.D. (Wikipedie). Kódový název této nejnovější verze je Ken Wood. Představení novinek v poznámkách k vydání a také na YouTube.

Ladislav Hagara | Komentářů: 3
18.5. 05:55 | Zajímavý článek

Tento týden se v Cambridge ve Velké Británii konal hackfest, který měl za cíl zlepšit výkon na GNOME postavených systémů na slabších počítačích. Hans de Goede například analyzoval spotřebu paměti jednotlivých komponent ve Fedora 28 Workstation na stroji s 2 GB RAM a pomocí kroků popsaných v článku Kde uspořit paměť ve Fedora Workstation na MojeFedora.cz snížil spotřebu paměti z 1,4 GB na 765 MB.

Ladislav Hagara | Komentářů: 8
17.5. 20:55 | Nová verze

Bram Moolenaar oznámil vydání verze 8.1 textového editoru Vim (Vi IMproved). Hlavní novinkou je integrovaný terminál.

Ladislav Hagara | Komentářů: 8
17.5. 16:55 | Nová verze

Bylo oznámeno vydání nové stabilní verze 1.27 a beta verze 1.28 open source textového editoru Atom (Wikipedie). Přehled novinek i s náhledy v příspěvku na blogu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 6
17.5. 11:11 | Nová verze

Byla vydána verze 5.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Před měsícem slavil Proxmox VE 10 let (pdf).

Ladislav Hagara | Komentářů: 16
17.5. 10:22 | Nová verze

Byla vydána verze 4.8 a záhy na to opravná verze 4.8.1 svobodné náhrady proprietárních BIOSů coreboot (Wikipedie). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 10
16.5. 05:55 | Komunita

Správce souborů (Files, Soubory, Nautilus) v nejnovějším GNOME 3.28 již neumožňuje zobrazovat ikony na ploše. Dalším vylepšením bude pravděpodobně odstranění možnosti spouštění aplikací (commit) přímo ze správce souborů.

Ladislav Hagara | Komentářů: 126
16.5. 04:44 | IT novinky

Dnes končí crowdfundingová kampaň na podporu modulárního open source routeru Turris MOX od CZ.NIC. Cílová částka 250 tisíc dolarů byla vybrána. Z posledních novinek představených v rámci kampaně lze zmínit demo webového rozhraní, spolupráci s Nextcloudem a Turris MOX: Cloud nebo konfigurátor pro testování kompatibility jednotlivých modulů.

Ladislav Hagara | Komentářů: 19
Používáte pro některé služby inetd?
 (32%)
 (26%)
 (43%)
Celkem 129 hlasů
 Komentářů: 3, poslední 9.5. 08:05
    Rozcestník

    Dotaz: Jak správně delegovat PTR záznamy na další DNS server

    8.6.2012 16:13 ekameron
    Jak správně delegovat PTR záznamy na další DNS server
    Přečteno: 837×
    Ahoj. Poskytovatel mi nadelegoval pomocí CNAME záznamy na můj dns server. Je to udělané přesně takto: http://www.zytrax.com/books/dns/ch9/reverse.html. Jak jsem pochopil, tak toto je standardní řešení, ale nechápu proč. Mohl by mi to někdo vysvětlit? Proč není lepší udělat u poskytovatele záznam v named serveru typu "$GENERATE 1-126 $ IN NS muj.dns.cz."? Takhle to vlastně poskytovatelův dns přeloží na CNAME a odkáže na mojí speciální zónu 0/25.x.x.x.in-addr.arpa. Neboť já můj dns server používám ze vnitřní sítě i jako rekurzivní dns a chci, aby mi překlad PTR fungoval i při výpadku internetu, pak jsem musel rozdělit v bindu 2 pohledy: vnější a vnitřní. Ve vnějším mám zónu 0/25.x.x.x.in-addr.arpa., ve vnitřním zónu x.x.x.in-addr.arpa. - v této zóně mám odkaz na cizí ip adresy pomocí $GENERATE ... NS k poskytovatelově dns. Je to funkční, ale docela drastické řešení. Když už mi ve vnitřní síti funguje zápis pomocí $GENERATE ven, proč se to zvenku musí dělat jinak? Snad jsem to našel i v nějakém RFC. Je k tomu nějaký důvod?

    Odpovědi

    8.6.2012 16:43 xHire | skóre: 20 | blog: Linuxovník
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Jediné zdůvodnění, které mě napadá, je, že při CIDRu je potřeba delegovat každou jednotlivou IP adresu (nejde delegovat celou doménu). Pokud by se nepoužil CNAME, tak by se musely pro každou adresu zavést dva (nebo více) NS záznamů. Pokud se deleguje jedna nebo dvě adresy, tak to samozřejmě nedává smysl, ale jakmile se jednomu člověku (resp. na jednu sadu jmenných serverů) deleguje více adres, tak už je to úspora v uchovávaných záznamech.

    Druhá věc je, že cíl toho CNAME záznamu se u klienta nacachuje, takže při dotazu na další adresu z delegovaného rozsahu se pošle jako odpověď pouze ten CNAME, nemusí se už znovu ptát na NS záznamy. Ale význam tohoto vlivu asi není moc významný.

    Sám o tomhle řešení taky nejsem zrovna přesvědčený.

    P.S.: Díky za ten odkaz.
    Kryptoměny a bločenka.
    9.6.2012 19:30 d'areback
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Protoze je to normalni a v duchu DNS. Naopak vas navrh vidim jako hotovou ztrestenost. Pro kazdou IP adresu vlastni subdomenu? Fuj. V dusledku RFC2317 spravce puvodni reverzni domeny u sebe v zone jasne deklaruje "vrat kanonicke jmeno nebo zdechni", pricemz pristup nevyzadoval skoro zadne upravy DNS (jen se jasne reklo, ze zatimco konecnym vysledkem hledani PTR je vzdy kanonicke jmeno, v procesu hledani se muze objevit i CNAME alias). Kdezto vas navrh by tehdy nezvladala spousta DNS serveru a zasah do tehdejsich principu DNS by byl podstatne vetsi.

    BTW Ve sve konfiguraci vlastne deklarujete existenci subdomeny u poskytovatele, o ktere poskytovatel nic nevi. Navic to muze byt CNAME. Pekny humus. Funguje to jen diky tomu, ze DNS implementuji rozumni a tolerantni lide, kteri uzivateli leccos odpusti.

    PS Vase fascinace direktivou $GENERATE je zajimava, ale je to jen direktiva jedne konkretni implementace DNS serveru - BINDu.
    10.6.2012 03:34 ekameron
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Však jo, psal jsem to o bindu, to $GENERATE zkrátí spoustu zápisů, proto to tady i v konfiguraci používám.
    BTW Ve sve konfiguraci vlastne deklarujete existenci subdomeny u poskytovatele, o ktere poskytovatel nic nevi. Navic to muze byt CNAME. Pekny humus. Funguje to jen diky tomu, ze DNS implementuji rozumni a tolerantni lide, kteri uzivateli leccos odpusti.
    Ono by to jen tak nefungovalo. Deklaruju to tak proto, že vím, jak a kde jsou PTR záznamy pro zbytek C rozsahu IP adres definovány. Že je to prasárna naprosto souhlasím. Uvítám jakýkoliv zajímavý nápad, jak to řešit jinak. K tomuhle jsem se odhodlal poté, kdy jsem během výpadku internetového spojení musel pracovat s různými servery ve vnitřní síti. Tyto servery mají ip adresy z delegovaného PTR rozsahu a proto některé služby prakticky nefungovaly (hlavně SSH, kde se ověřuje PTR záznam apod.). Jednoduše proto, že dns servery pro PTR nebyly k dispozici.
    10.6.2012 12:57 d'areback
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Pozadat spravce DNS u poskytovatele o povoleni prenosu zony a zridit u sebe neverejny sekundar pro prislusnou zonu. Pokud to nepovoli, zvednout TTL u PTR zaznamu co to da a tlouct hlavou do zdi za zvorany navrh infrastruktury nerespektujici omezene pripojeni.
    10.6.2012 15:52 ekameron
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Mám přidělenou polovinu C rozsahu IP adres. Často potřebuji měnit dns záznamy. Poskytovatel mi proto doporučil delegovat všechny dns záznamy na můj primární dns server, což je jediné možné funkční řešení při mé situaci. Zase tak omezené připojení to není, poslední výpadek nastal tak před rokem, ale i tak je to problém. Přenos zóny je v bledě modrém to, co řeším přesměrováním na NS servery. Nějak nechápu jak jinak mohu mít navrženou infrastrukturu?
    10.6.2012 21:00 d'areback
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Ja treba vidim docela zasadni rozdil mezi automatickou replikaci DNS zony a rucnim smudlanim zaznamu. Ale kdo chce kam, pomozme mu tam.
    10.6.2012 22:08 ekameron
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Rozdíl tam určitě je. Pokud budu odkazovat pomocí NS záznamu na dns poskytovatele, tak nemusím řešit aktualizaci zón a je to méně poruchové. Podle mě je to rozumnější než replikovat celý reverzní zónový soubor pro C-čkový rozsah IP adres. Ty adresy nejsou moje, tak proč bych je měl mít u sebe? Myslím, že oba způsoby (jak můj, tak navrhovaný) jsou docela prasácké, nicméně vzhledem k návrhu dns asi nezbytné.
    10.6.2012 22:22 d'areback
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Nevim, co si predstavujete pod pojmem "resit aktualizace zon" v pripade mistniho sekundarniho DNS. Mozna byste si mel neco o DNS precist. Ten muj zpusob aspon neni technicka prasarna. Ten vas je humus na vyhazov. Mnoho zdaru.
    11.6.2012 06:49 ekameron
    Rozbalit Rozbalit vše Re: Jak správně delegovat PTR záznamy na další DNS server
    Poskytovatel by byl blázen, kdyby mi posílal notifikace o aktualizacích. Musel by buď upravit zónový soubor (což v tomto případě nelze - nemůže deklarovat autoritativní NS, kde není) nebo ručně nakonfigurovat v bindu (což zde lze) sekundární dns servery. Takže tím řešit aktualizace jsem myslel to, že bych musel periodicky provádět transfer zón vyvolaný ze sekundáru. Oba způsoby jsou technické prasárny, neboť se spoléhají na existenci záznamů na konkrétním vzdáleném serveru. Jak jsem psal, uvítám nápady jak tohle řešit, ale tohle je vyhánění čerta ďáblem. Cílem je najít něco, co nespoléhá na existenci záznamů na konkrétním dns serveru.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.