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 23:44 | IT novinky

    Na Epic Games Storu lze do 15. června získat zdarma počítačovou hru PAYDAY 2 (ProtonDB, Wikipedie). Linuxový port přestal být ve čtvrtek 8. června podporován.

    Ladislav Hagara | Komentářů: 2
    včera 16:55 | Humor

    Ezoterický programovací jazyk Brainfuck (Wikipedie) slaví 30 let. Urban Müller nahrál první implementaci tohoto jazyka na Aminet 9. června 1993.

    Ladislav Hagara | Komentářů: 3
    včera 16:22 | Komunita

    Společnost Apple na konferenci WWDC23 představila Game Porting Toolkit. Společnost CodeWeavers informuje, tento toolkit vychází ze zdrojových kódů jejího CrossOveru, tj. komerčního Wine.

    Ladislav Hagara | Komentářů: 1
    8.6. 23:11 | Nová verze

    Byla vydána květnová aktualizace aneb nová verze 1.79 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.79 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

    Ladislav Hagara | Komentářů: 5
    8.6. 22:22 | IT novinky

    Jak to bude s podporou rastrového grafického formátu JPEG XL ve webových prohlížečích? Google ji nedávno z Chrome a Chromia odstranil (#1178058#c84). Jednou z novinek beta verze Safari 17 je ale právě podpora JPEG XL. Vráti se JPEG XL do Chrome a Chromia (#1451807)? Dění kolem JPEG XL lze sledovat například na r/jpegxl.

    Ladislav Hagara | Komentářů: 1
    8.6. 12:55 | Nová verze

    Byla vydána nová stabilní verze 6.1 (aktuálně 6.1.3035.51) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 114. Přehled novinek i s náhledy v příspěvku na blogu. Nový Vivaldi se pro Bing tváří jako Microsoft Edge (upravený User-Agent) a díky tomu v něm funguje Bing Chat. Vylepšeny byly Pracovní prostory (Workspaces). Podrobný přehled v Changelogu.

    Ladislav Hagara | Komentářů: 1
    8.6. 11:00 | Komunita

    Linuxová distribuce ArchLabs Linux po šesti letech vývoje končí. Dobbie to zabalil.

    Pinhead | Komentářů: 7
    7.6. 22:44 | Zajímavý článek

    David Tschumperlé v obšírném článku se spoustou náhledů shrnuje vývoj multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie) za poslední rok a půl.

    Ladislav Hagara | Komentářů: 0
    7.6. 17:11 | Nová verze

    Vývojáři postmarketOS vydali verzi 23.06 tohoto před šesti lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, Plasma a Sxmo. Aktuálně podporovaných zařízení je 30.

    Ladislav Hagara | Komentářů: 0
    7.6. 16:33 | Nová verze

    Byla vydána distribuce openSUSE Leap verze 15.5 (poznámky k vydání). Jde o konzervativní distribuci odpovídající komerčnímu SUSE Linux Enterprise 15, nyní Service Pack 5. Mělo jít o poslední aktualizaci Leap v současné podobě před přechodem na Adaptable Linux Platform s „neměnným“ základem, ale padlo rozhodnutí, že v roce 2024 ještě vyjde Leap 15.6 s podporou do konce roku 2025.

    Fluttershy, yay! | Komentářů: 0
    Twitter (nejen pro příležitostné čtení)
     (92%)
     (2%)
     (6%)
    Celkem 321 hlasů
     Komentářů: 7, poslední dnes 09:25
    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: 964×
    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: 21 | 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.