Názory k článku PowerDNS: server odolný proti spoofingu

Uprimne receno, duvody DJB jsou pro me neprilis pochopitelne. Casto mam dojem, ze nektere veci dela jen proto, aby ukazal, ze to "jde jinak".

Co se tyce bezpecnosti, obavam se, ze pri nasazeni vicero systemu bezpecnost nijak nezvysim (ba prave naopak).

Ano, snadna administrace zaznamu je duvod, kteremu rozumim. Ovsem nikoliv snadna administrace systemu - vic systemu vice prace. Takze rozumim tomu, ze si pri pouziti nejake databaze na backendu administratori usetri trosku nevabne prace (vyplnovani textovych souboru), nicmene za to ziskaji vice (ale zajimave a "hraci") prace pri nastavovani a udrzbe systemu.

Nic proti qmailu, sam jej pouzivam (s ruznymi patchi, napr. s temi z qmailrocks.org). Ale neco hledat v log souboru qmailu je na Chocholouska. Takze planuju prechod na Postfix.
ast

Jak bylo řečeno, zóny se automaticky replikují prostřednictvím db backendu, což je např. pro MySQL backend preferovaný způsob. Navíc lze využít možnosti backendu a jednodušše pro replikaci použít šifrovaný kanál nebo složitější replikační schéma.

Výkon je zcela zřejmě omezen oproti jiným DNS (nsd, bind) z důvodu použití ruzných backendů - je to daň za flexibilitu, kterou PowerDNS nabízí (by design).

Je proto asi nesmysl nasazovat PowerDNS na root nameservery, případně na nameservery s 50 000+ zóny nebo 10 000+ q/s. Jestli je cokoli ostatní pro vás pidifirma, budiž (za zmínku stojí pár toplevel registrátorů, register.com, tucows.com).

Nejsem si vubec jist, zda reseni, kdy misto dvou systemu provozujete ctyri a misto jednoho replikacniho mechanismu dva (a za to dostanete nasobne mensi vykon), se da nazvat chytrym.

Asi pro to bude nějaký důvod, nebo si myslíte, že si to jen chteli udělat složitější? Proč se vůbec používají relační databáze nebo LDAP?

Vás prostě zajimá především výkon, jiné flexibilita, bezpečnost a snadná administrace. V každém případě může být chytřejší něco jiného.

Existuje DNScache od D.J. Bersteina, ktera se jmenuje prekvapive dnscache. Tato dnscache je take odolna proti spoofingu.
Tato cache se pta na informace pouze DNS serveru, ktery prislusi k dane domene a nebere ohled na "bonusove odpovedi" zadneho DNS serveru.
Take bych doporucoval DNS cache mit na jinem serveru, nez DNS server a teto DNS cache nedavat verejnou IP adresu.

Kvizovy dotaz 2:
K cemu by bylo dobre vybrat si ze stejne funkcnich a bezpecnych programu zrovna ten svobodny?

Odpoved na kviz 1:
Treba proto, ze mi poskytuje zaruku bezpecnosti programu:

http://cr.yp.to/djbdns/guarantee.html
The djbdns security guarantee
I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns.

A aby mohl garantovat, tak samozrejme musi zprisnit podminky sireni. Nemuzes ocekavat, ze budes mit stejne svobody jako u programu sirenych -- "AS IS" WITHOUT WARRANTY OF ANY KIND --.

No, do jiste miry to svobodny software je - muzes ho svobodne pouzivat, modifikovat i distribuovat. Akorat distribuovat musis pouze originalni verzi a binarku musis distribuovat ve strukture, kterou by to vytvorilo pri defaultni konfiguraci.

Tady bych polozil kvizovy dotaz 3:
Proc tedy tolik lidi dela mega patchu a pouzivaji qmail, kdyz je to takovej shit:) Vzdyt by prece bylo jednodussi pouzit nejaky jiny SVOBODNY smtp server, ktery uz treba vetsinu funkci ma, ne?

A mluvil jsem o djbdns - ne o qmailu. Ale kdyz jsi o tom zacal, tak si precti http://cr.yp.to/qmail/guarantee.html "The qmail security guarantee"

---
In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account.

My offer still stands. Nobody has found any security holes in qmail.
---

Takze bud si muzes pouzit jakykoliv svobodny software zadarmo a sirit ho jak chces, pripadne muzes pouzit i qmail a mega patchu, az ti ale nekdo naboura server a smazne data/emaily uzivatelu a budes z toho mit problemy, pak muzes maximalne ohlasit bug vyvojarum.

U produktu DJB si muzes byt relativne dost jisty, ze v originalnim kodu neni chyba.

Priznavam, svobodne programy maji dost casto vice vlastnosti, ale DJB slo hlavne o bezpecnost a na to bych se spolehnul. Taky nepouzivam qmail, ale postfix, ale treba daemontools se mi libi a djbdns-dnscache a tinydns- pouzivam, protoze je o dost jednodussi nez bind nebo pdns a rekl bych, ze i konfigurace je o neco prijemnejsi, kdyz si clovek zvykne. Pravdepodobne to bude platit i o qmail:)

cili 64-bitovou architekturu, pro kterou ten program neni urcen ? :)

Nesvoboda produktu DJB neni zadnou nesvobodou. Pokud se nepletu, smite volne upravovat co chcete, pouze se to uz nesmi jmenovat qmail a nemelo by to s nim byt nijak spojovano. (ted ale trosicku varim z vody)
SW od DJB je pro me to nejlepsi reseni. Mail server, DNS...v okamziku kdy si clovek zvykne na slozitejsi strukturu, okamzite zacne chapat proc je tak slozita:) Navic bych rad dodal, ze srovnavat dnscache s BINDem je skutecne nevhodne. BIND je zlo na koleckach a kd onekdy sledoval historicky vyvoj chyb apod. musi mi dat za pravdu. Ale to je muj nazor a vy samozrejme muzete mit jiny ;)

Dokazes nejak podlozit to tvrzeni o licenci? Pri vsi snaze jsem zadnou licenci u qmailu ani u djbdns nenasel.

Bezpecnost bych moc nerozmazaval, nebezpecne jde provozovat cokoli a bezpecne skoro vsechno taky. V poslednich letech ubylo der dokonce i v sendmailu.
A nebudeme se doufam hadat o nepouzivane funkce jako treba ipv6 a dnssec.

Kvizovy dotaz:
K cemu by bylo dobre vybrat si ze stejne funkcnich a bezpecnych programu zrovna ten nesvobodny?

Třeba protože jeho vývoj (nebo spíše nevývoj u djbdns) bude s menší pravděpodobností ovlivněn vrtochy D. J. Bernsteina. Navíc to "stejně funkční" nemohlo být v Kvizovém dotazu č. 1 myšleno vůbec vážně :-)

Sorry za zpozdeni s odpovedi.
Klienti nemaji na cache co delat. Klienti pristupuji k DNS serveru bez cache a az tento server se pta dnscache (coz neni problem).
DNS server ma samozrejme verejnou IP adresu.

A co když shoří procesor nebo disk? ;-) Výhodou je, že s tímhle DNS serverem máte na výběr, používejte jakýkoliv backend s vyhovujícím poměrem spolehlivost/rychlost/snadnost změn.