Porównanie technologiczne DoH i DoT

DNS over HTTPS (DoH) i DNS over TLS (DoT) to dwa powszechnie stosowane sposoby szyfrowanej transmisji DNS, które realizują bezpieczne przesyłanie zapytań DNS za pomocą różnych stosów protokołów. Standard DoT jest zdefiniowany w RFC 7858, podczas gdy DoH został ustandaryzowany w dokumencie DNS Queries over HTTPS (DoH). Aby zrozumieć istotne różnice między tymi technologiami, należy przeanalizować je od strony hierarchii protokołów sieciowych.

Hierarchia protokołów sieciowych

Współczesne stosy protokołów sieciowych wykorzystują projekt warstwowy, przy czym każda warstwa pełni inną funkcję. DNS jako protokół warstwy aplikacji nie jest związany z konkretnym sposobem transmisji i może działać na wielu protokołach nośnych.

Warstwa aplikacji (L7) obejmuje protokoły takie jak HTTP/1.1, HTTP/2, HTTP/3, FTP i DNS. Warto zauważyć, że semantyka HTTP/3 nadal znajduje się na warstwie aplikacji, a QUIC służy jako nośnik transportowy. Warstwa bezpieczeństwa znajduje się między warstwą aplikacji a warstwą transportu i obejmuje głównie TLS oraz jego warianty. Zazwyczaj TLS działa na protokole TCP, np. w przypadku HTTPS i DoT. DTLS to wersja TLS dla datagramów, która może działać na protokole UDP. Protokół QUIC jest dość specyficzny, ponieważ integruje bezpośrednio wewnątrz protokołu handshake TLS 1.3 i wyprowadzanie kluczy.

QUIC można postrzegać jako protokół warstwy L4.5, który rozszerza UDP, zapewniając możliwości tradycyjnej warstwy transportu. Warstwa transportu (L4) obejmuje TCP, UDP i QUIC. Chociaż z inżynieryjnego punktu widzenia QUIC opiera się na UDP, posiada wbudowaną niezawodność, kontrolę zatłoczenia, multipleksowanie i szyfrowanie handshake, dlatego w inżynierii traktuje się go jako oddzielny protokół warstwy transportu. Warstwa sieciowa (L3) używa protokołu IP (IPv4/IPv6) odpowiedzialnego za routing i przekazywanie pakietów. Warstwa łącza danych (L2) obejmuje technologie takie jak Ethernet i Wi-Fi (802.11).

TLS jako metoda szyfrowania działa między warstwą aplikacji a warstwą transportu. Jeśli usunie się szyfrowanie TLS z DoT, to w istocie DoT staje się DNS over TCP. Taki projekt warstwowy sprawia, że szyfrowanie jest opcją, a nie obowiązkowym ograniczeniem samego protokołu.

Cechy Plain DNS

Najprostszy DNS nosi nazwę Plain DNS i może działać na protokole UDP lub TCP. UDP jest najczęstszym nośnikiem, ponieważ nawiązywanie połączenia jest proste, a pierwsze zapytanie jest szybkie. Słabą stroną UDP jest jednak brak niezawodności – pakiety łatwo gubią się w sieci. Mimo że TCP wymaga więcej handshake’ów i pierwsze połączenie jest wolniejsze o około 30% niż UDP, po ustanowieniu długotrwałego połączenia jego szybkość odpowiedzi jest taka sama jak UDP.

Operatorzy sieci w godzinach szczytu mogą wybierać odrzucanie pakietów UDP w celu złagodzenia obciążenia urządzeń. W regionach, gdzie niektórzy operatorzy mocno gubią pakiety UDP, określenie użycia TCP do zapytań DNS może być bardziej korzystne. TCP posiada mechanizm retransmisji, więc nawet w przypadku utraty pakietów gwarantuje niezawodne dotarcie danych, podczas gdy odrzucanie pakietów UDP nie zmniejsza obciążenia urządzeń małych operatorów, a wręcz przeciwnie, wprowadza więcej niepewności z powodu ponawiania prób.

Zagnieżdżanie warstwy aplikacji

Zarówno DNS, jak i HTTP należą do protokołów warstwy aplikacji, a DoH jest w istocie protokołem warstwy aplikacji zagnieżdżonym w innym protokole warstwy aplikacji. DoH nie musi koniecznie oznaczać DNS over HTTPS; użycie zwykłego HTTP jest również możliwe, choć niezaszyfrowany DoH to żądanie w czystym tekście, które nie ma żadnych przewag nad Plain DNS i jest używane tylko w bardzo nielicznych, specjalnych scenariuszach.

Teoretycznie DNS można obsługiwać na dowolnym protokole warstwy aplikacji; na przykład DNS over FTP również jest możliwy do zrealizowania, wystarczy opracować odpowiednie oprogramowanie serwera i klienta. Ta elastyczność demonstruje możliwość łączenia protokołów warstwy aplikacji.

flowchart TD
    subgraph L7["Warstwa aplikacji"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["Warstwa bezpieczeństwa"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["Warstwa transportu"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["Warstwa sieciowa"]
        I[IP]
    end
    
    subgraph L2["Warstwa łącza danych"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

Zagnieżdżanie warstwy transportu

Protokół QUIC opiera się na UDP, zapewniając jednocześnie usługi orientowane na połączenie na warstwie transportu. QUIC realizuje możliwości warstwy transportu, takie jak orientacja na połączenie, kontrola zatłoczenia, retransmisja, kontrola przepływu, fragmentacja i montaż, już dostępne w TCP. W porównaniu z TCP, QUIC ma niższe opóźnienia. W porównaniu z UDP, QUIC jest bardziej zaawansowany i niezawodny.

Relacje kombinacji protokołów

Nie ma ścisłego ograniczenia między warstwą aplikacji a warstwą transportu; szyfrowanie można dodać lub pominąć. HTTP może działać na TCP lub na QUIC. DNS może działać na TCP, na UDP lub na QUIC.

Na podstawie tych możliwości można podsumować następujące relacje kombinacji. Plain DNS to protokół DNS działający na UDP lub TCP. HTTP/2 to protokół HTTP działający na TCP z TLS 1.2 lub TLS 1.3. HTTP/3 to protokół HTTP działający na QUIC z TLS 1.3.

DoH (DNS over HTTPS) to protokół DNS działający na HTTP/2 lub HTTP/3. DoT (DNS over TLS) to protokół DNS działający na TCP z TLS 1.2 lub TLS 1.3. DoQ (DNS over QUIC) to protokół DNS działający na QUIC z TLS 1.3.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH przez HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH przez HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

Analiza wydajności i kompatybilności

Po zrozumieniu struktury warstw protokołów można przeanalizować zalety i wady DoH oraz DoT.

Porównanie TCP i QUIC wymaga uwzględnienia rzeczywistego środowiska sieciowego operatorów. QUIC jest nowszym protokołem rozwiązującym niektóre problemy starych sieci, ale wciąż opiera się na UDP. Z punktu widzenia opóźnień sieciowych, protokoły oparte na QUIC mają opóźnienia o około 35% niższe niż TCP, więc teoretycznie DNS over HTTP/3 i DoQ (DNS over QUIC) mogą oferować lepszą wydajność niż DNS over HTTP/2 i DoT.

Jednak w rzeczywistym środowisku sieciowym istnieje problem opóźnień spowodowanych retransmisją z powodu utraty pakietów. Operatorzy w godzinach dużego ruchu mogą odrzucać pakiety UDP, a QUIC może zostać zidentyfikowany jako UDP i odrzucony. Mimo że QUIC obsługuje retransmisję, opóźnienie wprowadzone przez nią może sprawić, że rzeczywiste opóźnienie QUIC będzie wyższe niż TCP.

Pod względem prywatności i bezpieczeństwa zarówno DoH, jak i DoT to ruch szyfrowany, który nie może zostać przechwycony ani sfałszowany. Jeśli chodzi o blokowanie DoT po zidentyfikowaniu, wynika to głównie z faktu, że ustawienia szyfrowanego DNS w systemie Android domyślnie używają portu 853, co czyni ten port wrażliwym. Sam DoT to powszechny, zwykły ruch szyfrowany i nie jest identyfikowany jako ruch dedykowany dla DNS. W rzeczywistości DoT może być świadczony na dowolnym porcie; na Androidzie wymaga to aplikacji stron trzecich, podczas gdy iOS natywnie obsługuje DoT na dowolnym porcie.

Rozszerzalność jest ważną zaletą DoH. W porównaniu z DNS opakowanym w HTTP i Plain DNS, HTTP ma znacznie lepszą rozszerzalność. Dostawcy mogą świadczyć niezliczone usługi na porcie 443, w tym DoH, i mogą wygodnie rozszerzać funkcje. DoT i DoQ zazwyczaj wymagają wyłącznego portu, a ich zdolności rozszerzania opierają się wyłącznie na Plain DNS. Jest to różnica z perspektywy dostawcy usług, której zwykły użytkownik na razie nie zauważa.

Jeśli chodzi o szybkość przetwarzania żądań DNS, przetwarzanie w HTTP może faktycznie być nieco wolniejsze o kilka cykli zegara CPU niż Plain DNS, ale różnica ta w praktycznym użytkowaniu jest znikoma. Pod względem kompatybilności DoH może stać się bardziej popularny, ponieważ dla dostawców usług ma on dobrą rozszerzalność.

Obecna obsługa szyfrowanego DNS na głównych platformach różni się. Przeglądarki oparte na jądrze Chromium obsługują DoH. System Windows 11 natywnie obsługuje DoH. System Android w wersji 8 i nowszych natywnie obsługuje DoT. System Android w wersji 11 i nowszych natywnie obsługuje DoT i DoH. System macOS natywnie obsługuje DoT i DoH. System iOS natywnie obsługuje DoT i DoH.

Rzeczywiste rekomendacje wyboru

Dla przeciętnego użytkownika korzystanie z DoH będzie mniej problematyczne niż DoT. W porównaniu z DoT, DoH większość czasu oferuje lepsze opóźnienia, a przez resztę czasu podobne. W porównaniu z DoQ, DoH większość czasu ma podobne opóźnienia, a przez pewien czas lepsze.

Warunkiem tego wniosku jest świadczenie przez dostawcę usługi DNS over HTTP/3. Jeśli dostawca nie oferuje HTTP/3, nie ma wyraźnej różnicy między DoH a DoT. DoH automatycznie używa DoH/3 w celu uzyskania niższych opóźnień, gdy jakość sieci jest dobra, i automatycznie przełącza się na HTTP/2, gdy jakość sieci jest niska. Ta zdolność adaptacji musi zostać zaimplementowana przez dostawcę, ale główni dostawcy zaz

• ←Poprzednia
• Następna→