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

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

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

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

Google की सार्वजनिक डीएनएस सेवा, एपीआई कॉल के लिए असुरक्षित http: यूआरएल के साथ काम नहीं करती.

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

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

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

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

Google Public DNS DoH, इन एचटीटीपी स्टेटस कोड दिखाता है:

पुष्टि हो गई

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

रीडायरेक्ट

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

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

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

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

गड़बड़ियां

गड़बड़ी के जवाबों में एचटीएमएल या सादे टेक्स्ट का इस्तेमाल करके, मुख्य भाग में एचटीटीपी स्टेटस की जानकारी होगी.

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

502 रिस्पॉन्स के मामले में, वैकल्पिक Google सार्वजनिक डीएनएस पते का इस्तेमाल करने से मदद मिल सकती है. हालांकि, फ़ॉलबैक रिस्पॉन्स के तौर पर दूसरी डीओएच सेवा या 8.8.8.8 पर पारंपरिक यूडीपी या टीसीपी डीएनएस पर स्विच करना बेहतर विकल्प होगा.

DoH के फ़ायदे

सिर्फ़ TLS एन्क्रिप्शन ही नहीं, बल्कि एचटीटीपीएस का इस्तेमाल करने से कुछ व्यावहारिक फ़ायदे मिलते हैं:

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

डीओएच के लिए निजता से जुड़े सबसे सही तरीके

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

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

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

  • ईडीएनएस पैडिंग (जगह) के विकल्पों का इस्तेमाल करना

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

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

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

समस्याएं

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