प्रतिनिधि इंटरव्यू विषय

सामान्य इंटरव्यू: DNS SVCB और HTTPS रिकॉर्ड्स को समझाना

सामान्यकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक सर्विस चाहती है कि DNS वैकल्पिक एंडपॉइंट्स, HTTP/3 और TLS पैरामीटर्स का विज्ञापन करे। SVCB और HTTPS रेजोल्यूशन, AliasMode, पैरामीटर ट्रस्ट, कैशिंग और विफलता फ़ॉलबैक को समझाएं।

प्रॉम्प्ट और दायरा

एक टीम चाहती है कि DNS सर्विस-बाइंडिंग डेटा प्रकाशित करे ताकि क्लाइंट वैकल्पिक होस्ट, पोर्ट, प्रोटोकॉल और TLS हिंट्स खोज सकें, और उपलब्ध होने पर HTTP/3 को प्राथमिकता दें। SVCB और HTTPS रिकॉर्ड्स, प्राथमिकता, AliasMode, कैशिंग और सुरक्षा सीमाओं की व्याख्या करें। RFC 9460 SVCB और इसके HTTP वेरिएंट को परिभाषित करता है, लेकिन DNS हिंट्स सर्टिफिकेट सत्यापन, HTTP सेमेंटिक्स या ऑथराइजेशन की जगह नहीं लेते हैं।

इंटरव्यूअर क्या मूल्यांकन करता है

  • यह जानना कि HTTPS, HTTP-विशिष्ट SVCB वेरिएंट है।
  • AliasMode और ServiceMode तथा उनके प्राथमिकता नियमों में अंतर करना।
  • यह समझना कि alpn, port और एड्रेस हिंट्स कनेक्शन हिंट्स हैं।
  • DNSSEC, DoH/DoT और सामान्य DNS ट्रस्ट सीमाओं की व्याख्या करना।
  • TTL, फ़ॉलबैक, मॉनिटरिंग और निरसन (revocation) डिज़ाइन करना।

पहले पूछे जाने वाले स्पष्टीकरण

क्लाइंट और रिज़ॉल्वर संस्करणों की पुष्टि करें, क्या लक्ष्य अलियासिंग है या प्रोटोकॉल चयन, DNSSEC और एन्क्रिप्टेड-DNS परिनियोजन, HTTP/3 फ़ॉलबैक आवश्यकताएं, और सर्टिफिकेट तथा उपलब्धता लक्ष्य। यदि अनिर्दिष्ट है, तो मान लें कि कुछ रिज़ॉल्वर HTTPS रिकॉर्ड्स को नहीं समझते हैं।

तीस-सेकंड का उत्तर ढांचा

HTTPS रिकॉर्ड को HTTP सर्विस डिस्कवरी के रूप में मानें। प्राथमिकता 0 AliasMode दूसरे नाम की ओर इंगित करता है और इसके लिए दूसरे लुकअप की आवश्यकता होती है; गैर-शून्य ServiceMode रिकॉर्ड्स सेवाओं का वर्णन करते हैं। alpn और port कनेक्शन चुनने में मदद करते हैं लेकिन ऑथराइजेशन प्रदान नहीं करते हैं या TLS सत्यापन को प्रतिस्थापित नहीं करते हैं। लुकअप विफलता या असमर्थित प्रोटोकॉल पर, A/AAAA, डिफ़ॉल्ट पोर्ट और एक समर्थित प्रोटोकॉल पर फ़ॉलबैक करें, जिसमें TTL और मॉनिटरिंग रोलआउट को नियंत्रित करते हैं।

चरण-दर-चरण गहन विश्लेषण

1. रिकॉर्ड प्रकारों में अंतर करें

SVCB एक जेनेरिक सर्विस-बाइंडिंग रिकॉर्ड है; HTTPS इसका HTTP-उन्मुख वेरिएंट है। दोनों प्राथमिकता, लक्षित नाम और की-वैल्यू पैरामीटर ले जाते हैं। वे कोई प्रॉक्सी लेयर नहीं बनाते हैं; HTTP अभी भी RFC 9110 सेमेंटिक्स का पालन करता है।

2. AliasMode और ServiceMode को समझाएं

AliasMode वर्तमान नाम को लक्षित नाम का उपनाम (alias) देने के लिए प्राथमिकता 0 का उपयोग करता है, इसलिए क्लाइंट को लक्ष्य को क्वेरी करना चाहिए। ServiceMode किसी सेवा का वर्णन करने के लिए गैर-शून्य प्राथमिकता का उपयोग करता है। क्लाइंट पहले कम प्राथमिकताओं को आज़माते हैं लेकिन असमर्थित उम्मीदवारों को छोड़ देते हैं।

3. हिंट्स पर अत्यधिक भरोसा किए बिना उन्हें पढ़ें

alpn h2 या h3 का विज्ञापन कर सकता है, port एक गैर-डिफ़ॉल्ट पोर्ट का विज्ञापन कर सकता है, और एड्रेस हिंट्स अतिरिक्त लुकअप को कम कर सकते हैं। हिंट्स पुराने या ब्लॉक हो सकते हैं, इसलिए क्लाइंट अभी भी A/AAAA को हल करते हैं, QUIC/TLS पूरा करते हैं, और नेगोशिएट किए गए प्रोटोकॉल की पुष्टि करते हैं।

4. फ़ॉलबैक डिज़ाइन करें

एरर बजट के भीतर, सबसे कम प्राथमिकता वाली उपयोगी सेवा का प्रयास करें, फिर कनेक्शन त्रुटि या टाइमआउट के बाद अगले उम्मीदवार का प्रयास करें। यदि HTTPS लुकअप विफल हो जाता है, तो पारंपरिक A/AAAA और डिफ़ॉल्ट HTTPS पोर्ट का उपयोग करें। अज्ञात कुंजियाँ ऑथराइजेशन नीति नहीं बननी चाहिए।

5. कैशिंग और परिवर्तनों को प्रबंधित करें

TTL नियंत्रित करता है कि पुनरावर्ती रिज़ॉल्वर और क्लाइंट कितने समय तक हिंट्स को बनाए रखते हैं। क्रमिक TTL और रिकॉर्ड परिवर्तन से पहले नए होस्ट या पोर्ट को तैयार करें। आधिकारिक रिकॉर्ड को हटाने से कैश्ड उत्तर तुरंत नहीं हटते हैं; अत्यावश्यक घटनाओं के लिए सर्वर-साइड ब्लॉकिंग या सर्टिफिकेट नियंत्रण की आवश्यकता होती है।

6. DNS और TLS सुरक्षा को समझाएं

DNSSEC रिकॉर्ड अखंडता को प्रमाणित करता है; DoH/DoT क्वेरी ट्रांसपोर्ट की सुरक्षा करता है। दोनों में से कोई भी TLS पहचान सत्यापन की जगह नहीं लेता है। RFC 9460 DNS हिंट्स में विश्वास को क्लियरटेक्स्ट HTTP 307 सिग्नल से अधिक तक सीमित नहीं करता है। क्लाइंट अभी भी सर्टिफिकेट, SNI, ALPN और TLS संस्करण को मान्य करते हैं, और किसी अनकवर किए गए क्रॉस-ओरिजिन लक्ष्य को अधिकृत नहीं कर सकते हैं।

7. मान्य करें और रोलबैक करें

पुराने क्लाइंट, AliasMode चेन, एकाधिक प्राथमिकताओं, अज्ञात कुंजियों, बासी कैश, DNSSEC विफलता, अनुपलब्ध h3, सर्टिफिकेट बेमेल और IPv4/IPv6-ओनली नेटवर्क का परीक्षण करें। हैंडशेक समय, प्रोटोकॉल सफलता, फ़ॉलबैक, त्रुटियों और गोपनीयता संकेतों की निगरानी करें। पुराने रिकॉर्ड्स को पुनर्स्थापित करके और TTL की प्रतीक्षा करके रोलबैक करें; पहचान आपात स्थिति के लिए सर्वर-साइड ब्लॉकिंग का उपयोग करें।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं HTTPS रिकॉर्ड्स को सर्विस-डिस्कवरी हिंट्स के रूप में स्थान दूंगा। AliasMode क्लाइंट से लक्ष्य नाम की क्वेरी करवाता है, जबकि ServiceMode प्राथमिकता के आधार पर उम्मीदवारों को सूचीबद्ध करता है। alpn, port और एड्रेस हिंट्स चयन में सहायता करते हैं लेकिन कोई एक्सेस प्रदान नहीं करते हैं। यदि h3 विफल हो जाता है, तो बजट के भीतर h2 या पारंपरिक A/AAAA पथ पर वापस आएं, और DNS क्वेरी विफल होने पर पुराने पथ को उपलब्ध रखें।

DNSSEC रिकॉर्ड अखंडता की रक्षा करता है और DoH/DoT क्वेरी ट्रांसपोर्ट की रक्षा करता है, लेकिन सर्टिफिकेट, SNI, ALPN और TLS-संस्करण की जाँच स्वतंत्र रहती है। TTL-जागरूक रोलआउट का उपयोग करें और प्रोटोकॉल सफलता, फ़ॉलबैक, सर्टिफिकेट त्रुटियों और कैश व्यवहार की निगरानी करें। पुराने रिज़ॉल्वर, अज्ञात कुंजियों, AliasMode, DNSSEC विफलता और केवल IPv6 नेटवर्क का परीक्षण करें। आपातकालीन पहचान समस्या के लिए, सर्वर-साइड ब्लॉकिंग और सर्टिफिकेट नियंत्रण आवश्यक हैं; DNS कैश समाप्ति की प्रतीक्षा करना अपर्याप्त है।

सामान्य गलतियाँ

  • HTTPS को CNAME या रीडायरेक्ट प्रतिस्थापन के रूप में मानना।
  • AliasMode, ServiceMode और प्राथमिकता को भ्रमित करना।
  • एड्रेस हिंट्स को आधिकारिक मानना और A/AAAA को छोड़ देना।
  • यह मान लेना कि alpn=h3 QUIC/TLS नेगोशिएशन को बायपास करता है।
  • अखंडता सुरक्षा के बिना सामान्य DNS को भरोसेमंद कहना।
  • आधिकारिक रिकॉर्ड को हटाने के बाद कैश्ड उत्तरों को अनदेखा करना।
  • सत्यापन योग्य सर्टिफिकेट द्वारा कवर नहीं किए गए लक्ष्य की ओर इंगित करना।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: AliasMode को किसी अन्य लुकअप की आवश्यकता क्यों होती है?

यह केवल एक नाम-स्तरीय उपनाम व्यक्त करता है और कोई अंतिम सेवा पैरामीटर नहीं ले जाता है, इसलिए क्लाइंट को ServiceMode डेटा के लिए लक्ष्य को क्वेरी करना होगा।

फॉलो-अप 2: क्या HTTPS रिकॉर्ड्स CDN होस्ट के सर्टिफिकेट को बायपास कर सकते हैं?

नहीं। क्लाइंट अभी भी कनेक्शन नाम के लिए सर्टिफिकेट और TLS कॉन्फ़िगरेशन को मान्य करता है; CDN को एक सत्यापन योग्य सर्टिफिकेट प्रस्तुत करना होगा।

फॉलो-अप 3: DNSSEC और DoH/DoT कैसे भिन्न हैं?

DNSSEC रिकॉर्ड के स्रोत और अखंडता को मान्य करता है। DoH/DoT क्वेरी ट्रांसपोर्ट गोपनीयता की रक्षा करता है। दोनों में से कोई भी TLS पहचान सत्यापन का विकल्प नहीं है।

फॉलो-अप 4: आप लीक हुए लक्ष्य को कैसे निरस्त (revoke) करते हैं?

इसे पहले सर्वर-साइड ब्लॉक करें या इसके सर्टिफिकेट को निरस्त करें, फिर रिकॉर्ड्स अपडेट करें और TTL को कम करें; कैश्ड उत्तर तुरंत गायब नहीं होंगे।

सार्वजनिक स्रोत

संबंधित प्रश्न