Po dw\u00f3ch latach prac konsorcjum ISC zaprezentowa\u0142o pierwsz\u0105 stabiln\u0105 wersj\u0119 nowej, wa\u017cnej ga\u0142\u0119zi serwera DNS BIND 9.18. Wsparcie dla ga\u0142\u0119zi 9.18 b\u0119dzie prowadzone przez trzy lata, do drugiego kwarta\u0142u 2025 roku, w ramach rozszerzonego cyklu wsparcia. Wsparcie dla ga\u0142\u0119zi 9.11 zako\u0144czy si\u0119 w marcu, a dla ga\u0142\u0119zi 9.16 w po\u0142owie 2023 roku. W celu rozwoju funkcjonalno\u015bci nast\u0119pnej stabilnej wersji BIND utworzono eksperymentaln\u0105 ga\u0142\u0105\u017a BIND 9.19.0. <\/p>\n
Wydanie BIND 9.18.0 jest znacz\u0105ce dzi\u0119ki wprowadzeniu wsparcia dla technologii \u201eDNS przez HTTPS\u201d (DoH, DNS over HTTPS) oraz DNS przez TLS (DoT, DNS over TLS), a tak\u017ce mechanizmu XoT (XFR-over-TLS) do bezpiecznego przesy\u0142ania zawarto\u015bci stref DNS mi\u0119dzy serwerami (wsparcie dla przesy\u0142ania i odbioru stref przez XoT). Przy odpowiednich ustawieniach jeden proces named mo\u017ce teraz obs\u0142ugiwa\u0107 nie tylko tradycyjne zapytania DNS, ale tak\u017ce zapytania wysy\u0142ane z u\u017cyciem DNS-over-HTTPS i DNS-over-TLS. Wsparcie klienta dla DNS-over-TLS jest wbudowane w narz\u0119dzie dig, kt\u00f3re mo\u017cna wykorzysta\u0107 do wysy\u0142ania zapyta\u0144 przez TLS przy u\u017cyciu flagi \u201e+tls\u201d. <\/p>\n
Wdro\u017cenie protoko\u0142u HTTP\/2, u\u017cywanego w DoH, opiera si\u0119 na wykorzystaniu biblioteki nghttp2, kt\u00f3ra jest jednym z optionalnych zale\u017cno\u015bci kompilacyjnych. Certyfikaty dla DoH i DoT mog\u0105 by\u0107 dostarczane przez u\u017cytkownika lub generowane automatycznie podczas uruchamiania. <\/p>\n
Obs\u0142uga zapyta\u0144 z u\u017cyciem DoH i DoT jest w\u0142\u0105czana przez dodanie opcji \u201ehttp\u201d i \u201etls\u201d w dyrektywie listen-on. Aby wspiera\u0107 nieszyfrowane DNS-over-HTTP, w ustawieniach nale\u017cy wskaza\u0107 \u201etls none\u201d. Klucze s\u0105 definiowane w sekcji \u201etls\u201d. Standardowe porty sieciowe 853 dla DoT, 443 dla DoH i 80 dla DNS-over-HTTP mog\u0105 by\u0107 nadpisane przez parametry tls-port, https-port i http-port. Na przyk\u0142ad: <\/p>\n
tls local-tls { key-file \"\/path\/to\/priv_key.pem\"; cert-file \"\/path\/to\/cert_chain.pem\"; }; http local-http-server { endpoints { \"\/dns-query\"; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
W\u015br\u00f3d cech implementacji DoH w BIND wyr\u00f3\u017cnia si\u0119 mo\u017cliwo\u015b\u0107 przeniesienia operacji szyfrowania TLS na inny serwer, co mo\u017ce by\u0107 potrzebne w warunkach, gdy certyfikaty TLS s\u0105 przechowywane w innym systemie (na przyk\u0142ad w infrastrukturze z serwerami webowymi) i obs\u0142ugiwane przez inny personel. Wsparcie dla nieszyfrowanego DNS-over-HTTP zosta\u0142o wprowadzone w celu uproszczenia debugowania i jako poziom do przekierowania na inny serwer w sieci wewn\u0119trznej (w celu przeniesienia szyfrowania na osobny serwer). Na serwerze zdalnym do generowania ruchu TLS mo\u017cna wykorzysta\u0107 nginx, podobnie jak w przypadku organizacji otoczki HTTPS dla stron internetowych. <\/p>\n
Inn\u0105 cech\u0105 jest integracja DoH jako og\u00f3lnego transportu, kt\u00f3ry mo\u017ce by\u0107 stosowany nie tylko do przetwarzania zapyta\u0144 klient\u00f3w do resolvera, ale r\u00f3wnie\u017c podczas wymiany danych mi\u0119dzy serwerami, przy przekazywaniu stref przez autorytatywne serwery DNS oraz przy przetwarzaniu wszelkich zapyta\u0144 obs\u0142ugiwanych przez inne transporty DNS. <\/p>\n
W\u015br\u00f3d wad, kt\u00f3re mo\u017cna zrekompensowa\u0107 przez wy\u0142\u0105czenie kompilacji z DoH\/DoT lub przeniesienie szyfrowania na inny serwer, wyr\u00f3\u017cnia si\u0119 og\u00f3lne skomplikowanie bazy kodu \u2014 do sk\u0142adu dodawany jest wbudowany serwer HTTP i biblioteka TLS, kt\u00f3re mog\u0105 potencjalnie zawiera\u0107 luki i stanowi\u0107 dodatkowe wektory ataku. Ponadto korzystanie z DoH zwi\u0119ksza ruch. <\/p>\n
Przypomnijmy, \u017ce DNS-over-HTTPS mo\u017ce okaza\u0107 si\u0119 pomocne w eliminowaniu wyciek\u00f3w informacji o \u017c\u0105danych nazwach host\u00f3w przez serwery DNS dostawc\u00f3w, w walce z atakami MITM oraz podmian\u0105 ruchu DNS (na przyk\u0142ad podczas pod\u0142\u0105czania si\u0119 do publicznych Wi-Fi), w przeciwdzia\u0142aniu blokadom na poziomie DNS (DNS-over-HTTPS nie mo\u017ce zast\u0105pi\u0107 VPN<\/a> w zakresie omijania blokad, zrealizowanych na poziomie DPI) lub dla organizacji pracy w przypadku braku mo\u017cliwo\u015bci bezpo\u015bredniego kontaktu z serwerami DNS (na przyk\u0142ad podczas pracy przez proxy). Je\u015bli w normalnej sytuacji zapytania DNS s\u0105 bezpo\u015brednio wysy\u0142ane do okre\u015blonych w konfiguracji systemu serwer\u00f3w DNS, to w przypadku DNS-over-HTTPS zapytanie dotycz\u0105ce adresy IP<\/a> hosta jest inkapsulowane w ruchu HTTPS i wysy\u0142ane na serwer HTTP, na kt\u00f3rym resolver przetwarza zapytania przez Web API. <\/p>\n \u201eDNS przez TLS\u201d r\u00f3\u017cni si\u0119 od \u201eDNS przez HTTPS\u201d zastosowaniem standardowego protoko\u0142u DNS (zwykle u\u017cywa portu sieciowego 853), opakowanego w zaszyfrowany kana\u0142 komunikacyjny, utworzony przy pomocy protoko\u0142u TLS z weryfikacj\u0105 to\u017csamo\u015bci hosta przez certyfikaty TLS\/SSL, zatwierdzone przez centrum certyfikacji. Istniej\u0105cy standard DNSSEC wykorzystuje szyfrowanie jedynie do uwierzytelnienia klienta i serwera, ale nie chroni ruchu przed przechwyceniem i nie gwarantuje poufno\u015bci zapyta\u0144. <\/p>\n Kilka innych nowo\u015bci: <\/p>\n\n