Dnsmasq – DHCP i DNS dla małych i średnich sieci i nie tylko.

DHCP od ISC, którego opis konfiguracji zamieszczono niedawno na jakilinux.org jest świetny, popularny, skalowalny, o bardzo szerokich możliwościach, ale… jest też stosunkowo skomplikowany, szczególnie dla kogoś, kto po prostu chce nadawać adresy w swojej sieci. Nie jest to jednak jedyna implementacja opensource’owego serwera DHCP. Do godnych uwagi rozwiązań należy dnsmasq, czyli prosty i lekki serwer DHCP oraz forwarder DNS (de facto – DNS cache’ujący). Na dodatek obsługujący IPv6 (tylko dla DNS). Klient TFTP gratis. Co prawda tylko read only, ale do bootowania po sieci z użyciem PXE wystarczy, poza tym, to celowy zabieg w założeniu zwiększający bezpieczeństwo.

Co prawda na stronie projektu wspomina się o działaniu dnsmasq nawet na 1000 hostach, ale osobiście odradzam – cache DNS nie jest specjalnie pojemny (limit w kodzie, poza tym, co można skonfigurować) i przy większej ilości zapytań demon nie wyrobi się z odpowiedziami DNS (źródło: doświadczenia własne, kilka lat temu…) i trzeba będzie przeprosić się z czymś standardowym (bind, djbdns itp.). Natomiast dla kilkudziesięciu czy nawet małych kilkuset hostów powinien działać bardzo dobrze, przy minimalnym nakładzie pracy, a dając sporo opcji i możliwości (cache DNS, przygotowanie do IPv6), kosztem minimalnego tylko zużycia zasobów.

Główna zaleta dnsmasq to moim zdaniem prostota konfiguracji. Cały konfig, z definicjami zakresu, z jakiego ma przydzielać IP w DHCP, interfejsami, na których ma słuchać i określeniem wielkości cache DNS to… trzy linie. Mimo prostoty, rozwiązanie jest dość elastyczne i pozwala na parę przydatnych w sieci lokalnej tricków.

Wszystkie opcje są bardzo dobrze, z przykładami, opisane w pliku konfiguracyjnym /etc/dnsmasq.conf (Debian), do którego lektury, podobnie jak do man dnsmasq oczywiście odsyłam, poniżej przegląd kilku niezbędnych, podstawowych opcji i dodatkowo kilka najciekawszych.

Nieśmiertelna instalacja:

apt-get install dnsmasq 

Interfejs (inny, niż loopback, na którym słucha domyślnie), na którym demon ma słuchać zapytań DHCP i DNS:

interface=eth0

Oczywiście można zdefiniować więcej niż jeden, wystarczy dodać kolejne, analogiczne linie.

Zakres przyznawanych IP z DHCP, maska, czas dzierżawy:

dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,1h

Ustawienie rozmiaru cache DNS:

cache-size=150

To ustawienie (domyślne) raczej dla małej sieci, ale dzięki temu użytkownicy będą mieli kilka-kilkadziesiąt ms mniej na każdym zapytaniu DNS. I tak naprawdę te trzy linie w konfigu to wszystko, co jest potrzebne, by po prostu działało przydzielanie IP z DHCP na wskazanym interfejsie oraz cache DNS, czyli to, czego będzie potrzebować 99% korzystających. W takiej – domyślnej – konfiguracji zapytania kierowane są do serwerów DNS określonych w /etc/resolv.conf (można to zmienić).

Pora na parę troszeczkę bardziej zaawansowanych, ale przydatnych opcji (czyli nadchodzi przepisywanie manuala ;-)). Wyłączenie nasłuchu DHCP na wskazanym interfejsie (DNS nadal działa):

 no-dhcp-interface=eth1 

Oczywiście wcześniej musiałaby istnieć linia interface=eth1, żeby zadziałało.

Popularne bindowanie, czyli przypisanie IP do MAC (dany MAC zawsze otrzyma dany adres IP):

dhcp-host=11:22:33:44:55:66,192.168.0.60

Wykluczenie hosta o danym MAC z DHCP (nigdy nie otrzyma dzierżawy):

dhcp-host=11:22:33:44:55:66,ignore

Inna przydatna funkcja to umożliwienie manipulowania odpowiedziami uzyskiwanymi z serwerów DNS. Przykładowo, jeśli chcemy, by wszystkie zapytania o daną domenę były resolvowane na adres lokalny:

address=/doubleclick.net/127.0.0.1

Oczywiście linii może być więcej, czyli de facto można zrobić mały, lokalny DNS blackholing. Odpowiadać można zarówno adresami IPv4, jak i IPv6. Powyżej rozwiązanie dla reklam, ale równie dobrze można tym sposobem popsuć trochę szyki malware’owi, albo dać znać użyszkodnikom, że admin czuwa i NK w trakcie pracy to niekoniecznie dobry pomysł…

W przypadku IPv4 można też „naprawiać” odpowiedzi otrzymywane z nadrzędnych serwerów DNS:

alias=1.2.3.4,5.6.7.8

Dzięki powyższemu odpowiedź 1.2.3.4 zostanie przetłumaczona na 5.6.7.8.

Działa także dla całych zakresów:

alias=1.2.3.0,5.6.7.0,255.255.255.0

Powyższe powoduje, że każdy adres 1.2.3.x jest mapowany do 5.6.7.x

Teraz bonus dla wytrwałych czytelników, czyli opcja zwiększająca bezpieczeństwo, której nie ma w przykładowym konfigu (jest w manie, daje się dodać do konfiga).

stop-dns-rebind 

Chodzi o blokadę (i logowanie) odpowiedzi z nadrzędnych DNSów, które są adresami prywatnymi (stosowane do ataków na sieci lokalne, np. do zmiany konfiguracji routerów). Warto jednak doczytać o pozostałych opcjach typu rebind w manualu, żeby np. nie zepsuć DNS blackholingu na upstreamowych DNS…

Podstawowe opcje związane z TFTP

enable-tftp

powoduje włączenie TFTP. Można podać interfejs, na którym ma słuchać TFTP

enable-tftp=eth0

Można też ustawić różne katalogi TFTP obsługiwane na różnych interfejsach. W tym celu należy użyć

tftp-root=/katalog,eth0

tftp-root=/katalog2,eth1

Ostatnia przydatna opcja to

log-queries

które spowoduje logowanie zapytań DNS do pliku. Przydatne np. przy debugu, statystyce odpytywanych domen i przy permanentnej inwigilacji.

I tak naprawdę to koniec popularniejszych opcji (choć opcji jest dużo więcej). Moim zdaniem tyle wystarczy, by zachęcić do przyjrzenia się temu rozwiązaniu na mniejszych sprzętach i/lub sieciach. W wielu przypadkach nie ma sensu stosowania „dużych” rozwiązań typu dhcpd od ISC czy „pełny” serwer cache’ujący DNS.

Z innych, bardziej systemowych zastosowań dnsmasq – może być przydatny dla środowisk chroot z nieskonfigurowanym /etc/resolv.conf. Jeśli w /etc/resolv.conf nie ma żadnego działającego nameserwera, to odpytywany jest loopback. Dnsmasq domyślnie słucha na loopbacku, więc zapewni działające DNSy systemom w chrootach. Źródło: Simple DNS in chroots.

Jeszcze inną – ciekawą z punktu widzenia sysadminów – właściwością dnsmasq jest fakt, że domyślnie zapytania DNS kierowane są jednocześnie do wszystkich serwerów DNS. Bez żadnego, najmniejszego opóźnienia (czego AFAIK nie da się uzyskać przy korzystaniu wyłącznie z /etc/resolv.conf). Dla tych zastosowań, dla których działanie DNS jest krytyczne i nawet 1 sekunda w odpytaniach jest niedopuszczalna, dnsmasq być sposobem na zrównoleglenie odpytań serwerów DNS.

Na koniec odpowiedź na pytanie, jak sprawdzić, czy dnsmasq w ogóle działa. Należy wydać polecenie kill -USR1 `pidof dnsmasq`, następnie można sprawdzić w syslogu, co się pojawiło – grep dnsmasq /var/log/syslog. Powinny tam się znaleźć linie w stylu (nie ma hitów, bo niski uptime):

wielkość pamięci podręcznej: 2000; 0 z 212 miejsc aktualnych wpisów użyto ponownie.
171 zapytań przesłanych dalej, 467 odpowiedzi udzielonych samodzielnie

UPDATE: Dodane info i przykłady dla TFTP.

UPDATE: Dodany przykład jak uzyskać statystyki wykorzystania pamięci cache.

Licencja wpisu: CC BY-NC-SA (wyjątkowo, specjalnie dla jakilinux.org z okazji dyskusji nt. wpisu o DHCP od ISC). W związku ze zmianą licencji globalnie, w dodatku na bardziej liberalną, zapis ten nie ma już sensu.