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í
×

dnes 18:56 | Nová verze

Byla vydána nová stabilní verze 1.9 (1.9.818.44) webového prohlížeče Vivaldi (Wikipedie). Z novinek vývojáři zdůrazňují podporu nového vyhledávač Ecosia. Ten z příjmů z reklam podporuje výsadbu stromů po celém světě (YouTube). Nově lze přeskupovat ikonky rozšíření nebo řadit poznámky. Nejnovější Vivaldi je postaveno na Chromiu 58.0.3029.82.

Ladislav Hagara | Komentářů: 0
dnes 17:00 | Nová verze

Byla vydána verze 3.7.0 svobodného systému pro správu obsahu (CMS) Joomla!. V oznámení o vydání (YouTube) se píše o 700 vylepšeních. Opraveno bylo také 8 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0
dnes 08:22 | Komunita

Grsecurity (Wikipedie) je sada bezpečnostních patchů pro linuxové jádro (porovnání se SELinuxem, AppArmorem a KSPP). Od září 2015 nejsou stabilní verze těchto patchů volně k dispozici. Dle včerejšího oznámení (FAQ) nejsou s okamžitou platností volně k dispozici už ani jejich testovací verze.

Ladislav Hagara | Komentářů: 24
včera 23:33 | Komunita

OpenBSD 6.1 vyšlo již 11. dubna. Po dvou týdnech byla vydána i oficiální píseň. Její název je Winter of 95 a k dispozici je ve formátech MP3 a OGG.

Ladislav Hagara | Komentářů: 0
včera 18:55 | Nová verze

Byla vydána verze 2017.1 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux. S vydáním verze 2016.1 se Kali Linux stal průběžně aktualizovanou distribucí. Aktualizovat jej lze pomocí příkazů "apt update; apt dist-upgrade; reboot".

Ladislav Hagara | Komentářů: 0
včera 18:22 | Nová verze

Po téměř pěti letech od vydání verze 2.00 byla vydána nová stabilní verze 2.02 systémového zavaděče GNU GRUB (GRand Unified Bootloader). Přehled novinek v souboru NEWS.

Ladislav Hagara | Komentářů: 11
včera 17:55 | Komunita

Vývojáři Debianu oznámili, že od 1. listopadu letošního roku nebudou jejich archivy dostupné pomocí protokolu FTP. Již v lednu oznámil ukončení podpory FTP kernel.org (The Linux Kernel Archives).

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

V oblíbeném webmailu postaveném na PHP SquirrelMail (Wikipedie) byla nalezena bezpečnostní chyba CVE-2017-7692, jež může být útočníkem zneužita ke spuštění libovolných příkazů a kompletnímu ovládnutí dotčeného serveru. Zranitelnost se týká pouze instancí, kde je pro transport používán Sendmail.

Ladislav Hagara | Komentářů: 3
včera 13:11 | Zajímavý článek

Soudní dvůr Evropské unie rozhodl (tisková zpráva) ve věci C-527/15: Prodej multimediálního přehrávače, který umožňuje zdarma a jednoduše zhlédnout na televizní obrazovce filmy protiprávně zpřístupněné na internetu, může představovat porušení autorského práva.

Ladislav Hagara | Komentářů: 27
25.4. 13:33 | Pozvánky

Byly stanoveny termíny konferencí LinuxDays 2017 a OpenAlt 2017. Letošní LinuxDays proběhne o víkendu 7. a 8. října v Praze v Dejvicích v prostorách FIT ČVUT. Letošní OpenAlt proběhne o víkendu 4. a 5. listopadu na FIT VUT v Brně.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (4%)
 (35%)
 (1%)
 (6%)
 (45%)
 (9%)
Celkem 322 hlasů
 Komentářů: 50, poslední dnes 04:06
    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: 780×
    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: 19 | 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.
    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.