Rekordy HTTPS w DNS: jak działa wykrywanie HTTP/3

HTTP/3 przenosi HTTP przez QUIC, czyli z użyciem UDP. Klient może spróbować QUIC bez wcześniejszego ogłoszenia. Powodzenie zależy jednak od punktu końcowego i drogi sieciowej. Błąd może wystąpić natychmiast albo ujawnić się dopiero po przekroczeniu limitu czasu.

W wyborze pomagają dwa źródła informacji: Alt-Svc wskazuje usługę alternatywną w odpowiedzi HTTP, a rekord HTTPS w DNS może dostarczyć parametry połączenia przed pierwszym żądaniem HTTP. Oba mechanizmy ogłaszają możliwości, ale nie gwarantują osiągalnego ani szybszego połączenia.

Alt-Svc pomaga także podczas tej samej odsłony

Alt-Svc: h3=":443"; ma=86400 ogłasza równoważną usługę HTTP/3 na porcie UDP 443 tego samego hosta. ma podaje w sekundach okres ważności dla nowych prób połączenia. Użycie alternatywy jest opcjonalne; nadal obowiązuje walidacja certyfikatu pierwotnego hosta.

Bez wcześniejszego wpisu w pamięci podręcznej lub innego źródła informacji nagłówek często dociera najpierw przez HTTP/1.1 albo HTTP/2. Po odczycie klient obsługujący mechanizm może zestawić dodatkowe połączenie QUIC. Nie wymaga to kolejnej wizyty: korzyść może objąć dalsze zasoby tej samej strony. Pierwotne połączenie TCP nie musi zostać wcześniej zamknięte.

Co dodaje rekord HTTPS

Typ DNS HTTPS ma numer 65 i należy do mechanizmu SVCB. Dla zwykłego adresu HTTPS na porcie 443 zapytanie dotyczy nazwy hosta. Rekord ServiceMode opisuje możliwy cel połączenia: nazwę serwera, port i obsługiwane protokoły aplikacyjne, takie jak HTTP/3. Protokoły te są oznaczane identyfikatorami ALPN. AliasMode wskazuje natomiast inną nazwę, której rekordy wymagają dalszego rozwiązania.

alpn="h3,h2" ogłasza HTTP/3 i HTTP/2. Zgodny klient może dzięki temu spróbować pierwszego żądania HTTP przez QUIC. Wybór, równoległe próby połączenia, stan pamięci podręcznej i warunki sieciowe decydują o rzeczywistym przebiegu. Rekord DNS nie włącza HTTP/3 na serwerze.

ipv4hint i ipv6hint dostarczają wskazówek adresowych do wczesnej próby połączenia. Dostępne odpowiedzi A/AAAA mają pierwszeństwo; w przeciwnym razie odpowiednie zapytania nadal powinny zostać wykonane. Wskazówki nie zastępują więc zasadniczo rozwiązywania adresów.

Parametr ech może przenosić listę konfiguracji ECH z kluczem publicznym i dodatkowymi informacjami. Przy zgodnych klientach i serwerach ECH chroni między innymi wewnętrzną nazwę serwera TLS. Ogłoszenie w DNS nie dowodzi udanego użycia ECH. Nieszyfrowane zapytania DNS lub widoczne adresy docelowe nadal mogą ujawniać informacje; konfiguracja ECH może też być dostarczana innymi drogami.

Historyczne wyniki dla 20 domen

Zapisane wyniki narzędzia z 5 września 2026 r. ponownie przeanalizowano podczas aktualizacji. Poniższa tabela opisuje tamten przebieg, a nie aktualny pomiar dostawców czy reprezentatywny udział w rynku.

Dwie domeny ogłaszające h3 w rekordach HTTPS miały również odpowiedni nagłówek Alt-Svc. Nie dotyczyło to każdego rekordu HTTPS: trzeci wymieniał tylko h2 i nie miał nagłówka Alt-Svc. Siedem wobec dwóch daje współczynnik 3,5 dla obserwowanych ogłoszeń HTTP/3; siedem wobec wszystkich trzech rekordów HTTPS daje natomiast około 2,3.

Pięć ogłoszeń Alt-Svc miało ma równe 86 400 sekund, a dwa 2 592 000 sekund. W przetworzonych wynikach DNS nie rozpoznano parametru ech. Nie był to pomiar wynegocjowanych połączeń ECH; znaczenie mają także ograniczenia ówczesnego przetwarzania DNS.

Pojedynczy błąd nie ustala przyczyny

Historyczny rekord wyłącznie z h2 należał do stackoverflow.com. Wymuszony test HTTP/3 zakończył się po 63 milisekundach komunikatem „QUIC connection has been shut down”. Nie określa to zachowania wszystkich punktów końcowych ani intencji operatora. Poprawny rekord HTTPS bez h3 sam w sobie nie stanowi jednak błędu konfiguracji.

Dwie ogłoszone usługi przekroczyły limit czasu, podczas gdy inne połączenia HTTP/3 udały się w tym samym przebiegu. Potwierdza to podstawową obsługę QUIC przez stanowisko pomiarowe, lecz nie wyjaśnia każdego błędu. Dla google.com zapisano nawet czasy połączenia i TLS, zanim żądanie wygasło bez otrzymania odpowiedzi. Przekroczenie czasu nie zawsze oznacza więc blokadę UDP.

Przydatny raport błędu wskazuje URL, badany punkt końcowy, rodzinę IP, wersję klienta, czas i miejsce pomiaru. Jedna nieudana próba z jednej lokalizacji nie dowodzi awarii na całym świecie.

TTL i ma dotyczą różnych pamięci podręcznych

TTL określa, jak długo odpowiedź DNS może być zwykle ponownie używana z pamięci podręcznej. Rekurencyjne odpowiedzi DNS zawierały dla dwóch rekordów h3 wartości TTL wynoszące 20 i 21 474 sekundy. Takie wartości mogą przedstawiać pozostały czas ważności kopii. Nie pozwalają wiarygodnie ustalić pierwotnej skonfigurowanej TTL ani dowieść świadomego wyboru maksymalnej elastyczności lub minimalnego obciążenia resolverów.

Krótka skonfigurowana TTL ułatwia zmiany, lecz może zwiększać liczbę zapytań. Długie wartości utrudniają szybkie korekty. DNS serve-stale dopuszcza też przeterminowane dane w określonych warunkach awarii. TTL nie gwarantuje więc jednoczesnego przełączenia na całym świecie. Także ma określa ważność dla nowych połączeń alternatywnych, a nie jedynie zalecenie; istniejące połączenia nie muszą kończyć się wraz z upływem tego czasu.

Oddzielne sprawdzenie ogłoszenia i osiągalności

Przykłady używają nazwy zastępczej. Pierwsze żądanie pokazuje nagłówki odpowiedzi GET, po czym następuje zapytanie DNS. Ostatnie polecenie wymaga curl z obsługą HTTP/3; curl --version pokazuje dostępne możliwości.

curl --silent --show-error --max-time 15 --dump-header - \
  --output /dev/null https://example.com/
dig +noall +answer HTTPS example.com
kdig -t HTTPS example.com
curl --version
curl --http3-only --silent --show-error --max-time 15 \
  --output /dev/null --write-out 'HTTP %{http_version}\n' \
  https://example.com/

Żądanie --http3-only bada QUIC bez przejścia awaryjnego na TCP. Nie dowodzi w pełni, że przeglądarka wykrywa rekord HTTPS i wybiera alternatywny punkt końcowy. Inna nazwa docelowa lub port wymagają osobnego sprawdzenia dokładnie tego punktu. Przekierowania mogą również prowadzić do innego hosta i wymagają oddzielnej interpretacji.

Sprawdzanie HTTP/3 i Alt-Svc łączy prezentację DNS, próby protokołów i kolejne żądanie z pamięcią Alt-Svc. Sprawdzona implementacja nie podąża jednak za aliasami HTTPS, nie stosuje celu i portu z DNS w bezpośrednim teście QUIC oraz nie obsługuje w pełni uciętych odpowiedzi DNS. Drugie żądanie jest testem curl, a nie pełną wizytą przeglądarki. Poszczególne ustalenia pozostają przydatne, ale nie dowodzą kompleksowej kontroli wykrywania przez DNS.

Różnicę między wymuszonym testem protokołu a rzeczywistym zachowaniem klienta opisuje także HTTP/3 przy pierwszej wizycie: jak klient odkrywa protokół i co odpowiedziało dwadzieścia stron.