डीएनएस-ओवर-एचटीटीपीएस (डीओएच)

Google सार्वजनिक डीएनएस इन एंडपॉइंट पर दो अलग-अलग DoH एपीआई उपलब्ध कराता है:

सुरक्षित परिवहन की खास जानकारी वाले पेज पर, TLS के साथ-साथ डीएनएस (DoT) और DoH, दोनों के लिए एपीआई के साथ-साथ दूसरी सुविधाओं का इस्तेमाल करने के लिए, curl कमांड लाइन के उदाहरण दिए गए हैं.

DoH, सिर्फ़ IPv6 Google की सार्वजनिक DNS64 सेवा के साथ भी काम करता है.

Google सार्वजनिक DNS API कॉल के लिए असुरक्षित http: URL का समर्थन नहीं करता.

एचटीटीपी मेथड

जाकर,
GET के तरीके का इस्तेमाल करके, इंतज़ार के समय को कम किया जा सकता है, क्योंकि इसे कैश मेमोरी में सेव करना ज़्यादा आसान होता है. आरएफ़सी 8484 के GET अनुरोधों में, Base64Url के कोड में बदले गए डीएनएस मैसेज के साथ ?dns= क्वेरी पैरामीटर होना चाहिए. जीईटी तरीका ही JSON एपीआई के लिए काम करता है.
POST
पोस्ट करने का तरीका सिर्फ़ आरएफ़सी 8484 एपीआई पर काम करता है. साथ ही, यह अनुरोध के मुख्य हिस्से में और DoH एचटीटीपी रिस्पॉन्स में, कॉन्टेंट टाइप ऐप्लिकेशन/dns मैसेज का बाइनरी डीएनएस मैसेज इस्तेमाल करता है.
शीर्ष
HEAD की सुविधा अभी काम नहीं करती है और 400 बैड अनुरोध की गड़बड़ी दिखती है.

अन्य तरीके में 501, लागू नहीं की गई गड़बड़ियां मिलती हैं.

एचटीटीपी स्टेटस कोड

Google की सार्वजनिक डीएनएस सेवा के DoH वर्शन में, ये एचटीटीपी स्टेटस कोड दिखते हैं:

कार्रवाई सफल रही

200 ठीक
एचटीटीपी रिज़ॉल्वर और एचटीटीपी रिज़ॉल्वर, सफल रहा. रिस्पॉन्स बाइनरी, बाइनरी या JSON कोड में बदलने के तरीके का डीएनएस रिस्पॉन्स है. यह क्वेरी एंडपॉइंट, हेडर और जीईटी पैरामीटर स्वीकार करने पर निर्भर करता है.

रीडायरेक्ट

301 स्थायी रूप से स्थानांतरित
क्लाइंट को Location: हेडर में दिए गए यूआरएल पर फिर से कोशिश करनी चाहिए. अगर ओरिजनल क्वेरी POST के लिए अनुरोध थी, तो क्लाइंट को GET की मदद से सिर्फ़ तब कोशिश करनी चाहिए, जब नए यूआरएल में dns GET पैरामीटर का आर्ग्युमेंट दिया गया हो. ऐसा न होने पर, क्लाइंट को POST के साथ फिर से कोशिश करनी चाहिए.

आने वाले समय में, 302 मिले, 307 अस्थायी रीडायरेक्ट या 308 स्थायी रीडायरेक्ट जैसे दूसरे कोड का इस्तेमाल किया जा सकता है. डीओएच क्लाइंट को ये सभी कोड हैंडल करने चाहिए.

हमेशा के लिए 301 और 308 कोड के जवाबों को कैश मेमोरी में सेव रखना ज़रूरी है. साथ ही, अगर इस्तेमाल करना संभव हो, तो उपयोगकर्ताओं से नए यूआरएल का इस्तेमाल करके, अपने मूल कॉन्फ़िगरेशन को अपडेट करने के लिए कहा जा सकता है.

307 या 308 जवाब पाने वाले पोस्ट अनुरोध हमेशा POST के साथ फिर से कोशिश करने चाहिए.

गड़बड़ियां

गड़बड़ी के रिस्पॉन्स में, एचटीएमएल या सादे टेक्स्ट का इस्तेमाल करके, एचटीटीपी के स्टेटस की जानकारी दी जाएगी.

400 खराब अनुरोध
GET पैरामीटर या पार्स करने के अमान्य अनुरोध को पार्स करने में समस्या आ रही है. गलत जीईटी पैरामीटर के लिए, एचटीटीपी बॉडी को गड़बड़ी के बारे में बताना चाहिए. ज़्यादातर अमान्य डीएनएस मैसेज को 'फ़ॉर्मर' से 200 'ठीक है' पर क्लिक किया जाता है; बिना सवाल वाले सेक्शन के साथ गड़बड़ी वाले मैसेज के लिए एचटीटीपी गड़बड़ी दिखाई जाती है, जवाब के बारे में बताने वाला क्यूआर फ़्लैग या बाइनरी डीएनएस पार्स से जुड़ी बिना गड़बड़ी वाले अन्य मिले-जुले मैसेज.
413 पेलोड बहुत बड़ा है
आरएफ़सी 8484 के POST के अनुरोध की बॉडी, मैसेज की 512 बाइट की तय सीमा से ज़्यादा बड़ी हो गई है.
414 यूआरआई बहुत लंबा है
'GET' क्वेरी का हेडर बहुत बड़ा था या dns पैरामीटर में Base64Url का एन्कोड किया गया डीएनएस मैसेज था, जो 512 बाइट के मैसेज के साइज़ से ज़्यादा था.
415 असमर्थित मीडिया प्रकार
पोस्ट के हिस्से में application/dns-message कॉन्टेंट-टाइप हेडर नहीं है.
429 बहुत ज़्यादा अनुरोध
क्लाइंट ने तय समय में बहुत ज़्यादा अनुरोध भेजे हैं. क्लाइंट को फिर से कोशिश करने के बाद वाले हेडर में बताए गए समय (सेकंड में रिलेटिव समय) तक के लिए अनुरोध भेजना बंद कर देना चाहिए.
500 सर्वर में गड़बड़ी
Google सार्वजनिक डीएनएस की आंतरिक DoH गड़बड़ियां.
501 कार्यान्वित नहीं
सिर्फ़ GET और POST तरीकों का इस्तेमाल किया जाता है, जबकि अन्य तरीकों में यह गड़बड़ी होती है.
502 खराब गेटवे
DoH सेवा Google सार्वजनिक DNS रिज़ॉल्वर से संपर्क नहीं कर सकी.

502 रिस्पॉन्स के मामले में, Google के किसी दूसरे सार्वजनिक डीएनएस पते पर फिर से कोशिश करने से अगर मदद मिले, तो दूसरा DoH सेवा आज़माएं या फिर 8.8.8.8 पर पुराने यूडीपी या टीसीपी डीएनएस का इस्तेमाल करें.

DoH के फ़ायदे

एचटीटीपीएस का इस्तेमाल करने के साथ-साथ, एचटीटीपीएस का इस्तेमाल करने के कुछ और भी फ़ायदे हैं:

  • एचटीटीपीएस और आसानी से काम करने वाले एचटीटीपीएस एपीआई, Google की सार्वजनिक डीएनएस सेवा और संभावित क्लाइंट, दोनों के लिए लागू करने की प्रक्रिया को आसान बनाते हैं.
  • एचटीटीपीएस सेवा, वेब ऐप्लिकेशन को सभी तरह के डीएनएस रिकॉर्ड ऐक्सेस करने की सुविधा देती है. इससे, मौजूदा ब्राउज़र और ओएस डीएनएस एपीआई की सीमाओं से बचा जा सकता है. इनमें आम तौर पर, सिर्फ़ होस्ट से पते में पता लगाने की सुविधा काम करती है.
  • ऐसे क्लाइंट जो QUIC UDP-आधारित एचटीटीपीएस समर्थन लागू करते हैं, वे टीसीपी की ट्रांसपोर्ट का इस्तेमाल करते समय होने वाली समस्या से बच सकते हैं.

DoH के लिए निजता के सबसे सही तरीके

डीओएच ऐप्लिकेशन के डेवलपर को आरएफ़सी 8484 में बताई गई निजता के सबसे सही तरीकों और नीचे दी गई जानकारी को ध्यान में रखना चाहिए:

  • एचटीटीपी हेडर का इस्तेमाल कम करें

    एचटीटीपी हेडर से, क्लाइंट के DoH को लागू करने के बारे में जानकारी मिलती है. साथ ही, इसका इस्तेमाल क्लाइंट की पहचान छिपाने के लिए किया जा सकता है. कुकी, उपयोगकर्ता-एजेंट, और स्वीकार-भाषा जैसे हेडर सबसे खराब अपराधी होते हैं, लेकिन भेजे गए हेडर का सेट भी दिख सकता है. इस जोखिम को कम करने के लिए, सिर्फ़ DoH के लिए ज़रूरी एचटीटीपी हेडर भेजें: होस्ट, सामग्री का प्रकार (पोस्ट के लिए), और ज़रूरी होने पर. उपयोगकर्ता एजेंट को किसी भी डेवलपमेंट या टेस्टिंग वर्शन में शामिल किया जाना चाहिए.

  • EDNS के पैडिंग विकल्पों का इस्तेमाल करें

    ट्रैफ़िक विश्लेषण से बचने के लिए, 'डीओएच क्वेरी' को कुछ सामान्य लंबाई वाले पैड पर इस्तेमाल करने के लिए, आरएफ़सी 8467 में दिए गए दिशा-निर्देशों का पालन करें. एचटीटीपी/2 पैडिंग का इस्तेमाल भी किया जा सकता है. हालांकि, EDNS पैडिंग के उलट, DoH सर्वर के जवाबों पर पैडिंग की ज़रूरत नहीं होगी.

  • आरएफ़सी 8484 POST का इस्तेमाल, सिर्फ़ निजता को ध्यान में रखकर बनाए गए ऐप्लिकेशन या ब्राउज़र मोड के लिए करें

    DoH क्वेरी के लिए, POST का इस्तेमाल करने पर जवाबों की कैश मेमोरी कम होती है. साथ ही, डीएनएस में इंतज़ार का समय बढ़ सकता है. इसलिए, आम तौर पर इसका सुझाव नहीं दिया जाता है. हालांकि, निजता संवेदनशील ऐप्लिकेशन के लिए

समस्याएं

किसी गड़बड़ी की शिकायत करने या नई सुविधा का अनुरोध करने के लिए, कृपया DoH से जुड़ी समस्या खोलें.