specjaliści ds. bezpieczeństwa od dziesięcioleci doradzają ludziom, aby ograniczali zapytania DNS wobec swoich serwerów DNS, aby używali tylko portu UDP 53. W rzeczywistości zapytania DNS mogą również używać portu TCP 53, jeśli port UDP 53 nie jest akceptowany. Teraz wraz ze zbliżającym się wdrożeniem DNSSEC i ewentualnym dodaniem IPv6 będziemy musieli zezwolić naszym firewallom na przesyłanie zarówno pakietów TCP, jak i UDP port 53.

DNS może być używany przez atakujących jako jedna z ich technik rozpoznawczych., Informacje publiczne zawarte na serwerach celu są cenne dla atakującego i pomagają mu skupić się na atakach. Atakujący mogą korzystać z różnych technik pobierania informacji DNS za pomocą zapytań. Jednak hakerzy często próbują wykonać transfer strefy z autorytatywnych serwerów DNS, aby uzyskać dostęp do jeszcze większej ilości informacji. Możesz użyć polecenia dig, aby zebrać informacje z serwera dla określonego pliku strefy.,

dig @192.168.11.24 example.org -t AXFR

transfery stref odbywają się przez port TCP 53 i aby zapobiec ujawnianiu przez nasze serwery DNS krytycznych informacji atakującym, port TCP 53 jest zazwyczaj blokowany. Jeśli zapora organizacji chroniąca autorytatywny serwer DNS zezwalała na port 53 pakietów TCP, a serwer DNS został skonfigurowany tak, aby zezwalał na transfery stref do każdego, To polecenie dig byłoby skuteczne. Jednak większość organizacji skonfigurowała swoje serwery DNS, aby zapobiec transferom stref z niezamierzonych serwerów DNS., Można to skonfigurować w pliku BIND zone przy użyciu jednej z tych form polecenia allow-transfer, Jak pokazano poniżej.

allow-transfer {"none";}; allow-transfer { address_match_list }; allow-transfer {192.168.11.11;};

Ponadto większość organizacji używa zapór sieciowych do blokowania portu TCP 53 do i z serwerów DNS oraz Internetu. Jest to podwójna ochrona w przypadku, gdy serwer DNS przypadkowo zezwolił na transfery.

Konfigurowanie serwerów DNS tak, aby zezwalały na transfery stref do tylko legalnych serwerów DNS zawsze było i nadal jest najlepszą praktyką., Jednak praktyka odmawiania portu TCP 53 do i z serwerów DNS zaczyna powodować pewne problemy. Istnieją dwa dobre powody, dla których chcielibyśmy zezwolić zarówno na połączenia TCP, jak i UDP port 53 do naszych serwerów DNS. Jednym z nich jest DNSSEC, a drugim IPv6.

DNSSEC tworzy większe odpowiedzi DNS

uwielbiam czytać IP Journal i czytam go od pierwszego numeru w 1998 roku.

w ostatnim wydaniu IP Journal pojawił się artykuł mojego przyjaciela, Stephana Lagerholma, z Secure64 i Texas IPv6 Task Force, zatytułowany „wyzwania operacyjne podczas wdrażania DNSSEC”., W tym artykule omówiono wiele zastrzeżeń, na które napotykają organizacje w trakcie wdrażania DNSSEC.

jednym z kluczowych problemów jest to, że DNSSEC może spowodować, że odpowiedzi DNS będą większe niż 512 bajtów. DNSSEC (zdefiniowany w RFC 4033, RFC 4034 i RFC 4035) wymaga możliwości przesyłania większych wiadomości DNS ze względu na dodatkowe kluczowe informacje zawarte w odpowiedziach zapytań. Port TCP 53 może być używany w przypadkach, gdy odpowiedzi DNS są większe niż 512 bajtów., Jednak używanie wiadomości UDP jest preferowane niż używanie TCP dla dużych wiadomości DNS ze względu na fakt, że połączenia TCP mogą zużywać zasoby obliczeniowe dla każdego połączenia. Serwery DNS uzyskują wiele połączeń na sekundę, a korzystanie z TCP może dodać zbyt wiele kosztów. Aby rozwiązać ten problem, IETF RFC 2671″ Extension Mechanisms for DNS (EDNS0) ” definiuje metodę rozszerzenia bufora UDP do 4096 bajtów, aby umożliwić odpowiedzi DNSSEC i większe zapytania., Aby włączyć EDNS0 w konfiguracji BIND 9, możesz użyć następującej instrukcji BIND operations

edns-udp-size 4096 ;

świadomość DNSSEC wzrosła z powodu luk ujawnionych 2 lata temu i ostatnich wiadomości o rządach USA dążących do jego wdrożenia. Wiele organizacji planuje wdrożenia DNSSEC. DNSSEC jest coraz szerzej wdrażany teraz, gdy podpisywane są kluczowe domeny najwyższego poziomu (TLD). TLD. org została podpisana. Strefa korzeniowa Internetu została podpisana zaledwie 2 miesiące temu podczas ceremonii w Wirginii., VeriSign zadeklarowało chęć wsparcia DNSSEC dla .com i. NET do 2011 roku. Comcast stworzył witrynę Centrum Informacyjnego DNSSEC, która może pomóc ci być na bieżąco z najnowszym statusem DNSSEC.