Dotaz: Jaký rekurzivní/cache DNS server?

[Petr Tomášek]

Zdravím!

Hledám náhradu za dnsmasq pro domácí síť. Moje požadavky:

• Cachující nameserver, obsluhují lokální LAN.
• Možnost nadefinovat hosty pro lokální síť (dnsmasq to má tak, že si je sosá přímo z /etc/hosts)
• Podpora DNSSEC.
• Možnost „přebít“ některé hosty (a nejlépe i domény) vlastním záznamem (typicky: blokování Facebooku a podobných bezpečnostních děr).
• Dostupné v ofic. repozitářích Debianu 7.

K BINDu nemám příliš důvěry (ani nevím, jestli umožňuje vše, co jsem výše napsal). Doporučíte nějaký moderní nameserver? Díky

---

---

Odpovědi

[Milan Roubal]

mozna pomuze tento clanek

[Filip Jirsák]

Unbound, nebo si počkejte na KnotDNS Resolver.

Nevím, jak moc bude podporováno přebití některých hostů nebo domén, zvlášť u serverů podporujících DNSSEC – protože klient validující DNSSEC pozná, že jste záznam zfalšoval. Navíc osobně si myslím, že DNS není vhodné místo, kde tohle řešit.

[Petr Tomášek]

Nevím, jak moc bude podporováno přebití některých hostů nebo domén, zvlášť u serverů podporujících DNSSEC – protože klient validující DNSSEC pozná, že jste záznam zfalšoval.

Vzhledem k tomu, že mým cílem je blokovat, tak je mi jedno, jestli se mi podaří docílit podstrčení adresy 0.0.0.0, nebo jestli to vrátní chybu "NO-HOST"...

Navíc osobně si myslím, že DNS není vhodné místo, kde tohle řešit.

Proč by nebylo?

[Filip Jirsák]

Vašim cílem to je. Ale cílem DNSSEC validujícího resolveru je poskytovat validní odpovědi... Je tedy otázka, zda na tuhle schizofrenii přistoupí autoři toho kterého serveru.

Vodné místo to není proto, že tím přístupu k daným službám nezabráníte, pouze si uživatel bude muset IP adresu zjistit jinak. Nastaví si jiný DNS server, zadá si adresy do hosts, použije proxy server, bude používat IP adresu...

[Petr Tomášek]

Vašim cílem to je. Ale cílem DNSSEC validujícího resolveru je poskytovat validní odpovědi... Je tedy otázka, zda na tuhle schizofrenii přistoupí autoři toho kterého serveru.

A to se vylučuje? (Navíc, cílem DNS resolveru je poskytovat to, co si jeho administrátor přeje. BTW, i Unbound má volbu „domain-insecure“...)

Vhodné místo to není proto, že tím přístupu k daným službám nezabráníte, pouze si uživatel bude muset IP adresu zjistit jinak. Nastaví si jiný DNS server, zadá si adresy do hosts, použije proxy server, bude používat IP adresu...

No, např. použití proxy serveru asi těžko zabráníte (když je uživatel tak blbý, tak ať ). Ale nevidím důvod, proč vedle např. blokování AS Facebooku(*) zároveň neblokovat taky DNS (pro případ, že by mi něco uniklo )...

(*)Něco jako:

#!/bin/bash

FBFW=/etc/firewall/block-facebook.sh
/usr/bin/whois -h whois.radb.net '!gAS32934' |
                /usr/bin/head -n -1 |
                /usr/bin/tail -n -1 |
                /usr/bin/xargs --max-args=1 |
                /bin/grep "^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]\/[0-9]*$" |
                /usr/bin/xargs -I {} --max-args=1 echo /sbin/iptables -t mangle -I POSTROUTING -d {} -j DROP \
                                > $FBFW.new

if [ -s $FBFW.new ]
then
        /bin/chmod +x $FBFW.new
        /bin/mv -f $FBFW.new $FBFW
else
        /bin/echo "Cannot generate rules for $FBFW!" 1>&2
fi

[Filip Jirsák]

Ano, vylučuje se to. DNSSEC slouží k tomu, aby nikdo nemohl manipulovat s DNS odpověďmi. A to přesně vy byste od serveru chtěl. Server by tedy měl manipulacím bránit, a zároveň je umožňovat.

[Petr Tomášek]

To je pěkná blbost . Pokud chci blokovat určité DNS dotazy, tak to rozhodně nelze brát jako manipulace, prostě proto, že se tím nic nepodvrhuje. Jenom zabraňuje tomu, aby šla určitá doména/host resolvnout.

Navíc, jak už jsem psal, server by měl umožňovat to, co chce jeho administrátor. Nevidím důvod, proč by server neměl umožňovat „manipulace“, když si to administrátor přeje...

[Filip Jirsák]

Blokování dotazů je manipulace. DNSSEC samozřejmě brání i proti takovémuto typu manipulací, takže i odpověď o neexistenci doménového jména je podepsaná.

[Petr Tomášek]

No a?

[pavlix]

Validující resolver se technicky s blokováním určitých DNS jmen nevylučuje a současná praxe je taková, že manipulace je jednou ze základních funkcí resolvujících nameserverů. Na druhou stranu bych se osobně na blokování konkrétních DNS vykašlal, nevidím k tomu rozumný důvod.

[Filip Jirsák]

Technicky se to nevylučuje. Ale validace slouží mimo jiné k odhalení takového blokování. Takže je otázka, zda někdo chce klienty bránit před manipulací s DNS záznamy a zároveň s nimi sám manipulovat. Jistě, může si dotyčný myslet, že on je ten hodný manipulátor a ostatní jsou ti zlí, ale DNSSEC neumí mezi hodnými a zlými manipulátory rozlišovat.

[Petr Tomášek]

Takže je otázka, zda někdo chce klienty bránit před manipulací s DNS záznamy a zároveň s nimi sám manipulovat.

Ano, to přesně chci a není na tom nic špatného . Jste moc zaslepenou to Vaší ideologií...

[j]

Japa by to moh poznat, kdyz se k jinemu nez memu DNS nedostane?

[Filip Jirsák]

Nebude sedět podpis s veřejným klíčem v nadřazené zóně. A pokud by zfalšoval vše až ke kořenové zóně, nebude sedět podpis kořenové zóny s veřejně známým klíčem kořenové zóny, který má uložen každý validující DNSSEC resolver.

[NN]

Bind, NSD. Knot neni v repozitari vyber si.. Btw. z ceho prameni ta neduverak Bind, spatna zkusenost?

[Petr Tomášek]

Asi to, že je to na můj vkus moc starý SW, který se začal vyvíjet ještě v době, kdy se to „s tou bezpečností“ až zas tak „vážně nebralo“.

[ET]

hehe a jak je na tom (podle Vaseho nazoru) linux (kernel)?

[j]

A proto ho pouziva 60+% DNS po netu?

[Petr Tomášek]

No a?

[pet]

pdnsd ?

[Petr Tomášek]

Tam nevidím podporu pro DNSSEC (tj. podporu pro validaci, žejo...).

[BigWrigley]

Určitě Unbound.

[Petr Tomášek]

Proč „určitě“? Argumenty si velmi rád poslechnu...

[Sten]

bind-dyndb-ldap

[Petr Tomášek]

A co to má společného s mým dotazem?

[Sten]

Splňuje to požadavky

[Petr Tomášek]

1) tohle je přece backend pro BIND, 2) opravdu nevím, proč bych měl ještě instalovat LDAP. Celá ta vaše odpověď je poněkud neplausibilní...

[BigWrigley]

Nevim, jak pro domaci nasazeni. Ale mohu doporucit unbound, jak jiz zde bylo zmineno. Zkouseli jsme i PowerDNS, ma nektere zajimave vlastnosti (paketova cache), ale spatne odolava specifickym utokum, resp. odolaval. Presli jsme na unbound:

• podpoda DNSSEC vcetne Lookaside validation
• podpora DNS-0x20 draftu
• robustnost
• dobra konfigurovatelnost
• ovladatenost (moznost doptat se na probihajici se dotazy, statistiky a pod)
• lokalni zony
• aktivni vyvoj

Intalace na 1 stroji s 16 jadry ma pri cca 2.000 req/s zatez CPU asi 10% a to vetsinou na softirq. Neni problem ustat zatez radu desitek tisic req/s, obykle se zacnou varit prvky okolo. Bez problemu je to pouzitelne pro ISP.

[d.c.]

Ja sice obvykle pouzivam BIND (v 8. a hlavne v 9. byl prepsany, takze argument o prilis starem designu je trochu mimo misu) a od te doby, co ISC upustilo od projektu BIND10, se uz ani tolik nebojim, ale tu a tam zkusim neco jineho. Unbound zkousim v posledni a prvni dojmy jsou velmi dobre, coz se mi u jinych projektu nestalo. Je tam nekolik veci snad az prilis "samo od sebe" (obvykle vyzadovane zony), ale asi to je pro vetsinu lidi vyhoda. Takze se pripojuji k doporuceni.

[Petr Tomášek]

OK, tak jsem nainstaloval Unbound a vypadá to hezky, až přítulně . Lokální zóna i blokování Facebooku funguje OK. Akorát přemýšlím, jestli ho mám nechat jako čistě rekurzivní DNS, nebo se napíchnout na nějaký "otevřený" DNS (DNS od providera je nepoužitelný, ale zase jediný, co znám jsou 8.8.8.8 a 8.8.4.4 - ale cpát gůglovi do chřtánu domény, který rezolvuju se mi opravdu nechce.) Takže asi nechám jenom čistě rekurzivní, i když to napoprvé chvíli trvá, než to probublá...

[BigWrigley]

Asi bych to nedelal a nechal unbond v ciste rekursivnim modu. Pokud to mate na stroji, ktery je trvale zapnuty, brzo se cache naplni a bude to rychle. Oprit jej o nejaky jiny resolver by melo smysl, pokud by byl takovy dobre dostupny a s minimalni latenci. Navic si myslim, ze takove otevrene resolvery mohou byt casto pod utokem ruznych botnetu (amplification attack) a kdo vi, jake pak budou odezvy.

[d.c.]

Ja se tez domnivam, ze resolver ma bezet co nejblize pouziti, tedy forwardovat pouze v pripade, ze to jinak nejde (pitoma politika ISP apod.).

[pavlix]

Důvod?

[pavlix]

Otevřeným bych se teda taky vyhnul, ale pokud by byl slušný u providera, tak nevidím důvod ho nepoužít.

[Petr Tomášek]

Což v mém případě není :-/

[pavlix]

Sám jsem v tom případě používal plnou rekurzi aniž bych nad tím nějak zvlášť uvažoval.

[Petr Tomášek]

Jj, po cca 1.5 dni testování zjišťuji, že sice gůglí servery jsou při prvním přístupu o kapičku rychlejší, ale celkově se to všechno zdá přijatelně svižné. (Navíc stejně nakonec ty další přístupy budou o latenci linky - v tomto případě DSL - vždycky rychlejší...)

[BigWrigley]

Zkuste Namebench Hezky nastroj na testovani vykonu DNS. Google nam vychazel take o malicko rychlejsi. IMHO je to kvuli tomu, ze Google ma asi kvalitnejsi zahranicni konektivitu (s mensi latenci) a proto vychazel lepe pro zahr. sajty.

[d.c.]

1. Validace.

2. Nedostatek vyhod pro pouziti forwarderu.

3. Rad se vyhnu hledani zbytecnych chyb, ktere zpusobuji manipulace s DNS u provideru. Uz jsem to musel absolvovat nekolikrat a je to IMHO cas (a prace) vyhozeny z okna.

[pavlix]

Možná jsem trochu deformovaný tím, že se s ISP znám osobně :).

[bigBRAMBOR]

Taky se s nasim ISP znam osobne a stejne bych jeho DNS nepouzil.

[d.c.]

Ja mam tedy vice ISP, a zrovna ten, co ho znam osobne to prekrucuje nejvic.

[pavlix]

Unbound. Osobně pracuju na integraci unboundu, dnssec-triggeru a NetworkManageru, používám denně.