Minimalizacja QNAME

M

inimalizacja QNAME (RFC 7816), czyli Query Name zmienia zapytania DNS pochodzące z resolwera rekurencyjnego, aby w każdym zapytaniu zawierał tylko tyle szczegółów, ile jest to wymagane dla tego kroku w procesie rozwiązywania danej domeny. Internet Engineering Task Force opisuje to jako technikę, „w której resolwer DNS nie wysyła już pełnej oryginalnej nazwy QNAME do nadrzędnego serwera nazw”. Powiedzmy, iż chcemy odwiedzić stronę: stardust.nfsec.pl. W celu określenia adresu IP, z którym chce się połączyć przeglądarka, system wysyła zapytania do resolwera dostawcy usług internetowych (ISP) lub innego ustawionego przez konfigurację systemu. Prosi on o pełną nazwę – stardust.nfsec.pl – w tym przypadku. ISP (lub inny serwer DNS przydzielony przez zarządce sieci, z której korzystasz) zapyta root DNS, a następnie domenę najwyższego poziomu (.pl), a następnie domenę drugorzędną (nfsec.pl) o pełną nazwę domeny. W rzeczywistości wszystko, czego się dowiadujesz od głównego serwera DNS to odpowiedź na pytanie „kto odpowiada za .pl?”, a jedyne, o co pytasz serwer .pl, to „kto odpowiada za .nfsec.pl?”. Żadne z tych żądań nie musi zawierać informacji o pełnej nazwie strony internetowej, którą chcesz odwiedzić, aby odpowiedzieć na wcześniejsze pytania, ale niestety oba te serwery taką informacje otrzymują. Tak zawsze działał DNS, ale w tej chwili nie ma ku temu praktycznego powodu.

Czy chodzi znów o prywatność?:

Inwigilacja to model biznesowy internetu. Każdy jest pod stałym nadzorem wielu firm, od sieci społecznościowych takich jak Facebook po dostawców usług telefonii komórkowej. Dane te są zbierane, kompilowane, analizowane i wykorzystywane do prób sprzedawania nam rzeczy.

Dane osobowe, które są ujawniane podczas korzystania z internetu są cenne. jeżeli udostępniasz dane osobowe, powinieneś założyć, iż może istnieć ktoś, kto jest zmotywowany do ich zbierania, analizowania i zarabiania. Stały wyciek tego rodzaju metadanych w tle, w połączeniu z ciągle ulepszaną analityką dużych zbiorów danych sprawiły, iż łatwiej jest profilować i śledzić aktywności poszczególnych użytkowników w internecie. Jak możemy przeczytać w RFC 7816 – „Minimalizacja QNAME jest zgodna z zasadą… im mniej wysyłasz danych, tym mniej masz problemów z prywatnością”. Projekt DNS Privacy zawiera doskonałe podsumowanie powodów do obaw o prywatność użytkowników:

• Prawie każda aktywność w internecie zaczyna się od zapytania DNS (a często kilku). Kluczową funkcją DNS jest mapowanie nazw czytelnych dla człowieka (np. nfsec.pl) na adresy IP (np. 1.1.1.1) potrzebne komputerom do łączenia się ze sobą.
• Zapytania te mogą ujawnić nie tylko, jakie strony odwiedza dana osoba, ale także metadane o innych usługach, takich jak domeny kontaktów e-mail lub usługi czatu.
• Podczas gdy dane w systemie DNS są publiczne, indywidualne transakcje dokonywane przez użytkowników końcowych nie powinny być.
• Jednak zapytania DNS są wysyłane w postaci zwykłego tekstu (przy użyciu protokołu UDP lub TCP), co oznacza, iż pasywni podsłuchujący mogą obserwować wszystkie wykonane kwerendy DNS.
• DNS to globalnie rozproszony system, który przekracza granice międzynarodowe i często korzysta z serwerów w wielu różnych krajach w celu zapewnienia odporności.
• Powszechnie wiadomo, iż NSA wykorzystywała narzędzia MORECOWBELL i QUANTUMDNS do prowadzenia tajnego monitorowania, masowego nadzoru i przejmowania ruchu DNS.
• Niektórzy dostawcy usług internetowych rejestrują zapytania DNS na poziomie swoich resolwerów i udostępniają te informacje osobom trzecim w sposób, który nie jest znany lub oczywisty dla użytkowników końcowych.
• Niektórzy dostawcy usług internetowych umieszczają informacje o użytkowniku (np. personalny identyfikator użytkownika lub adres MAC) w zapytaniach DNS, które trafiają do resolwera ISP np. w celu świadczenia usług, takich jak filtry rodzicielskie. Pozwala to na pobieranie „odcisków palców” od poszczególnych użytkowników.
• Niektóre sieci CDN (ang. Content Delivery Network) osadzają informacje o użytkownikach (podsieciach klientów) w zapytaniach z resolwerów do autorytatywnych serwerów DNS (w celu geolokalizacji użytkowników końcowych). Pozwala to na korelacje zapytań do poszczególnych podsieci.
• Należy pamiętać, iż choćby podczas korzystania z VPN niektórzy dostawcy tej usługi będą doprowadzać do wycieku zapytań DNS, wysyłając je w postaci niezaszyfrowanej do ISP.

Techniczne efekty uboczne:

1) Adopcja minimalizacji QNAME nie jest jeszcze standardem w internecie dlatego niektóre, autorytatywne serwery DNS mogą być zdezorientowane otrzymując tego typu zapytania i albo nie będą na nie odpowiadać, zwrócą kod błędu, lub zwrócą śmieciowe dane. Na szczęście powstające implementacje w resolwerach posiadają opcję powrotu do standardowego trybu. Czyli domyślnym trybem będzie wysyłanie zminimalizowanych zapytań QNAME, a jeżeli nastąpi błąd klient DNS będzie „powracać” do normalnego trybu i ponownie wyśle zapytanie z pełną nazwą QNAME. Obecne ustawienie w trybie „kompatybilności” może w przyszłości zostać zamienione na „ścisłe”, co spowoduje spychanie na margines serwery, które nie będą poprawnie odpowiadać na zminimalizowane zapytania.

2) Największym wyzwaniem związanym z minimalizacją QNAME jest widza, gdzie kończy się część nazwy FQDN, a zaczyna część nazwy hosta. Załóżmy na przykład, iż mamy domenę o nazwie „nfsec.pl”. FQDN wewnątrz tej domeny to „stardust.nfsec.pl”. Gdybyśmy teraz mieli inną nazwę hosta o nazwie „dev.stardust.nfsec.pl”? W takim przypadku koniec strefy następuje na poziomie „nfsec.pl”, a „dev.stardust” jest częścią nazwy hosta FQDN. Skąd serwer zgodny z RFC 7816 wie dokładnie, gdzie następuje początek i koniec strefy? Krótka odpowiedź: nie wie. Resolwer musi wydedukować lokalizację strefy DNS na podstawie odpowiedzi, które otrzymuje z różnych serwerów DNS w łańcuchu odpytań resolwera:

1. Odpytaj główne serwery o listę autorytatywnych serwerów TLD dla .pl.
2. Odpytaj serwery TLD .pl o listę autorytatywnych serwerów dla nfsec.pl.
3. Odpytaj serwery DNS nfsec.pl o listę autorytatywnych serwerów dla stardust.nfsec.pl.
4. Ups. Nie ma ani jednego (NODATA). Nie ma też strefy dla stardust.nfsec.pl.
5. Teraz resolwer wie, gdzie znajduje się odcięcie strefy (na poziomie nfsec.pl) i może przystąpić
do zapytania o FQDN dev.stardust.nfsec.pl autorytatywnego serwera nazw nfsec.pl.

Dodatek A do RFC 7816 opisuje bardziej rozbudowany algorytm QNAME, który między innymi obsługuje ten scenariusz „nie wiem, gdzie następuje ucięcie strefy”.

3) RFC zwraca również uwagę na inne możliwe wyzwanie związane z minimalizacją QNAME – źle „zachowujące” się serwery DNS, które nie honorują żądań dotyczących rekordów NS. Rekordy NS to rekordy serwerów nazw – wymagane, aby znaleźć autorytatywne serwery nazw dla domeny. Jest to krytyczna część funkcji minimalizacji QNAME, ponieważ proces rekurencji polega na ustaleniu, który serwer autorytatywnie przechowuje odpowiedź na zapytanie o nazwę hosta klienta za pośrednictwem zapytań NS, a następnie proszenie o odpowiedź tylko autorytatywny serwer DNS. RFC 7816 opisuje scenariusz, w którym niektóre serwery DNS mogą nie honorować żądań NS, zamiast tego honorują tylko żądania rekordów typu „A”. Pośrednicy sieciowi, tacy jak load balancery, były wymieniane jako tacy „złoczyńcy”. RFC wskazuje, iż pośredniczące serwery DNS zachowujące się w ten sposób są technicznie uszkodzone, ale jest możliwe obejście:

„…spróbuj z żądaniami QTYPE=A (typ „A” jest wybierany, ponieważ będzie on zawsze akceptowany podczas, gdy QTYPE=NS może popsuć humor pośredników). Zamiast odpytywać serwery nazw dzięki zapytania „NS example.com”, moglibyśmy użyć „A _.example.com” i sprawdzić, czy otrzymamy odesłanie.

Dlatego nie należy się dziwić jeżeli w naszej infrastrukturze odnotujemy zapytania z podkreśleniem „_” zamiast subdomeny.

4) Istnieją też dobre efekty uboczne. Kiedy resolwer otrzyma odpowiedź typu NXDOMAIN, co oznacza, iż domena nie istnieje, dalsze odpytywanie jest zatrzymywane. Klient buforuje i ponownie wykorzystuje negatywne odpowiedzi, aby uniknąć zbędnych zapytań. Dlatego minimalizacja QNAME sprawia, iż każda negatywna odpowiedź jest bardziej użyteczna. Na przykład, podczas zapytania o domenę „stardust.nfsec.pl” z minimalizacją QNAME, negatywna odpowiedź z domeny .pl będzie tylko dotyczyć zapytania o domenę nfsec.pl i zostanie zapisana w pamięci podręcznej jako odpowiedź negatywna dla tego zapytania wyższego poziomu. Czyli buforowanie przez cały czas działa, a lokalny serwer DNS przez cały czas będzie przetrzymywał w pamięci podręcznej odpowiedzi zgodnie z TTL rekordu DNS. Minimalizacja QNAME również nie zmienia liczby kroków związanych z rekurencją, przy założeniu, iż kompatybilne serwery nazw mają dobrze skonfigurowane strefy.

Podsumowanie:

Minimalizacja QNAME to tylko jeden element ogólnego planu ochrony prywatności w internecie. Nie szyfruje on komunikacji ani nie zapewnia integralności otrzymywanych danych. Do tego służą DNS over HTTPS (DoH) oraz DNSSEC. Jednak minimalizacja QNAME jest ważna, aby zminimalizować pasywny wyciek danych i jest to kolejny krok w zakresie prywatności użytkownika końcowego. Najpopularniejsze serwery DNS typu opensource, takie jak BIND, Knot, Unbound i PowerDNS, mają już zaimplementowane, przetestowane i włączone domyślnie funkcje minimalizacji QNAME. Również duzi gracze oferujący darmowe i publiczne serwery DNS, którzy deklarują dbanie o prywatność użytkowników w coraz większym stopniu przeprowadzają adopcję tego rozwiązania.

Więcej informacji: Improving DNS Privacy With QNAME Minimization (RFC7816), Making the DNS More Private with QNAME Minimisation, QNAME Minimization and Your Privacy