DNS-over-HTTPS (DoH)

Google Açık DNS, aşağıdaki uç noktalarda iki farklı DoH API'si sağlar:

  • https://dns.google/dns-query – RFC 8484 (GET ve POST)
  • https://dns.google/resolve? – JSON API (GET)

Güvenli Aktarımlara Genel Bakış sayfasında, her iki API'nin kullanımı için curl komut satırı örneklerinin yanı sıra TLS ve TLS üzerinden DNS (DoT) ve DoH için yaygın olan diğer özelliklerle ilgili ayrıntılar da bulunmaktadır.

DoH, yalnızca IPv6 Google Public DNS64 hizmeti için de desteklenir.

Google Açık DNS, API çağrıları için güvenli olmayan http: URL'lerini desteklemez.

HTTP yöntemleri

GET
GET yöntemi daha etkili bir şekilde önbelleğe alındığından gecikmeyi azaltabilir. RFC 8484 GET istekleri, Base64Url kodlu bir DNS mesajı içeren bir ?dns= sorgu parametresine sahip olmalıdır. GET yöntemi, JSON API için desteklenen tek yöntemdir.
POST
POST yöntemi yalnızca RFC 8484 API için desteklenir ve istek gövdesinde ve DoH HTTP yanıtında Content-Type uygulaması/dns mesajı içeren bir ikili DNS mesajı kullanır.
HEAD
HEAD şu anda desteklenmiyor ve 400 Hatalı İstek hatası veriyor.

Diğer yöntemler "501 Uygulanmadı" hataları döndürür.

HTTP durum kodları

Google Açık DNS DoH, aşağıdaki HTTP durum kodlarını döndürür:

Başarılı

200 Tamam
DNS çözümleyici ile HTTP ayrıştırma ve iletişimi başarılı oldu ve yanıt gövdesinin içeriği, sorgu uç noktasına bağlı olarak ikili program veya JSON kodlamasında bir DNS yanıtı olarak kabul edildi. Başlık ve GET parametreleri kabul edildi.

Yönlendirmeler

301 Kalıcı Olarak Taşındı
İstemciler, Location: başlığında sağlanan URL'de yeniden denemelidir. Orijinal sorgu bir POST isteğiyse istemciler, yalnızca yeni URL'nin dns GET parametresi bağımsız değişkenini belirtiyorsa GET ile yeniden denemelidir. Aksi takdirde, istemciler POST ile yeniden denemelidir.

Gelecekte 302 Found, 307 Temporary Redirect veya 308 Permanent Redirect gibi başka kodlar kullanılabilir ve DoH istemcilerinin dört kodu da işlemesi gerekir.

Kalıcı 301 ve 308 kodlarına sahip yanıtlar süresiz olarak önbelleğe alınmalıdır. Mümkünse kullanıcılardan yeni URL'yi kullanarak orijinal yapılandırmalarını güncellemeleri istenebilir.

307 veya 308 yanıtları alan POST istekleri her zaman POST ile yeniden denenmelidir.

Hatalar

Hata yanıtlarının gövdesinde HTTP durumu için HTML veya düz metin kullanılarak açıklama bulunur.

400 Hatalı İstek
GET parametrelerini ayrıştırma sorunları veya geçersiz DNS isteği mesajı. Hatalı GET parametreleri için HTTP gövdesi hatayı açıklamalıdır. Çoğu geçersiz DNS mesajı, FORMERR ile birlikte 200 OK alır. Soru bölümü olmayan bozuk mesajlar, yanıtı belirten bir QR işareti veya ikili DNS ayrıştırma hataları içeren diğer anlamsız işaret kombinasyonları için HTTP hatası döndürülür.
413 Yük Çok Büyük
Bir RFC 8484 POST isteği gövdesi, 512 baytlık maksimum ileti boyutunu aşıyor.
414 URI Çok Uzun
GET sorgu üstbilgisi çok büyüktü veya dns parametresinde, maksimum 512 baytlık mesaj boyutunu aşan Base64Url kodlu bir DNS mesajı bulunuyordu.
415 Desteklenmeyen Ortam Türü
POST gövdesinde application/dns-message İçerik Türü başlığı yoktu.
429 Çok Fazla İstek Var
İstemci, belirli bir süre içinde çok fazla istek gönderdi. İstemciler, Retry-After başlığında belirtilen zamana (saniye cinsinden göreli süre) kadar istek göndermeyi durdurmalıdır.
500 Dahili Sunucu Hatası
Google Açık DNS dahili DoH hataları.
501 Uygulanmadı
Yalnızca GET ve POST yöntemleri uygulanır, diğer yöntemler bu hatayı alır.
502 Bozuk Ağ Geçidi
DoH hizmeti, Google Açık DNS çözümleyicileriyle iletişime geçemedi.

502 yanıtı durumunda, alternatif bir Google Genel DNS adresinde yeniden denemek işe yarayabilir, ancak başka bir DoH hizmeti denemek ya da 8.8.8.8 adresinden geleneksel UDP veya TCP DNS'ye geçmek daha etkili bir yedek yanıttır.

DoH'nin Avantajları

HTTPS'yi yalnızca TLS şifrelemesini değil, aynı zamanda kullanmanın bazı pratik avantajları vardır:

  • Yaygın olarak kullanılan ve iyi desteklenen HTTPS API'leri, hem Google Açık DNS'nin kendisi hem de potansiyel istemciler için uygulamayı basitleştirir.
  • HTTPS hizmeti, genellikle yalnızca ana makineden adrese aramaları destekleyen mevcut tarayıcı ve OS DNS API'lerinin sınırlamalarını ortadan kaldırarak web uygulamalarının tüm DNS kayıt türlerine erişmesini sağlar.
  • QUIC UDP tabanlı HTTPS desteği uygulayan istemciler, TCP aktarımı kullanırken oluşabilecek satır başı engelleme gibi sorunlardan kaçınabilir.

DoH İçin Gizlilikle İlgili En İyi Uygulamalar

DoH uygulamalarının geliştiricileri, RFC 8484'te özetlenen ve aşağıda açıklanan en iyi gizlilik uygulamalarını dikkate almalıdır:

  • HTTP Başlıklarının kullanımını sınırla

    HTTP üst bilgileri, istemcinin DoH uygulaması hakkındaki bilgileri ortaya koyar ve istemcileri anonimleştirmek için kullanılabilir. Cookie, User-Agent ve Accept-Language gibi üstbilgiler en kötü suçlardandır, ancak gönderilen üstbilgiler bile çok açık bilgiler verebilir. Bu riski en aza indirmek amacıyla yalnızca DoH için gerekli olan HTTP üstbilgilerini gönderin: Ana Makine, İçerik Türü (POST için) ve gerekiyorsa Kabul Et. User-Agent, tüm geliştirme veya test sürümlerine dahil edilmelidir.

  • EDNS dolgu seçeneklerini kullan

    Trafik analizine karşı koruma sağlamak amacıyla DoH sorgularını yaygın olarak kullanılan birkaç uzunlukla doldurmak için EDNS dolgu seçeneklerini kullanmak üzere RFC 8467'deki yönergeleri izleyin. HTTP/2 dolgusu kullanmak da mümkündür ancak EDNS dolgusunun aksine DoH sunucularından gelen yanıtlarda dolgu bulunmaz.

  • RFC 8484 POST'u yalnızca gizlilik açısından hassas uygulamalar veya tarayıcı modları için kullanın

    DoH sorguları için POST kullanımı, yanıtların önbelleğe alınabilirliğini azaltır ve DNS gecikmesini artırabilir. Bu nedenle genellikle önerilmez. Bununla birlikte, gizliliğe duyarlı uygulamalar için önbelleğe almanın azaltılması muhtemelen istenen bir uygulamadır ve kullanıcının son zamanlarda hangi alan adlarını ziyaret ettiğini belirlemeye çalışan web uygulamalarından gelen zamanlama saldırılarına karşı koruma sağlayabilir.

Sorunlar

Bir hatayı bildirmek veya yeni bir özellik isteğinde bulunmak için lütfen DoH ile ilgili bir sorun açın.