Google Açık DNS, aşağıdaki uç noktalarda iki farklı DoH API'si sağlar:
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'nindnsGET 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
dnsparametresinde, 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.