Názory k článku Srdce Internetu = root servers?

No tak abych se trochu zastal míry tempíra. Vlastně jsem tak nějak čekal, kdo se tady s tím djbdns vytasí. Opravdu pěkná diskuze. Celkem se nešlo ani moc na krev. :-) Tak jen takovej postřeh možná už OT, ale když už se hovořilo o dostupnosti a možnosti DoSu na těch root kompech. Bez ohledu na důvěryhodnost zdroje, jsem četl o tom, že djbdns je schopno zpracovat více dotazů než BIND při stejných parametrech hardwaru. Tuším, že to uvádí samotný DJB na cr.yp.to, ale můžeme mu zkusit věřit nebo to sami testnout. Nejsem specialista na tuhle problematiku, ovšem to oddělení cache (těď doufám nekecám) by mělo mít ještě tu vlastnost, že při pokusu o DoS vám přinejhorším klekne právě jen tahle část sytému.

Ale djb ma uplne stejnou vlastnost. Od chvile, kdy pridal schopnost provozu "vlastnich" domen, ktere nemaji oporu v delegaci realneho DNS stromu tam pridal presne tu vlastnost, ktera je BINDu vycitana - i djb vraci domeny, ktere jsou (mozna) delegovany jinde nebo nejsou delegovany vubec. I djb, stejne jako BIND funguje dobre, kdyz je nakonfigurovano v souladu s tim, jak tento software vyzaduje, i djb, stejne jako BIND funguje mizerne, kdyz v souladu s vlastni dokumentaci a prislusnymi doporucenimi nakonfigurovano neni.

Hlavni rozdil, ktery mezi nimi vidim je tedy ten, ze zatimco BIND lze nakonfigurovat tak, aby mel zcela oddelene funkce, tak jako je ma DJB, DJB nelze nakonfigurovat tak, aby obe funkce provozoval "najednou". BIND je tedy flexibilnejsi. Ano, kdyz se rekne A, musi se rict B, flexibilnejsi software byva slozitejsi a slozitejsi software byva nachylnejsi k tomu, aby obsahoval SKUTECNE chyby (skutecna chyba je, kdyz spravne nakonfigurovany software reaguje nespravne). Ja nemam potrebu mit jednoho favorita - BIND proste je flexibilnejsi, DJB je jednodussi a tak, napriklad, snaze pochopitelny laikum. Nenapadlo by me ale povazovat djb za chybny, protoze nemohu resolver pro uzivatele a autoritativni server domeny provozovat na jednom pocitaci, stejne jako nepovazuji BIND za chybny proto, ze na primy (blby) pokyn sveho pana podava blbe odpovedi.

Ja plne respektuji a chapu, ze se djb neco nelibi a proto to udelal jinak. Ale lze-li jednu vec udelat vice zpusoby, nemyslim si, ze az na jeden musi byt vsechny chybne a stejne tak si nemyslim, ze kategorie "vadny/spravny" ma neco do cineni "libi/nelibi".

V mem poslednim clanku pro Lupu jsem napsal, ze se mi pridelovani drazbou NELIBI, ale je zrejme nutne ho povazovat za SPRAVNE. A to je tentyz princip na ktery se snazim poukazat zde - veci se mi mohou nelibit, ale to neni dostacujici duvod pro to, abych je oznacil za spatne - na to musim mit duvody trochu zasadnejsi. Ale je mozne, ze jen pouzivam a chapu bezna ceska slova v jinem vyznamu, nez vsichni ostatni ...

V kazdem dopisu pisete, ze BIND je vadny. Ale vyjma pocatecnich prispevku uz se nikdy nezminujete proc vlastne je podle vas vadny. Ve svych prvnich prispevcich jste uvedl, pokud to spravne interpretuji, ze je vadny proto, ze ho lze konkretni konfiguraci donutit ke konkretni cinnosti. Pokousel jsem se vam vysvetlit, ze v zavislosti na konfiguraci funguje BIND prakticky stejne jako djbdns a obracene, djbdns funguje, pro urcite konfiguraci, skoro ekvivalentne BINDu. Vy presto tyto software nejak rozlisujete - jeden je podle vas "vadny", kdezto je urcen pro vysoke naroky (i kdyz s usmevem). Snazil jsem se zjistit, v cem DOOPRAVDY vidite rozdil - oba lze nakonfigurovat tak, aby fungovaly vice zpusoby a hlavni rozdil, ktery vidim je, ze zatimco u BINDu MOHU rozdelit funkcnost na dve, u djbdns NEMOHU obe funkcnosti spojit. Kazdopadne, zrejme neumim spravne klast otazky - a nebo, coz take nemohu vyloucit, ve skutecnosti zadny vyslovitelny rozdil necitite a jde pouze o vas pocit a sympatie. Proti tem ja nic nemam, ale nezamenuji obvykle "nesympaticky" za "chybny".

Jestli to dobre chapu, tak se vam libi pristup bindu v tom, ze funguje tak, jak je nakonfigurovan (spatne kdyz spatne, dobre kdyz dobre). Na jednu stranu mi to prijde logicke, protoze se mi taky nelibi preudo-inteligentni reseni a la ms (jak uz tady nekdo zminoval).
Na druhou stranu ale chapu djb, kdyz se mu toto nelibi. Z meho pohledu je dost dobre videt podobny pristup ze strany smtp serveru. Taky funguji spatne, kdyz jsou nakonfigurovany spatne. Bohuzel zde je takovym "trosku" neprijemnym efektem i to, ze se kazdou hodinu pres tisice openrelay serveru zenou miliony spamu. :-(
Proto mi pristup djb pripada taky trochu "preventivni". U smtp to nejspis neni mozne, ale u dns to mozne je, tak proc to nevyuzit?

Nemyslim si, ze lzete umyslne. Pouze si myslim, ze pisete rychleji, nez si stacite uvedomit vsechny souvislosti.

Uz mne to trochu nastvalo, protoze se mi nechtelo psat porad dokola ty stejne argumenty.

Ostatne vyznam slova "kecat" se blizi spis vyznamu "vykladat neoverena domnenky" nez "lhat".

Myslite tim instalaci dvou paralelnich bindu ? To jsem si neuvedomil, sorry.

Pokud byste myslel, ze lzu umyslne, rikejte mi lhari. Kdyz mi rikate, ze kecam, nevim jestli to mam brat jako vulgarismus nebo tak mluvite normalne.

No mne to je vcelku jedno co CZ.NIC vymysli, do te doby co tu bude monopol si muzou delat cokoliv a neudalame s tim nic. No a proti nim samotnym uz vubec nic nemam, ja byt na jejich miste bych ty poplatky jeste zvysil, cim vic stihnu nahrabat, tim lip ne ? To, ze tu je monopol, neni snad jejich chyba ne ?

Bind je vadny svou podstatou, ne tim, ze by neco nekontroloval. On ani nemuze.

Na sve okoli kladu vysoke naroky, takze pouzivam djbdns ;-)

Bind vam pokud vim tuto moznosto nedava

Kecate, BIND muzete nakonfigurovat stejne jako ten vas uzasny djbdns, ostatne v nekterem dalsim prispevku je napsane jak.

Nemuzu za to, ze nejste schopen pochopit argumenty protistran.

No SMTP a POP3 jsou dva ruzne protokoly na ruznych portech, takze jaksi neni duvod to mit na ruznych IP. Ale to uz je mimo predmet diskuse - tim byly podle meho nazoru 'problemy vyplyvajici z navrhu bindu'.

Tady uz jsme dokazali, ze to nemusi byt pravda. Zvlaste v pripade lokalni domeny, pro kterou nejsou obcas dosazitelne root servery.

No to je o necem jinem. Tim muzete vytvorit svou soukromou TLD. Pokud to udelate pro nejakou globalne platnou domenu, delate to na sve riziko. Bind vam pokud vim tuto moznosto nedava. Pokud se po teto diskusi zvetsilo povedomi o djbdns, myslim, ze diskuse mela smysl.

Kontrola spravnosti nameserveru pred jejich delegaci neni vymyslem ani napadem CZ.NIC. Ano, existuji domeny, kde je pro delegaci dulezitejsi otazka zda platite a nikoho tam nezajima v jakem stavu delegovana domena je. A ja jsem dalek to povazovat za chybu - jde i rozhodnuti, ktera ma znovu sva pro i proti a je na kazdem spravci kazde domeny kazde urovne jake jsou zebricky preferenci.

BINDu funguje tak, jak je nakonfigurovan (spravne je-li spravne, spatne je-li spatne). Je zajimave zjistit, ze mu vycitate jako chybu prave to, ze se nepokousi identifikovat chybne konfigurace (misto abyste ji vycital tomu, kdo jej chybne nakonfiguroval). U CZ.NIC pro zmenu povazujete za chybu, ze kontroly provadi a na svepravnost spravce se nespoleha (a vycitate mu, ze nedeleguje domenu bez ohledu na to, zda ten, kdo ji ma nakonfigurovat ji nakonfiguroval spravne). BIND je vadny protoze nekontroluje a dela co se po nem chce, CZ.NIC je spatny, protoze kontroluje misto toho aby proste delal to, cop se po nem chce. Musim, bohuzel, konstatovat jistou nekonzistenci ve vasich nazorech - skoro to vypada, ze vam nelze zavdecit. A chyba je vzdy "nekde jinde".

Nerad bych ale, abyste to chapal jako osobni utok - o to mi skutecne nejde. Jen mam dojem, ze na sve okoli kladete prilisne naroky, a navic zamenujete "odlisne" za "chybne".

Delici cara mezi "vlastnost" a "chyba" je obvykle subjektivni a ponekud nejasna. To, ze software poskytuje autoritativni odpoved tam, kde to jeho administrator naridi je vlastnost, kterou muzete vnimat jako chybu.

To, ze djbdns nedokaze (v pripade ztraty konektivity k rootu) poskytovat udaje ani o "vlastnich" domenach je take jeho vlastnost - a take muze byt povazovana za chybu (a nekdo to tady, tusim, udelal). Myslim, ze tu nekdo odpovidal, ze djbdns lze nakonfigurovat tak, aby tuto vlastnost/chyb - tim se jeho vlastnosti priblizi BINDu. Jenze on opravdu ziskal tu vlastnost BINDu kompletne - pri chybne konfiguraci zacne odpovidat autoritativne i na dotazy tykajici se domeny, pro kterou neni ve skutecnosti delegovan - takze ziska vlastnost i chybu BINDu.

A ted naopak - nic vam nebrani nainstalovat na dve IP dva BINDy, na jednom nenakonfigurovat zadne domeny a pouzivat ho jako cache, na druhem nadelegovat domeny a zakazat rekurzivni resei dotazu - a mate reseni, ktere ma vlastnosti djbdns - vcetne neschopnosti resolvit "vlastni" domeny pri ztrate vzdalene konektivity.

Pomoci obou programu muzete dosahnou obou typu chovani - u kazdeho jak s klady tak zapory pozadovane vlastnosti - jen "defaultni" chovani techto dvo baliku je proste jine - jednoho takove a druhe takove.

Opravdu nelze vinu svalovat na program. To, co je dokumentovano je vlastnost - ne chyba. A je chybou toho, kdo program pouziva, ze s jeho vlastnostmi neni dostatecne seznamen (a tedy je spravnou konfiguraci neodstranil, ackoliv to je mozne). Chyba neni ani to, kdyz se program nechova podle pozadavku toho, kdo ho pouziva - i to je chyba toho, kdo ma neadekvatni ocekavani.

Vas zaverecnu odstavec skutecne ukazuje, kde by mohl byt problem teto debaty - kdyz porovnavate dva systemy, ktere, navzdory tomu, ze slouzi k podobnym nebo stejnym ucelum maji ruzne vlastnosti a k dosazeni tech cilu pouzivaji ruzne cesty - nelze obvykle obecne rict, ktery system je lepsi a ktery horsi. A uz vubec nelze rict o tom, ktery se vam z vaseho hlediska zda byt horsi, ze je chybny. A to plati jak pro debaty Windows vs. UNIX, tak pro debaty BIND vs. djbdns. TO se ale teto debaty netyka - kdybyste rikal "djbdns" je lepsi nez BIND, je to vas nazor a je v poradku a skutecne neni o cem diskutovat. Vy ale rikate, ze BIND je vadny - a to je uplne jina kategorie tvrzeni. A my ostatni vam tvrdime, ze vadny neni - pokud je dobre nakonfigurovany. A to plati i pro djbdns, ktere take lze nakonfigurovat dobre i spatne. A za konfiguraci odpovida nejaky spravce. A proto je chybna funkce DNS chybou toho, kdo konfiguraci provedl a kdo ma sve praci (a softwaru, ktery pouziva) rozumet.

Omyl, to bychom pak taky mohli pozadovat jednu IP adresu pro SMTP a jednu IP adresu pro POP3.

DNS CACHE vzdy zaisti spravne odpovede podla delegacie od autoritativnych DNS SERVERov.

Tady uz jsme dokazali, ze to nemusi byt pravda. Zvlaste v pripade lokalni domeny, pro kterou nejsou obcas dosazitelne root servery.

BTW: lisi se nejak dotazy od klienta a od jineho DNS serveru? Pokud ne, tak proc oddelovat funkce?

Ano, klient pozaduje rekurzivnu odpoved, kdezto DNS CACHE ju tvori postupnymi dotazmi na DNS SERVER podla delegacie od root-u.
Doporucujem nahliadnut sem.

Vo Vasom texte je skryta odpoved preco ma zmysel rozdelit na dve IP adresy DNS SERVER a DNS CACHE.

DNS SERVER vzdy odpoveda, ked sa ho niekto pyta na domenu, pre ktoru je nastaveny ako autoritativny.

DNS CACHE vzdy zaisti spravne odpovede podla delegacie od autoritativnych DNS SERVERov.

Pokud si jeden server zakopu pod zem a druhy postavim na ulici, proc nemuzu na obou bezet BIND, pouze s jinym .conf :-) ? Ja vim, je to hrisna myslenka ... :-)

No myslim, ze i toto uz bylo zmineno. Autor se domniva, ze dns server ma dva rozdilne ukoly a nelze to sloucit na jednu IP.

Nelze je ponekud divne slovo v pripade, ze BIND to dela :-)

Ad zakaz prohledavani: takze vas system prohledavani od korene je nakonec preveden na prohledavani a'la BIND. Uzasne. Takze jsme se vlastne dostali do stavu, kde jsme byli na zacatku. Proste spatnou konfiguraci nezachrani ani sebegenialnejsi program.

Moc bych se ale nedivil, kdyby byla v BINDu moznost prevest standardni chovani na chovani a'la djbdns.

BTW: lisi se nejak dotazy od klienta a od jineho DNS serveru? Pokud ne, tak proc oddelovat funkce?

Já jsem si tu práci dal, dejte si ji prosím také. Vysvětlil jsem tu dvě poměrně běžné situace, ve kterých je to, co vy nazýváte by logicky dělat měl, krajně nelogické a nežádoucí. A pokud nějakému programu řeknu: "Poskytuj autoritativní odpovědi pro zónu xxx.cz", očekávám, že bude poskytovat autoritativní odpovědi pro zónu xxx.cz. Odpoví-li "Trhni si nohou, nejsem delegován jako nameserver", pak jednoduše nedělá, co jsem po něm chtěl. Až bude vybaven umělou inteligencí, můžeme to probrat u piva a třeba mne přesvědčí, že nemám pravdu. Do té doby ať laskavě poslouchá.

To jako musi mit DNS server 2 IP adresy? :-)

No myslim, ze i toto uz bylo zmineno. Autor se domniva, ze dns server ma dva rozdilne ukoly a nelze to sloucit na jednu IP.

Co treba v pripade nepristupnosti root serveru (vypadek uplinku k providerovi)? To se nedoptam ani na svou vlastni domenu?

Pokud chcete pro nejake domeny zakazat prohledavani od root serveru, mate moznost urcit, kterych serveru se na tuto domenu bude ptat. I toto jsem zde uz tusim psal.

To je prave ta myslienka pana Bernsteina. DNS server je jedna vec a DNS cache ina. Bind toto zlucuje do jedneho.
Priznam sa, ze sa mi na prvy pohlad tiez vobec nepacilo, ze musim mat dve oddelene IP adresy, ale ked sa nad tym lepsie zamyslim, tak to ma nieco do seba.
CACHE poskytuje sluzby klientom, kdezto DNS SERVER inym resolverom. Pochopitelne je asi omnoho dolezitejsie mat bezpecny DNS SERVER ako DNS CACHE (i ked najlepsie oboje). Takze DNS SERVER mozem poriadne vselijako zabezpecit (100 pod zem, 10 UPSok, 10 nezavyslich pripojeni do netu) a pre klientov postavim nejake PCko, ktore bude fungovat vtedy, ked ma pristup do netu a keby klaklo, tak sa zase tak vela nedeje, lebo mam pre klientov este jedno. Trochu som to samozrejme prehnal, ale chcel som ukazat, ze server a cache su ine sluzby a nie je az take nelogicke ich prevadzkovat oddelene.

Ako uz bolo povedane vyssie, djbdns narozdiel od bindu striktne rozdeluje sluzby cache a dns, teda na jednej IP adrese nebezia obidve sluzby.

To jako musi mit DNS server 2 IP adresy? :-)

Ja v podstate proti djbdns nic nemam, ale nevidim duvod, proc bych kvuli neoddeleni cache od dns musel zavrhovat BIND. Funguje tak jak funguje a myslim si, ze to neni spatne.

Co treba v pripade nepristupnosti root serveru (vypadek uplinku k providerovi)? To se nedoptam ani na svou vlastni domenu?

Ako uz bolo povedane vyssie, djbdns narozdiel od bindu striktne rozdeluje sluzby cache a dns, teda na jednej IP adrese nebezia obidve sluzby.

CACHE server pri resolvovani postupuje skutocne od root-servera dalej, teda ak pre nejaku domenu je nejaky server delegovany, tak sa obracia vzdy na neho, nezavisle na tom, ci na tom istom pocitaci (zamerne nepisem DNS), je nastavene, ze je autoritativnym DNS pre tu domenu.
Na druhej strane, nic nebrani tomu, aby som povolil cez TCP AXFR a tam si mozem nastvit, kto je opravneny stahovat zonu. Tento mechanizmus vyuziva hlavne BIND, autor djbdns to nedoporucuje.

Aby se predislo diskusiam na temu: co v pripade, ze chcem prevadzkovat lokalnu domenu "mylocalnet"? Samozrejme i toto je s djbdns mozne. Staci mu nastavit, ze root pre "mylocalnet" bezi na nejakej IP adrese a bude sa na nu pri resolvovani obracat..

Ne, to neni absurdni. Clovek si musi vybrat komu muze duverovat. Pokud duveruje nekomu spatnemu (spravce DNS ktery ma autoritativni zaznam, ackoliv neni delegovany nadrazenym DNS serverem), tak jeho mail nedojde, on si si neprohledne spravne webove stranky, atd.

To, ze DNS server bude kontrolovat, jestli opravdu spravce nekeca a pokud ano, tak proste odpovi po svem, povazuji za spatny napad. To je "inteligentni" software by MS.

Ostatne by mne zajimalo skutecne reseni, to co jste popsal neni skutecne reseni. Uvedu priklad:

Mam dva delegovane DNS servery, ktere jsou autoritativni, ale zaroven jsou oba dva sekundarni vuci jinemu skrytemu primarnimu DNS serveru (muze to mit nekolik duvodu, treba primarni DNS server nemusi byt vzdy dostupny, nebo jej mam ve sve sprave a DNS servery jsou u nejakeho DNS hostovace z duvodu dostupnosti). Primarni DNS server by pak nemohl fungovat, protoze neni delegovany z nadrazeneho DNS serveru. A pritom si myslim, ze toto je zcela validni konfigurace.

Ale ja vas pochopil, i kdyz jsem to umyslne trochu posunul. Omlouvam se pokud jste ten umysl nepochopil. Ten nazor vam neberu, ja se domnivam, ze je spise veci spravce serveru, aby mel system spravne nakonfigurovany. Neni to tak, ze by nevedel, ze tu domenu ma odstranit.

Ano, CZ-NIC zrejme proto, aby navenek prokazoval nejakou cinnost, zavedl toto opatreni <g>. Jinde toto nutne neni a funguje to. Ale o tomto se bavit nechcu, bylo by to mlacenim prazdne slamy.

Bind funguje tak, jak byl navrzen -- tudiz blbe, ale uz si na to vetsina kompetentnich zvykla, takze neni potreba menit.

Vy jste zda se necetl predchozi prispevky, dejte si prosim tu praci a prectete si o cem jsme se vlastne bavili.

Netvrdim, ze chyba je v tom, ze bind dela to, co spravce rekne (i kdyz podle mych zkusenosti to tak uplne pravda neni), ale je chyba v jeho navrhu, ze nedela to, co by logicky delat mel. Chapu, ze to vzhledem k jeho navrhu neni mozne resit lepe, existuje ale alternativni sw (djbdns), kde k takovymto problemum ani dojit nemuze.

Pred dalsi diskusi zvazte, zda by nebylo vhodne se prvni neco dozvedet, jak funguje djbdns. Mam z toho obcas takovy pocit, jako kdybych uzivatelum windows rikal, ze "jsem s windows taky pracoval, ale nyni pouzivam jiny system, ktery se mi zda lepsi" a oni na to sverepe stale to svoje: "ale vzdyt ja jsem s temi mymi okny spokojeny".

Absurdni je to, ze bych mel citit nejaky stupen odpovednosti za spatny/spatne nakonfigurovany sw na cizich serverech.

S Vasim prispevkem se neda nez souhlasit, ostatne myslim, ze jsem psal k tomuto totez.

To není zas tak radikální názor, platné právo ho v celé řadě případů sdílí a někdy jde dokonce ještě dál - činí člověka odpovědným i za následky, které ovlivnit nemohl. Ale to už je na jinou debatu. :-)

Kdyz uz jsme u filozofovani, muj nazor je jeste radikalnejsi ;-)

Clovek je odpovedny i za nasledky, ktere nezpusobi, pokud mel byt' tu minimalni moznost ovlivneni.

... zkratka a dobre ... Lidi proste nechteji byt zodpovedni za to, co sami vytvori. Chapal bych to u lidi u pasu, nechapu to u lidi, kteri nastavuji systemy.

Proste clovek by mel byt v kazdem okamziku zodpovedny za to, co udela/zpusobi.

Myslim, ze jste necetl pozorne. Ne, nejste odpovedny za to, ze nekdo jiny na celem Internetu nezridi zaznamy, ktere pak vasi domene cini problemy. Ale, jste-li technicky spravce, jste odpovedny za to, ze zkontrolujete, ze pri presouvani nameserveru na jina mista to na tech puvodnich skutecne zmizi. Protoze presunout nameservery znamena zrusit ty stare a zalozit nove (ne nutne v tomto poradi) - a jelikoz jste odpovedny za presun, jste odpovedny za obe dve tyto faze.

Myslim, ze prispevek dost jasne hovoril o tom, ze zaznamy zustaly na nameserveru, kde kdysi drive byly - a tak je zrejme, ze neresime pripad "nekdo zlomyslne zridil" - proti tomu byste se ohrazoval celkem patricne, ale pripad "nekdo zanedbal svoji povinnost odbornika" - a na tom trvam.

BIND funguje tak jak ma a nemuze fungovat jinak - kdyby odmitl obsluhovat domenu, ktera mu neni nadelegovana, pak by, uvazite-li, ze nadrazeny spravce nedeleguje domenu dokud pro ni neexistuje radne nakonfigurovany nameserver vznikl deadlock znamy pod oznacenim "byla driv slepice nebo vejce ?".

Podle meho nazoru, software, ktery nepracuje spravne v situaci, kdy je chybne nakonfigurovan, stale nemuze byt povazovan za chybny. A ani to, ze RFC nepopisuje spravne jak reagovat na situaci, ktera vubec nemela nastat (a jde o chybnou konfiguraci) nelze take bez dalsiho vykladat jako "chybu RFC". To, ze nameserver nakonfigurovany v rozporu s doporucenimi funguje v rozporu s doporucenimi (ale v souladu s konfiguraci) nenichyba ani toho software, ani tech doporuceni, ale toho, kdo tu konfiguraci udelal a za jeji spravnost odpovida. Chybna konfigurace je obvykle chybou cloveka (jak by rikate, hloupeho admina) a pokouset se ji svalovat na software nebo na doporuceni (RFC) je sice z psychologickeho hlediska pochopitelne, ale presto je to nespravne.

BIND se chová přesně tak, jak má. Když mu správce řekne, aby poskytoval autoritativní odpovědi pro zónu xxx.cz, tak je poskytuje. Nezjišťuje, jestli je skutečně primárním nameserverem příslušné domény. Už tady byl zmíněn problém s tím, že váš přístup by neumožnil zavést novou doménu. Jiný příklad: běžně používám pro lokální síť zóny typu neco.priv. To bych podle vás také nemohl - TLD priv přece neexistuje. Samozřejmě existuje i jiná filozofie k psaní programů: takovým programům můžete do zblbnutí opakovat, co mají dělat a ony si stejně udělají, co uznají za vhodné, protože vy tomu přece nerozumíte. Opravdu si myslíte si, že to je lepší?

Co je na tom absurdniho?

Kdyz pouzivam nejaky DNS server, ktery za mne resi dotazy, tak mu musim verit. Jinak to proste nejde. Nebo snad ano?

Pokud pouzivam podivny DNS server na reseni svych dotazu, tak je to muj problem.

Ano, jsem tim, kdo byl zodpovedny za to, ze "nikdo na celem internetu nezridi na svem DNS serveru zaznamy pro mnou spravovanou domenu a nezmate timto klienty pouzivajici jeho DNS server".

Nezda se Vam to absurdni ? Podle meho nazoru kdyz uz nekdo pouziva sw, ktery nepracuje spravne (jak jsem rekl, necetl jsem vsechny RFC, o ja hloupy admin), je jeho ukolem i opravovat chyby toho sw.


Takze, pri vsi ucte k Vam, s timto nemuzu souhlasit. Muzete tedy vyvratit to, ze bind v tomto nefunguje tak jak ma ?
Protoze pokud je toto chovani podle RFC, jsou ta RFC spatna a mela by se nahradit.

Chyba je IMHO jinde nez si vsichni myslite. A to primarne na strane
technickeho spravce dane domeny - kdyz domenu prevadel na jine
nameservery, je v zajmu jeho klienta (jemuz domenu spravuje) a tedy
jeho povinnosti zajistit vsechny souvisejici cinnosti - tedy i to,
ze na puvodnich nameserverech je zona zrusena. Fyzicky to samozrejme
musi udelat spravce onoho DNS, ale technicky spravce je ten, kdo
drziteli domeny zodpovida za to, ze se to stane - a pokud se se
spravcem daneho DNS nedokaze dohodnout, ze sveho klienta prinejmensim
upozorni. Hacek je v tom, ze technickeho spravce dneska dela kde-kdo
(proto je treba takovychto vzdelavacich clanku) a drzitele domen
berou kazdeho, kdo jim nabidne nizsi ceny - a po jeho znalostech,
schopnostech a spolehlivosti se neptaji a nezajima je. Pak
se ale nemohou divit, ze dotycny nedela to co ma poradne, pokud vubec
neco dela. (Nejste, doufam, tim technickym spravcem vy - i kdyz, to co
rikam bych zrejme rekl at je jim kdokoliv).

Kdysi jsem si vedl přehled RFC k DNS na http://www.ryston.cz/petr/dns.html , už delší dobu jsem ho ale neupdatoval.

Místo dalších verzí jsou ty stovky patchů na www.qmail.org, a to je právě to neštěstí. Navíc djb zákazem distribuce binárek znemožnil umístit qmail do distribucí, což poněkud ztěžuje jeho implementaci méně zručným administrátorům.
Teď chci přejít z RedHat 6.2 na 7.2 a asi budu muset qmail opustit, nemám dost času na to si s ním hrát.
Ta chyba nebyla přímo v qmailu, ale tuším v vpopmailu, už je to dlouho.

No nic, o djb by to mohla být dlouhá filozofická diskuse, jeho produkty jsou kontroverzní jako jejich autor, dal by se najít dlouhý seznam pro i proti, pro někoho převáží jedno, pro někoho druhé.

Ano, jde o nepochopení, jak jste asi předpokládal. Znám více serverů s djbdns, které úspěšně provozují české domény :)

Chtěl jsem tou poznámkou říct, že bind má nejen bezpečnostní díry (které se Vám zas tak strašné nezdají), ale podle mého i jeho fukčnost je pochybná. Djbdns je totiž na rozdíl od bindu rozdělený do dvou částí:

• dnscache - už z názvu patrné, že vyřizuje rekurzivní dotazy na cizí autoritativní servery. Postupuje při tom podle mého jediným možným správným způsobem tj. od root serverů až po servery nižších úrovní. Samozřejmě udělat výjimku a u některých domén toto chování změnit (nastavit IP serverů, kterých se bude ptát) - nebo jak jsem zmiňoval, je možné změnit i IP "root serverů".
• tinydns - autoritativní nameserver - vyřizuje pouze nerekurzivní dotazy na "svoje" záznamy - nezkoumá už tedy, jestli je pro tyto záznamy správně delegován, to je úkolem resolveru

Ano, DJB je kontroverzní osobnost, taky s některými věcmi nesouhlasím. Nemění to ale nic na tom, že jeho sw je bezpečnější tak nějak z principu. Tj. k některým implementačním chybám nemůže dojít kvůli bezpečnému návrhu.

qmail je více než tři roky "frozen" a obávám se, že další verze už asi nebude. Přesto je ale používán. Zvláštní že ?

RFC kolem DNS neznám. Vím ale, že DSN u qmailu není součástí žádného RFC, které by se DJB rozhodl implementovat. DSN je rozšíření SMTP, nepříliš šťastně navržené nutno říct.

btw: Které bezpečnostní díry jste měl na mysli konkrétně ?

Tak to pak na něm nejde zprovoznit dosud nedelegovaná zóna? To by ho pak nešlo použít na registraci domény pod TLD .cz, protože tam musí nejprve autoritativně odpovídat nameserver, a pak je teprve doména delegována. Nebo jsem to nepochopil?

Programy od djb jsou podle mě mnohem záludnější, protože autor bez ohledu na RFC co se mu nelíbí, neimplementuje (třeba TCP dotazy u dns, DSN u qmailu...), a pak existují tisíce patchů a doplňků (viz qmail), které nikdo nemůže ohlídat, jestli nemají díry. A taky občas mají.

djbdns vzdy zistuje ci je...

Velmi dlho som bind (ako asi vela inych) pouzival, az mi dosla trpezlivost a kazdu chvilu cakat, kedy sa najde dalsia diera. djbdns ma svojsku logiku (ako vsteky programy od jeho autora), ale po case a zvladnuti vsetkych potrebnych malickosti by som som uz bind nechcel...

V adminovi. Bind nemůže při každém dotazu zjišťovat, jestli je ještě pořád autoritativní od kořenových nameseverů. Na něco se spolehnout musí.

Anarchistické firmy ? Nerozumim.

Odpovím si sám: nešlo mi o ORSC - že tam figuruje tady to jsem zjistil až teď. Toto mi připadá fakt dost mimo.

Já bych ani neřekl, že to DJB zamýšlel na použití v reálu, ale je kdo ví ;-)

Anarchistické firmy ? Nerozumim.

Taky posloužím jedním příkladem neschopnosti:
kontaktoval nás admin jednoho lokálního ISP s tím, že si jeho zákazníci stěžují, že se nedostanou na jeden web (hostovaný na našem serveru) a ať si to opravíme, že už ho to pěkně štve....

Problém byl ale v tom, že daný ISP vlastní DNS server (který používali jeho zákazníci), kde vede záznamy pro tuto doménu jako autoritativní (skutečně tam byla ta doména dříve delegována, jak jsem se zpětně dozvěděl). Používaný sw (bind) ale při překladu nepostupoval od root serverů, ale poskytl svůj záznam (s vírou, že je autoritativní). Nevím, jestli toto chování bindu vydrželo do dneška, ale docela bych tomu věřil.

Takže kde je chyba ? V adminovi, který včas nezrušil záznamy ze svého named.conf, když se ta doména převáděla pryč nebo ve funkčnosti bindu ?

Ok, trochu jsem se unáhlil, ovšem to v tom odkazu jsou IMHO dost úchylné nápady. Přece jenom používat root zone nějaké anarchistické firmy není moc profi řešení. A provozu to moc neušetří a odezvy se taky moc v praxi nezkrátí, protože při použití normálních root dns se cachuje informace o nameserverech pro TLD 2 dny, djb doporučuje stahovat root zone kazdych 7 dní, to v praxi při tisícovkách dotazů denně nehraje roli.

Clanek byl IMHO urceny nizsim odbornym kadrum - pomerne mnoho spravcu DNS celou konfiguraci provedlo z nejakeho primitivniho examplu "how to easy set-up own domain" aniz by ve skutecnosti vedeli jak vlastne takove DNS funguje. Nemohu sice poslouzit zadnym konkretnim prikladem (prestoze, nebo mozna spise protoze jsem behem sve prace pro CZ.NIC mluvil s mnohymi), ale mohu poslouzit prikladem z jine oblasti. Pro jednoho zakaznika jsem kdysi resil jakysi problem s jeho spojenim a byl jsem nucen kontaktovat jeho "ISP". Problem se vyresil, ale otazku jejich technika si pamatuji dosud - znela "a jak se vlastne lisi to TCP od UDP ?".

Myslim, ze spravcu DNS, co o DNS vedi houby a nebo prinejmensim pomerne malo je ohromna spousta ...

Nechci se hadat o cislicka, ale logictejsi by bylo, kdyby domeny prvni urovne obsluhovali nameservery prvni urovne, nikoli druhe ...

A co se tyce onoho lokalniho seznamu - samozrejme, ze prestanete potrebovat root servery, kdyz si vytvorite vlastni, coz jste presne udelal. Nicmene, stejne nedosahujete totozneho vysledku - zatimco o obsahu root-serveru se jeste vseobecne predpoklada, ze musi (mel by byt) pravidelne aktualizovany, u jakehokoliv jineho seznamu (ze ktereho muzete mozna provadet aktualizace) to, za soucasne situace, jiste vubec neni. Takovy seznam aktualni byt muze, a take nemusi (protoze se nepocita s tim, ze na nem nekdo zavisi - ten seznam se publikuje "pro informaci").

Mozna bych si dovolil pripomenout, jak to chodilo pred zavedenim DNS. To se po siti na kazdy uzel distribuoval kompletni seznam jmen vsech pocitacu na celem svete (a byl jen jednourovnovy). Temto system se obesel nejen bez root nameserveru, ale bez nameseveru vubec. Pokud si dnes dokazete prislusne udaje shanet, pak si takovy seznam muzete vytvorit znovu (dnes uz viceurovnovy, ale to nevadi) a i dnes se muzete obejit nejen bez root serveru, ale bez nameserveru vubec. Verim, ze tento napad musi vsechny, co by se chteli bez root nameserveru obejit dokonale nadchnout ;-)

Nepotřebuji root servery, když mám ve svém lokálním resolveru seznam adres všech nameserverů druhé úrovně (pravidelně aktualizovaný samozřejmě). Tj. dotazy opravdu rekurzivně vyřizuje, jen přeskakuje ten první krok k root-serveru. Myslím ale, že toto bylo patrné už z toho uvedeného odkazu, takže mi není jasné, čemu nerozumíte. Nezakládám žádnou ligu proti root-serverům ;-) ... jen se kolega ptal, jak se obejít bez root-serverů.

Článek je pěkný, ale systém vyřizováni DNS požadavků je popsán dost špatně.
Ve skutečnosti je to takto:
Klient má nastavený dns server, kterého se ptá, buď je to lokální dns server, nebo dns server providera. To je v článku správně.
Tento dns server může být nastaven buď tak, že všechny dotazy forwarduje na nějaký jiný dns server a pouze cachuje odpovědi, nebo dotazy plnohodnotně řeší.
Pokud má plnohodnotně vyřešit dotaz, nejprve se zeptá kořenového (root) dns serveru (seznam root dns serverů se součástí konfigurace dns serveru). Ten ho odkáže na server, který je zodovědný za TLD (top level domain, doména prvního stupně), druhý dotaz směřuje tedy na TLD server. Ten, pokud je nerekurzivní (doporučeno) zase pošle odpověď, který dns server je odpovědný za doménu druhého stupně. Třetí dotaz tedy tedy směřuje na tento dns server, a zpravidla tento server již poskytne autoritativní odpověď.
Můj plnohodnotný dns server si pak už pamatuje (než záznam expiruje), který dns sever je zodpovědný za doménu první i druhé úrovně, a pokud se ho zeptám na další jméno spadající do stejné TLD, tak není třeba se znovu ptát root dns serveru. Pokud ale bude z jiné, nebo pokud je informace v mém serveru vyexpirovaná, posílá se další dotaz na root dns server.

Takhle to rozepisuji proto, aby bylo jasné, že to řešení vždy začíná přímým dotazem na kořenový (root) dns server, a probíhá shora dolů, nikoliv, jak je v článku uvedeno, že by se začínalo dotazem na server druhé úrovně, pak první a nakonec root. Systém je hierarchický, proto nemá smysl se ptát serveru zodpovědného za TLD CZ cz.eunet.cz na adresu z domény SK. A v případě, že se ptám na překlad doménového jména www.neexistujicidomena.cz, tak mi naopak odpověď serveru cz.eunet.cz, že doména neexistuje, musí stačit, a neptám se nikde jinde. Každý server má delegovánu svou odpovědnost, a systém je budován zvrchu od root dns. Žádný resolvující dns server se proto nebude ptát jinde.
Pokud tedy nemám v cache z dřívějšího dotazu IP adresu dns serveru zodpovědného za doménu .CZ, tak v případě výpadku kořenových dns serverů nemám žádnou možnost jak tento server nalézt.
Možná jsem to popsal trochu neohrabaně, ale doufám že správně.

ISP také nemají žádné servery druhé úrovně, jak je v článku uvedeno. (cz.eunet.cz a ostaní dns servery druhé úrovně jsou nerekurzivní a nedají (a nesmějí) se k plnému překladu použít).

Kořenový server žádné požadavky nikam nepřenáší.

"Cache tak funguje jako airbag pro kořenové servery, které jsou tak chráněny před případnými útoky."

Ne, to je vůbec neochrání, útoky přece vedou na server a ne na cache. Pouze se trochu zmírní dopad.

Závěr je myslím přehnaně optimistický. Jak je v článku uvedeno, výpadek 50% serverů by už způsobil komplikace. Dovedu si představi jak exploit, tak DOS (třeba DDOS) který by to mohl způsobit. Už v minulosti tu byl případ, kdy byla autorita kořenových serverů "ukradena" Alternicem. A myslím, že není důvod se domnívat, že se něco podobného nemůže opakovat. V každém programu je chyba.

Můžete upřesnit jak myslíte to, že nebudete vůbec potřebovat root DNS servery? Root DNS servery jsou základem funkčnosti DNS systému jako takového, a bez nich se, pokud se chcete někam na Internetu dostat, neobejdete.
Ledaže byste to myslel tak, že vůbec dns dotazy neřešíte, ale přeposíláte na nějaký skutečný dns server, který ale ty root dns servery potřebuje.

K té ementálovitosti - z přehledu ISC vyplývá, že to není až tak strašné, problém je především na straně líných správců.
Root servery používají různé verze, 8.2.3, 8.2.4, 8.2.5, 8.3.0, 8.3.1 a pak nějaké VRGS1 a VRSN1, což by taky mělo trochu snížit pravděpodobnost zasažení všech serverů najednou.

Suhlas, slusny clanok.

Na druhej strane ma napada otazka: Komu bol urceny?

Predpokladam, ze kazdy (poriadny) spravca name servera vacsinu z toho ovlada, takze sa skoro nic noveho nedozvie.
Mozno bolo cielom vzdelat verejnost. Co by bolo mozno zaujimave, je konkretizovat informacie o tom ake UNIXy a zelezo sa pouziva. To v ziadnej prirucke ani v RFC asi nebude. Je fakt, ze je to okrajova informacia.

Robert

Ackoliv se domnivam, ze zmineny problem mezi narodnimi spravci a ICANN neni jediny a snad dokonce ani hlavni, na takovy clanek reaguji pochvalnym mrucenim. A primlouval bych se za vznik dalsich clanku, ktere by v ucelene sade objasnovaly dostatecne princip fungovani DNS (aby i pan vyse v diskusich dokazal sam vymyslet, co ma udelat, aby mu to fungovalo).

Spor o zaruky za fungovani sluzeb mezi spravci a ICANN je, dle meho nazoru, jen jednim z delsiho seznamu sporu. ICANN uzavrel urcite smlouvy s americkou vladou, ktera ma dopady na jeho provoz a na spravu domeny nulte urovne - a mnoho spravcu se domniva, ze nemel mandat k takovemu jednani a k uzavreni takove dohody. Jednim z nasledku je napriklad zmena praxe pri delegacich a redelegacich domen, kdy ICANN vyzaduje vyjadreni lokalni vlady (drive se k nemu prihlizelo, pokud vlada projevila nejaky nazor, ale pokud ho neprojevila, nebylo to prekazkou), zatimco urcity okruh spravcu narodnich domen se domniva, ze ICANN nema mandat k "povinnemu" zatahovani vlad do zalezitosti spravy narodni domeny. Dalsi spor spociva i v tom, ze v rozhodujicich strukturach ICANN nejsou rovnopravne zastoupeni spravci vsech domen, coz se, pochopitelne, nekterym spravcum take nelibi.