djbdns vs bind [zamknięte]

Jestem nowicjuszem, który chce nauczyć się konfigurować serwer nazw DNS. Czy powinienem używać djbdns, BIND, czy czegoś innego?

Obecne wymagania sieciowe obejmują obsługę subdomen, SSL i obsługę poczty, a wszystko to przy bardzo małym ruchu. Chciałbym rozwiązania, które pewnego dnia może skalować się do większego ruchu i być może trudniejszych wymagań (takich jak równoważenie obciążenia). W tej chwili działałbym albo na Linuksie.

Czytałem, że BIND ma problemy z bezpieczeństwem, jeśli nie jest odpowiednio skonfigurowany i że jego konfiguracja może być trudna. Przeczytałem również, że djbdns jest łatwiejszy do skonfigurowania, bardziej bezpieczny i równy dużym obciążeniom. Argumenty przemawiające za djbdns wydają się wiarygodne, ale nie mam specjalistycznej wiedzy, aby je właściwie ocenić. Jeśli BIND jest lepszy, byłbym wdzięczny za omówienie tych roszczeń do djbdns.

Dzięki.

W przeszłości pracowałem z djbdns i obecnie prowadzę kilka serwerów BIND.

Największym problemem związanym z djbdns jest najlepszy sposób, w jaki nauczyciel pierwszej klasy umieścił to na mojej karcie raportu: „nie gra dobrze z innymi”. Po prostu nie zachowuje się jak nic innego na unixowym pudełku na wiele bardzo małych sposobów, które mogą cię ugryźć później. Używa składni dla plików strefy, których nigdzie indziej nie zobaczysz.

Największą zaletą djbdns jest to, że został zaprojektowany od podstaw z bezpieczeństwem jako celem nr 1.

Jeśli zamierzasz skonfigurować serwer DNS, udostępnić go w Internecie, a następnie nigdy nie utrzymywać, djbdns będzie dobrym rozwiązaniem.

W prawdziwym świecie lepszym rozwiązaniem dla większości administratorów jest używanie pakietów BIND od dostawcy systemu operacyjnego i łatanie go natychmiast po aktualizacji. Ale uruchomienie go w trybie chroot jest dobrym pomysłem, a trzymanie autorytatywnych serwerów DNS oddzielnie od rekurencyjnych serwerów DNS resolvera jest dobrym pomysłem.

Jeśli znajdziesz dokumenty dotyczące czegoś z DNS, BIND zostanie dołączony, a djbdns raczej nie zostanie dołączony. Jeśli użyjesz dig, zwracany format można wkleić do pliku strefy BIND i pracować. Działa jak każdy normalny demon unix zamiast czegoś z innej planety.

Używamy sprzętu do równoważenia obciążenia i równoważenia obciążenia nasze rekurencyjne serwery resolvera BIND; działa świetnie. Upewnij się tylko, że użytkownicy otrzymują ten sam źródłowy adres IP, z którego wysyłali swoje żądania, a wszelkie ustawienia równoważenia obciążenia UDP i TCP powinny działać. Jeśli wykonujesz autorytatywny DNS, równoważenie obciążenia jest tak proste, jak posiadanie więcej niż jednego serwera i publikowanie ich wszystkich w informacji whois; pozostałe serwery DNS będą ładowały się inteligentnie.

Aby uzyskać autorytatywną usługę, nsd .

Dla rekurencyjnego, bez zobowiązań .

Oba są małe (więc prawdopodobnie mają mniej dziur w zabezpieczeniach, które czekają na odkrycie), aktywnie utrzymują i obsługują wszystkie najnowsze rzeczy DNS (DNSSEC, IPv6 itp.).

W przeciwnym razie BIND jest dobrym oprogramowaniem.

djbdns to projekt jednoosobowy, przez długi czas nieobsługiwany, nie bardziej bezpieczny (autor tak twierdzi), a oficjalna strona internetowa jest pełna błędów. (Teraz jestem pewien, że dostanę dużo ocen negatywnych od djbboys, mój przedstawiciel był zbyt wysoki jak na mój gust :-)

Jeśli to dla ciebie, a jeśli chcesz dowiedzieć się, jak działa DNS, skorzystałbym z djbdns.

Jeśli chcesz zrozumieć, jak wszyscy inni robią DNS i jak obsługiwać typowe wdrożenia korporacyjne, naucz się wiązania.

Jeśli Twoim celem jest minimalny wysiłek i wsparcie, a jesteś w miarę kompetentny, djbdns ma znacznie niższe koszty wsparcia.

Jeśli jesteś bardziej po stronie ogrodzenia dla początkujących, prawdopodobnie łatwiej będzie ci się związać i uruchomić, ale pamiętaj, że znacznie bardziej prawdopodobne jest wybuchnięcie w dziwny i zwariowany sposób.

Gdybym jeszcze nie znał djbdns (i bind), zajrzałbym również do powerdns i maradns, ale wątpię, aby w przypadku małych instalacji był lepszy niż pakiet djbdns.

Niezależnie od tego, nawet jeśli używasz bind do reklamowania swojego DNS w Internecie, nadal powinieneś uruchomić dnscache (część pakietu djbdns) działający na localhost dla twojego resolvera twojego systemu.

Pomiń djbdns. Chociaż djb jest bohaterem, przenosi arogancję matematyka do oprogramowania. Fakt, że nie zachowuje się jak inne oprogramowanie w odniesieniu do uruchamiania / zatrzymywania, może być dobrym przykładem sprytnej techniki zarządzania demonami. Ale będziesz musiał wyciągnąć dokumentację, jeśli nie będziesz jej używać regularnie, ponieważ wszystko jest tak różne. Jeśli skonfigurujesz go również w systemach, które utrzymują inni, musisz napisać im przejrzystą dokumentację - którą będą musieli przeczytać w całości, aby wykonać proste operacje. Uruchamianie rzeczy z init jest słodkie, a nawet sprytne. Ale jest też okropny, zaskakujący i niestandardowy.

Ponadto miałem problemy z djbdns powodujące poważne problemy z powodu nalegania na przestrzeganie tylko standardów, a nie interoperacyjności oprogramowania. Rozwiązywanie tych problemów było dużą stratą czasu, ponieważ zależało od niewielkich różnic w pakietach DNS.

Również djbdns zachowuje się dziwnie w niektórych przypadkach, co powoduje, że ludzie rozwiązujący problemy z serwerem DNS za pomocą narzędzi innych niż djb (np. Z nslookup) uzyskują zaskakujące wyniki. Będziesz tracić czas na wyjaśnianie „właściwie, po prostu używam tego niejasnego serwera DNS o nazwie djbdns. Problem polega na tym, że twoje narzędzia diagnostyczne dają dziwny komunikat, ale działa OK. Jeśli spojrzysz na przechwytywanie pakietów, możesz powiedzieć Nie ma to związku z problemem, który mieliśmy kilka miesięcy temu, gdy djbdns nie współpracował poprawnie z twoim serwerem DNS. Nie jest to również związane z problemem, który mieliśmy kilka tygodni temu, kiedy byłem poza biurem i zajęło mi to członków drużyny na godzinę, aby zrestartować serwer DNS. ”

Podobne problemy z qmailem dookoła.

Konfiguracja djbdns ma pewną wartość edukacyjną, jeśli zadajesz pytanie i masz czas na zabicie. Możesz się także wiele nauczyć, czytając stronę internetową djb.

Istnieją dwa zestawy problemów bezpieczeństwa. Luki bezpieczeństwa, które umożliwiają atakującemu dostęp do systemu - djbdns prawie na pewno nie ma żadnego z nich. Kilka lat temu bind odkrył kilka zawstydzających w krótkim czasie, ujawniając również zły projekt. Spodziewałbym się, że przez te wszystkie lata został on całkowicie przepisany. Jeśli naprawdę chcesz być pod tym względem bezpieczny, uruchom go pod maszyną wirtualną (np. Xen). Weź również pod uwagę, jeśli pracujesz w systemie Linux z SELinux w trybie ukierunkowanym, będziesz mieć konfigurację dla binda i prawdopodobnie nie będzie kłopotać się z jedną dla djbdns. System bind + SELinux jest potencjalnie bardziej bezpieczny.

Innym problemem jest ochrona przed zatruciem pamięci podręcznej. Domyślam się, że djbdns był lepszy, kiedy został wydany, a bindowanie jest prawdopodobnie teraz lepsze ze względu na większą uwagę. Prawdopodobnie jest to przyczyną twojego słuchu, że wiązanie jest niepewne, chyba że „odpowiednio skonfigurowane”. Powinieneś przynajmniej zbadać i zrozumieć ten problem. W trakcie tego procesu prawdopodobnie dowiesz się, jakie ryzyko konfiguracji istnieje dla obu serwerów DNS.

Zachowanie pod dużym obciążeniem jest nonsensownym kryterium dla większości użytkowników. Uważaj na wydajność wykorzystywaną jako kryterium oceny oprogramowania, które rzadko stanowi wąskie gardło wydajności. Nie hostujesz buforującego serwera DNS dla ogromnej bazy użytkowników, gdzie możesz otrzymywać żądania ze znaczną szybkością. Korzystasz z autorytatywnego systemu DNS, aby świadczyć usługi, które prawdopodobnie działają w tym samym systemie. Usługi te są tysiące razy droższe niż DNS. Twój link internetowy może nawet nie wystarczyć do dużego obciążenia serwera DNS, ale jeśli otrzymujesz tak duże obciążenie na świadczonych przez ciebie usługach, DNS nie będzie prawdopodobnie wąskim gardłem.

Możesz rzucić okiem na MaraDNS , bezpieczny serwer DNS.

• Bezpieczne. MaraDNS ma historię zabezpieczeń tak dobrą lub lepszą niż jakikolwiek inny serwer DNS. Na przykład MaraDNS zawsze losowo, używając bezpiecznego generatora liczb losowych, identyfikatora zapytania i portu źródłowego zapytań DNS; i nigdy nie był podatny na „nowy” atak zatrucia pamięci podręcznej.

• Utrzymany. MaraDNS ma długą historię utrzymywania i aktualizacji. MaraDNS został pierwotnie stworzony w 2001 roku. MaraDNS 1.0 został wydany w 2002 roku, a MaraDNS 1.2 został wydany w grudniu 2005 roku. MaraDNS został gruntownie przetestowany, zarówno z wykorzystaniem procesu SQA, jak i ponad czterech lat użytkowania w świecie rzeczywistym. MaraDNS jest nadal w pełni obsługiwany: najnowsza wersja została opublikowana 13 lutego 2009 r. Deadwood, kod, który stanie się częścią MaraDNS 2.0, jest aktywnie rozwijany.

• Łatwy w użyciu. Podstawowa konfiguracja rekurencyjna wymaga tylko jednego trzyliniowego pliku konfiguracyjnego. Podstawowa autorytatywna konfiguracja wymaga tylko cztero-liniowego pliku konfiguracyjnego i jednowierszowego pliku strefy. MaraDNS jest w pełni udokumentowany, zawiera zarówno łatwe w obsłudze samouczki, jak i kompletny i aktualny podręcznik.

• Mały. MaraDNS doskonale nadaje się do aplikacji wbudowanych i innych środowisk, w których serwer musi wykorzystywać absolutnie minimalną możliwą liczbę zasobów. Pliki binarne MaraDNS są mniejsze niż w przypadku innych obecnie utrzymywanych serwerów rekurencyjnych DNS.

• Otwarte źródło. MaraDNS jest w pełni open-source, licencja jest dwuskładnikową licencją BSD, która jest prawie identyczna z licencją FreeBSD.

Zobacz stronę maraDNS, na której znajduje się porównanie kilku programów serwera DNS, które mogą ci pomóc.

Jeśli korzystasz z DNS tylko dla siebie, lepszym pakietem oprogramowania jest djbdns. Był to jeden z niewielu pakietów oprogramowania, który zidentyfikował główny problem bezpieczeństwa DNS z zeszłego roku i został zbudowany / załatany, aby naprawić go wiele lat wcześniej. Do buforowania DNS instaluję dnscache (część djbdns) na wszystkich serwerach, które nie działają jako autorytatywne serwery DNS. To naprawdę działa lepiej niż BIND dla większości przedmiotów, ale biorąc pod uwagę dzisiejszy sprzęt, dodatkowa waga i wolniejsza prędkość BIND nie jest problemem.

Aby uzyskać doświadczenie, poznam podstawy BIND, niezależnie od tego, który pakiet chcesz uruchomić.

Djbdns jest skonfigurowany tak, aby był naprawdę łatwy do administrowania z poziomu wiersza poleceń. Wszystkie zmiany danych DNS są wykonywane jako polecenia. W BIND edytujesz serię plików tekstowych.

Możesz dostać paczki dla obu. Widzę różnicę jako IE w porównaniu z innymi przeglądarkami. IE jest wbudowany i działa na wiele rzeczy i nie zmienia się z domyślnego. Djbdns jest inny i wymaga innego zestawu kompromisów. W przypadku dostawcy usług internetowych przejście z BIND na djbdns może być nieco trudne, ponieważ BIND domyślnie buforuje i podaje nazwy, gdzie jak djbdns dzieli to na dwie części. To preferowane rozwiązanie bezpieczeństwa, ale trudniejsze do skonfigurowania, więc wiele instalacji BIND nie przeszkadza.

Osobiście powiedziałbym, że musisz nauczyć się podstaw BIND dla odniesienia, ale przejście na coś innego sprawi, że będziesz szczęśliwszym administratorem systemu na przyszłość :)

Większość miejsc, w których pracowałem w branży ISP, wydaje się wykorzystywać djbdns, zapewnia doskonałe bloki konstrukcyjne i fundamenty do warstwowania „zarządzanych” usług na szczycie - pisanie skryptów do generowania plików stref jest dość trywialne, co oznacza, że ​​możesz przechowywać wszystkie swoje dane DNS i tak w SQL. Obsługuje śmieszną liczbę zapytań na sekundę i jest bezpieczny do rozruchu.

Jeśli chcesz to skalować, po prostu zajrzyj na http://haproxy.1wt.eu i pop kilka autorytatywnych serwerów! Zdecydowanie zaleciłbym również rozdzielenie resolverów z autorytatywnych serwerów w dowolnej instalacji, którą zdecydujesz się wdrożyć.

Inne rzeczy, o których warto przeczytać to MaraDNS i PowerDNS.

Używam przede wszystkim FreeBSD do tego typu rzeczy, a ponieważ jest on dostarczany z pakietami BIND, nigdy tak naprawdę nie starałem się niczego więcej. Hoever uważam, że BIND jest dość łatwy w konfiguracji, a ponieważ jest utrzymywany przez FreeBSD w perspektywie bezpieczeństwa, muszę tylko śledzić ten kanał pod kątem problemów z bezpieczeństwem.

Sądzę więc, że najlepszym rozwiązaniem dla ciebie jest wypróbowanie obu z nich i sprawdzenie, który z nich najbardziej Ci odpowiada, to znaczy, chyba że używasz systemu operacyjnego dostarczonego z jednym z nich.

Jeśli chcesz dowiedzieć się o DNS, najlepiej jest skorzystać z książki O'Reilly „ DNS and BIND ” oraz zainstalowanej najnowszej wersji binda.

To prawda, że ​​BIND miał więcej problemów bezpieczeństwa w ciągu swojego życia. dnjdns nie miał go aż do zeszłego roku, ale ma zupełnie inną architekturę niż BIND i może być trudniejszy do znalezienia, jeśli nie wiesz, jak działa system nazewnictwa.

Jeśli chcesz po prostu dowiedzieć się, jak uruchomić serwer DNS (w przeciwieństwie do uczenia się o protokołach i tym podobnych), najlepiej wybrać jeden i zagłębić się. Spodziewam się, że znajdziesz pakiety binarne dla obu w dowolnej dystrybucji * nix. Biorąc to pod uwagę, istnieją pewne zalety kompilacji ze źródła za pomocą oprogramowania, które mogą wymagać ponownej kompilacji, jeśli zostanie zgłoszona luka w zabezpieczeniach.

Podobnie jak w przypadku każdej usługi dostępnej w Internecie, najlepszym rozwiązaniem jest zdrowy rozsądek i pragmatyczne myślenie, niezależnie od używanego oprogramowania. Jeśli musisz włączyć aktualizacje dynamiczne, upewnij się, że są one podpisane. Jeśli zezwalasz na transfery stref, ogranicz liczbę osób, które mogą je wykonywać z Twojego serwera itp.

WIĄZAĆ.

Jeśli nauczysz się go konfigurować (czytając całą masę dość męczących RFC związanych z DNS), możesz łatwo przełączyć się na inny serwer DNS w przyszłości (do jakichkolwiek celów). Używam BIND jako głównego i pomocniczego serwera wszędzie na FreeBSD, Linuksie, a nawet na laptopie Vista (dla hostów VMware NAT).

Przy okazji, jest to rodzaj zabawy, czytając źródło BIND i odkrywając, na przykład, jak działają klasyczne funkcje, takie jak gethostbyname () lub gethostbyaddr ().

Po latach używania binda w końcu dotarło do mnie, że większość moich serwerów wcale nie musi uruchamiać własnego demona DNS. To może nie dotyczyć ciebie, ale zastanów się: praktycznie każdy rejestrator domen oferuje obecnie serwery twoich rekordów DNS dla ciebie (zazwyczaj daje ci jakiś internetowy sposób edycji twoich rekordów DNS). Obsługują one podawanie informacji, zarządzanie dodatkami itp. Jeśli usuniesz potrzebę odpowiadania przez serwer na zapytania DNS, wszystko, co pozostało, to wyszukiwanie serwera DNS. W tym celu wskazuję mój plik /etc/resolv.conf na 4.2.2.1 i 4.2.2.2, które są serwerami DNS poziomu 3 „anycast” i wydają się dość szybkie i niezawodne.

Dodatkową zaletą jest to, że konfiguracja zapory ogniowej na serwerze nie musi już wpuszczać DNS. Wystarczy reguła „ustalona, ​​powiązana”, aby umożliwić kwerendy DNS serwera.

Okej, więc nie zapytałeś, czy potrzebujesz uruchomić demona DNS, ale na to pytanie odpowiedziałem. Na koniec, jeśli okaże się, że musisz go uruchomić, polecam pozostać przy bindowaniu, ponieważ jest on tak często używany, że znajdziesz mnóstwo dokumentacji i pomożesz zrobić to, co chcesz.