Jest powiedzenie, że nowe to dobrze zapomniane stare. Tak jest w przypadku DNS i ataków różnej maści. Niedawno głośno było o DDoSach z użyciem DNS amplification, potem o podmianie DNS (głównie na routerach, nie jak kiedyś na komputerach, ale cel ten sam), a od niedawna popularne stało się generowanie dużej ilości zapytań do serwerów DNS rekursywnych ISP (AFAIK też ostatecznie rodzaj DDoSu). Na tyle dużej, że niektórzy operatorzy mieli/mają problemy z obsłużeniem żądań pochodzących od swoich klientów na swoich serwerach cache’ujących.
Z różnych pokątnych źródeł (Facebook, IRC) wiem, że pierwszego dnia, gdy się to zaczęło, były problemy z dostępem do Internetu w sieciach należących do Inei i Multimedii. Nie znam przyczyny, ale biorąc pod uwagę, że jeszcze jednemu providerowi „kończyły się” maszyny obsługujące rekursywne DNS i że w przypadku Multimedii pomagała zmiana w systemie na np. serwery DNS Google, przypuszczam, że chodzi właśnie o niewydolność serwerów DNS dostarczanych użytkownikom tych sieci przez ISP.
Rozwiązanie jest dość proste – wystarczy uruchomić swój serwer DNS rekursywny lub forwarder na desktopie czy routerze w swojej sieci, by sieć zaczęła działać lepiej i być mniej zależna (lub nawet niezależna) od DNSów naszego ISP. Ja na swoich desktopach (oczywiście Linux) od dłuższego czasu mam uruchomionego unbound (pokłosie benchmarków DNS) – jest lekki i bezproblemowy. W obecnej sytuacji mamy podwójną korzyść z własnego cache: po pierwsze, jak zwykle odpowiedzi udzielane będą nieco szybciej[1], po drugie, uniezależniamy się od serwerów naszego ISP, który w związku z niewesołą sytuacją w sieci może mieć problemy z działaniem w ogóle.
Z kolei w przypadku sieci lokalnych i routerów sprzętowych działających pod kontrolą OpenWrt lub podobnego systemu warto zwrócić uwagę na mały i zgrabny dnsmasq, którego konfigurację opisywałem kiedyś dość dokładnie.
Niezależnie od wyboru, koniecznie pamiętajmy o zabezpieczeniu czyli poprawnej konfiguracji naszego serwera DNS. Obsługujmy zapytania rekursywne tylko z naszej zaufanej sieci (np. LAN). W przeciwnym razie nasz serwer może zostać wykorzystany do DDoS poprzez DNS amplification. Ograniczać można na wiele sposobów w zależności od użytego serwera i możliwości: firewall, ograniczenie nasłuchiwania do konkretnego interfejsu lub definicje obsługiwanych prefiksów w konfiguracji samego serwera.
[1] Nie zawsze jest to prawdą, liczy się nie tylko opóźnienie do serwera, ale także zawartość jego cache czy wydajność sprzętu, na którym działa. Pisałem kiedyś szerzej o wyborze serwera DNS.