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

[ekameron]

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

[xHire]

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.

[d'areback]

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.

[ekameron]

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.

[d'areback]

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.

[ekameron]

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?

[d'areback]

Ja treba vidim docela zasadni rozdil mezi automatickou replikaci DNS zony a rucnim smudlanim zaznamu. Ale kdo chce kam, pomozme mu tam.

[ekameron]

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é.

[d'areback]

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.

[ekameron]

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.