[...]
1285757303: >>> emerge (10 of 11) net-dns/bind-9.7.1_p2 to /
1285757305: === (10 of 11) Cleaning (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757305: === (10 of 11) Compiling/Merging (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757568: === (10 of 11) Merging (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757573: >>> AUTOCLEAN: net-dns/bind:0
1285757573: === Unmerging... (net-dns/bind-9.4.3_p5)
1285757574: >>> unmerge success: net-dns/bind-9.4.3_p5
1285757576: === (10 of 11) Post-Build Cleaning (net-dns/bind-9.7.1_p2::/usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild)
1285757576: ::: completed emerge (10 of 11) net-dns/bind-9.7.1_p2 to /
[...]

etc-update jakoś przeszło, ale restart nie udał się, bo chroot dir okazał się inconsistent.
Wykonałem więc zalecane wskazówki, ale nie skupiłem się na wyniku, bo zajęty byłem rozmową o pogodzie czy kobietach. A wynik wyglądał tak:

dns ~ # emerge --config net-dns/bind

Configuring pkg...

* NOTE: As of net-dns/bind-9.4.3_p5-r1 the chroot part of the init-script got some major changes!
*
* /chroot/dns already exists... some things might become overridden
* press CTRL+C if you don't want to continue

Potem coś tam jeszcze, co nadpisało powyższe linijki, więc nie dotarły do mnie za pierwszym razem. Próba restartu usługi i… $!#$!%#@%! – coś nie działa. Przegląd konfiguracji i jeszcze bardziej ~^%$!%^$#! Nie ma mojej starej konfiguracji! Przecież tylko might become overridden!

Tylko spokojnie. Sytuacja do opanowania.
Myślicie, że była poprawna kopia zapasowa? Ja też tak myślałem.

Jest ciepło, ale nie gorąco. A może jednak? Przecież jest zapasowy serwer nazw, z którego można sobie ściągnąć wszystkie strefy.
Jest, ale nie pozwala na AXFR. Huh. Kontaktu z administratorami nie ma (ja niestety nim nie zarządzam).

Dobra, sprawdźmy co robią te komendy, bo może jednak gdzieś na boku zrobiły kopię.

W pliku /usr/portage/net-dns/bind/bind-9.7.1_p2.ebuild funkcja pkg_config() wygląda następująco:

294 pkg_config() {
295 CHROOT=$(source /etc/conf.d/named 2>/dev/null; echo ${CHROOT})
[...]
303 if [[ -d "${CHROOT}" ]]; then
304 ewarn "NOTE: As of net-dns/bind-9.4.3_p5-r1 the chroot part of the init-script got some major changes!"
305 ewarn
306 ewarn "${CHROOT} already exists... some things might become overridden"
307 ewarn "press CTRL+C if you don't want to continue"
308 sleep 10
309 fi
[...]
337 }


O! czyli miałem 10 sekund na reakcję. Poza tym niewiele ciekawego w tym pliku (ani słowa o usuwaniu plików).
Idźmy dalej, to /etc/init.d/named namówił mnie na emerge --config. Odnaleźć w nim można funkcję start(), a w niej taką zawartość:

91 start() {
92 ebegin "Starting ${CHROOT:+chrooted }named"
93
94 if [[ -n ${CHROOT} ]];
95 then
96 check_chroot || {
97 eerror "Your chroot dir ${CHROOT} is inconsistent, please run 'emerge --config net-dns/bind' first"
98 return 1
99 }
100 einfo "Mounting chroot dirs"
101 _mount /etc/bind ${CHROOT}/etc/bind -o bind
102 _mount /var/bind ${CHROOT}/var/bind -o bind
103 _mount /var/log/named ${CHROOT}/var/log/named -o bind
104 fi
[...]
113 }

O! Jakieś mount -o bind (działania funkcji _mount() można się domyśleć). Więc zatrzymanie usługi wywoła _umount() i jest nadzieja, że znajdą się pliki!

Ufff! Udało się. Od teraz będę wykonywał kopie ważnych plików konfiguracyjnych, jeśli nie całego serwera. Przynajmniej do końca miesiąca.

Czemu przytrafiło mi się to teraz? Jak było wcześniej?
W /usr/portage/net-dns/bind/bind-9.4.3_p5.ebuild mamy:

243 pkg_config() {
244 CHROOT=`sed -n 's/^[[:blank:]]\?CHROOT="\([^"]\+\)"/\1/p' /etc/conf.d/named 2>/dev/null`
245 EXISTS="no"
246
247 if [ -z "${CHROOT}" -a ! -d "/chroot/dns" ]; then
248 CHROOT="/chroot/dns"
249 elif [ -d ${CHROOT} ]; then
250 eerror; eerror "${CHROOT:-/chroot/dns} already exists. Quitting."; eerror; EXISTS="yes"
251 fi
252
253 if [ ! "$EXISTS" = yes ]; then
254 einfo ; einfon "Setting up the chroot directory..."
255 mkdir -m 700 -p ${CHROOT}
256 mkdir -p ${CHROOT}/{dev,etc,var/run/named}
257 chown -R named:named ${CHROOT}/var/run/named
258 cp -R /etc/bind ${CHROOT}/etc/
259 cp /etc/localtime ${CHROOT}/etc/localtime
260 chown named:named ${CHROOT}/etc/bind/rndc.key
261 cp -R /var/bind ${CHROOT}/var/
262 chown -R named:named ${CHROOT}/var/

Czyli oprócz mkdir -p było również cp -R. Zmieniło się począwszy od wersji 9.4.3_p5-r1, ale wcześniej był jeszcze rozszerzony komunikat:

291 ewarn "NOTE: As of net-dns/bind-9.4.3_p5-r1 the chroot part of the init-script got some major changes!"
292 ewarn "To enable the old behaviour (without using mount) uncomment the"
293 ewarn "CHROOT_NOMOUNT option in your /etc/conf.d/named config."


Uczcie się na moich błędach i pokażcie mi swoje. Dojdziemy do doskonałości.

Jan  6 16:16:17 dns named[2420]: client 63.217.28.226#59110: query (cache) './NS/IN' denied
Jan  6 16:16:23 dns named[2420]: client 63.217.28.226#5401: query (cache) './NS/IN' denied
Jan  6 16:16:29 dns named[2420]: client 63.217.28.226#42293: query (cache) './NS/IN' denied
[...]
Feb  5 11:01:33 dns named[2422]: client 89.149.221.182#33910: query (cache) './NS/IN' denied
Feb  5 11:01:37 dns named[2422]: client 89.149.221.182#5760: query (cache) './NS/IN' denied
Feb  5 11:01:39 dns named[2422]: client 89.149.221.182#39304: query (cache) './NS/IN' denied

Patrząc po ilości (1’174’755 sztuk w tym okresie z ok. 30 źródeł), nie nazwał bym tego atakiem typu DOS, a tym bardziej DDOS. Roboty próbują truć masowo, ale na razie nie blokuję tego w żaden sposób.

O odczuciach innych można poczytać tutaj:

• Potential DNS DDoS (query (cache) ‘./NS/IN’ denied) | Uno-Code
• DShield: DNS DDoS – let’s use a long term solution

bsk.com.pl

Zrobiło się ostatnio trochę szumu wokół DNS za sprawą Dana Kaminskiego. Więcej, prócz wpisów w jego blogu, można poczytać tutaj:

• NASK – Analiza problemu DNS cache poisoning w polskim Internecie
• IANA – Frequently Asked Questions on Cache Poisoning and Cross Pollination


wp.pl

• US – CERT – Multiple DNS implementations vulnerable to cache poisoning
• CERT Polska – Błędy w DNS dotyczące większości producentów

IANA udostępniła narzędzie, dzięki któremu możemy sprawdzić czy jesteśmy bezpieczni czy nie. Technicznie ten test wygląda mniej więcej tak (linie nieparzyste pytania, linie parzyste – odpowiedzi):

1: [udp sum ok] 59142 [1au] NS? DOMAIN.TLD. ar: . OPT UDPsize=4096 (40) (DF) (ttl
    52, id 0, len 68)
2: 59142*- q: NS? DOMAIN.TLD. 2/0/3 DOMAIN.TLD. NS[|domain] (ttl 63, id 45373, len
    154)
3: [udp sum ok] 29369+ SOA? iana.org. (26) (DF) (ttl 52, id 0, len 54)
4: [udp sum ok] 29369 ServFail- q: SOA? iana.org. 0/0/0 (26) (ttl 63, id 0, len 54)
5: [udp sum ok] 62488+ SOA? iana.org. (26) (DF) (ttl 52, id 0, len 54)
6: 62488- q: SOA? iana.org. 0/5/3 ns: iana.org. NS[|domain] (ttl 63, id 45375, len
    218)

Konwersacja z moim pierwszym serwerem (linie 3 i 4) kończy się odpowiedzią SERVFAIL, z drugim (linie 5 i 6) – iana.org has no SOA record. Pierwszy to bind 9.3.5, drugi – PowerDNS 2.9.21. Oba mają wyłączone rekursywne zapytania. W przypadku bind:

allow-recursion { 127.0.0.1; };

PowerDNS to:

allow-recursion=127.0.0.1/8

Wobec czego możemy się pocieszyć komunikatem:

djbdns (w wersji 1.05) nie odpowiada w ogóle na takie ‘zaczepki’ i IANA uznaje, że Appears to not respond to recursive lookups.

Na widokach w BIND działało to bardzo dobrze. Konfiguracja sprowadza się do podania warunków, dla których dane strefy będą przetwarzane. Mając do dyspozycji match-clients i match-destinations możemy naprawdę wiele zrobić. Skorzystanie z tej funkcjonalności oszczędzi nam uruchamiania drugiego serwera nazw np. dla sieci lokalnej czy dla konkretnego łącza.

Z czasem zacząłem wykorzystywać PowerDNS (z racji świetnie działającej natywnej obsługi baz danych) i właśnie funkcjonalności widoków mi brakuje. Co prawda można mieć jedną bazę z dodatkową kolumną content, ale i tak trzeba uruchomić dwa serwery. Nadzieją mogło by być wykorzystanie adresu IP klienta (odpowiedni warunek w zapytaniu SQL), ale to niemożliwe sądząc po (niejednej) wypowiedzi developerów na liście dyskusyjnej PowerDNS.