Czasem zdarza się, że korzystamy z własnego serwera nazw. najczęściej instalujemy go zgodnie z przeznaczeniem i dokumentacją, uruchamiamy i działa. Zatem istnieje Bind, o którym ISC pisze, że pracując nie zajmuje dużo pamięci. Niestety w praktyce, ze względu na mało modularną budowę i wiele wbudowanych funkcji, serwer ten pochłania jednak dość wiele zasobów (ps -u).
Załóżmy zatem, że nasze zasoby pamięci są skromne, a chcemy administrować własnymi strefami DNS. Jak w łatwy sposób poradzić sobie w takiej sytuacji? Można skorzystać np. z djbdns, o ile nie boimy się prac związanych z jego konfiguracją lub też uruchomić NSD, który dla niektórych osób może okazać się najlepszym wyborem. NSD to implementacja serwera nazw będąca nierekursywnym serwerem DNS. Pierwotnie serwer ten został napisany dla systemów z rodziny BSD. Jest to duży atut, jeśli chodzi o bezpieczeństwo. Jeśli wcześniej używaliśmy Binda, możemy wykorzystać posiadane pliki konfiguracyjne definiujące strefy, gdyż w NSD stosowany jest ten sam format wspomnianych plików.
Nierekursywne serwery nazw pracują w ten sposób, że odpowiadają na zapytania dotyczące stref, dla których dany serwer został skonfigurowany, natomiast na pozostałe zapytania reagują wysyłając kod błędu, czyli informację, że żądana domena jest nieznana. Tym sposobem serwer ten staje się miarodajny dla adresów zdefiniowanych w jego plikach konfiguracyjnych. Dzięki takiemu działaniu nie wszystkie wyniki zapytań trafiają do cache, a zatem nie zapełniają nadmiernie pamięci operacyjnej.
NSD składa się z kilku pojedynczych programów: nsd – właściwy serwer nazw uruchamiany jako demon, nsdc – skrypt służący do sterowania serwerem, zonec – kompilator stref przekształcający pliki ze zdefiniowanymi strefami do formatu bazy danych rozumianego przez serwer, nsd-notify – skrypt informujący NSD o zmianach w strefach oraz nsd-xfer – służący do zapewniania transferu stref, a pochodzący z debianowego pakietu named-xfer.
Załóżmy, że zainstalowaliśmy program i chcemy wskazać strefy, o istnieniu których powinien wiedzieć nasz serwer. W tym celu edytujemy plik 'nsd.zones’. Niech naszą główną strefą będzie 'example.org’ o adresie 10.6.2.1, wówczas wpisy w edytowanym pliku będą się składać z następujących wierszy:
zone example.org example.org zone 1.2.6.10.in-addr.arpa reverse
Pierwsza kolumna zawsze składa się wyłącznie ze słowa 'zone’. Druga kolumna składa się z nazwy strefy. W drugim wierszu nazwą tą jest domena in-addr.arpa, która odpowiada za mapowanie odwrotne (reverse mapping). W trzeciej kolumnie należy wpisać nazwy plików przypisanych do danej strefy, które trzeba będzie następnie utworzyć. Można tu także podać pełną ścieżkę do danego pliku. Względne położenie każdego pliku definiuje zmienna 'configdir’ z pliku 'nsd’.
Teraz musimy utworzyć pliki, których nazwy podaliśmy w trzeciej kolumnie oraz umieścić w nich wpisy stref. Możemy skopiować je z plików konfiguracyjnych Binda. W poszukiwaniu odpowiedniej składni można także przejrzeć archiwum listy dyskusyjnej NSD.
Po zdefiniowaniu stref należy przekształcić je do formatu, który czytany jest przez serwer NSD. W tym celu wykonujemy polecenie:
zonec -v -f /ścieżka/do/pliku/nsd.db /ścieżka/do/pliku/nsd.zones
W przypadku pojawienia się błędów podczas kompilacji, można zwielokrotnić flagę ’-v’, by otrzymać bardziej szczegółowe komunikaty. Developerzy ostrzegają, że nawet jeśli ww. polecenie wykonane zostanie bez informacji o błędach, po uruchomieniu serwera należy upewnić się, że strefy widziane są prawidłowo, gdyż tego typu format danych jest trudny do parsowania.
Serwer można włączyć z uprawnieniami użytkownika 'nsd’. W tym celu należy skorzystać z opcji ’-u’. Aby uzyskać statystyki, dodajemy flagę ’-s’. By ułatwić sobie czytanie logów, korzystnie jest dodatkowo uruchomić program dnsstat. Podczas pracy serwera możemy przekazywać do niego polecenia poprzez skrypt 'nsdc’ – szczegóły w 'man nsdc’. Jeśli serwer pracuje jako serwer nadrzędny, wówczas do kontroli transferu stref do serwerów podrzędnych wykorzystywany jest wrapper TCP, o ile został on wcześniej wkompilowany. Poprawność przejmowania danych przez podrzędne serwery można sprawdzić wydając polecenie:
nsd-xfer -z example.org -f somefile servername
Jeśli test się nie powiedzie, należy sprawdzić wpisy w /etc/hosts.allow i /etc/hosts.deny . Być może brakuje wpisu nazwy usługi: axfr albo axfr-nazwastrefy, np. axfr-example.org. . Na końcu nazwy domeny musi być kropka. Gdy już wszystko działa, jak należy, możemy ponownie wykonać polecenie 'ps -u’ i porównać nowy wynik zużycia pamięci (NSD) ze starym wynikiem (Bind).
Archiwalny news dodany przez użytkownika: wojtek_germ.
Kliknij tutaj by zobaczyć archiwalne komentarze.