DNS रिकॉर्ड्स को समझें: इतने सारे टाइप्स क्यों हैं? (टाइमलाइन)

किसी भी डोमेन की DNS सेटिंग्स खोलिए और आपको रहस्यमय कोड्स की एक पूरी दीवार दिखेगी — A, AAAA, MX, TXT, SRV, CAA, SVCB — और सच में ऐसा लगता है जैसे किसी ने एक पुराने इंजन में बेतरतीब हिस्से जोड़ते-जोड़ते इसे बना दिया हो। और ईमानदारी से कहें तो, असल में यही हुआ है। ये सभी रिकॉर्ड टाइप्स इसलिए बने क्योंकि इंटरनेट किसी ऐसी दीवार से टकराया जिसे मौजूदा रिकॉर्ड्स पार नहीं कर सकते थे, और जब आप यह पूरी कहानी सिलसिलेवार देखते हैं, तो यह सारी गड़बड़ी असल में समझ में आने लगती है।

अच्छा, तो DNS रिकॉर्ड आखिर है क्या?

टाइमलाइन से पहले एक छोटा रिफ्रेशर ले लेते हैं, क्योंकि आगे आने वाली हर चीज़ के लिए यह ज़रूरी है।

DNS इंटरनेट की फोनबुक है [1]। इस फोनबुक की हर एंट्री एक “रिसोर्स रिकॉर्ड” होती है, और हर रिकॉर्ड — टाइप कोई भी हो — वही बेसिक स्ट्रक्चर फॉलो करता है जो नवंबर 1987 में RFC 1035 में तय किया गया था [2]:

example.com.    3600    IN    A    192.0.2.10
   |             |       |    |        |
  name          TTL    class type    data

नाम (name), टाइम-टू-लिव (TTL), क्लास (class) (लगभग हमेशा “इंटरनेट” के लिए IN — अब इसके अलावा कोई और इस्तेमाल नहीं करता), टाइप (type), और फिर डेटा जिसका फॉर्मेट पूरी तरह टाइप पर निर्भर करता है। यहाँ असली कहानी type फील्ड की है। यह बस एक नंबर है। IANA के पास एक रजिस्ट्री है जो बताती है कि कौन सा नंबर किसका मतलब रखता है [16], और उसके बाद आने वाला डेटा इस नंबर के आधार पर पूरी तरह अलग तरीके से समझा जाता है।

तो जब लोग पूछते हैं “इतने सारे DNS रिकॉर्ड टाइप्स क्यों हैं”, तो ईमानदार जवाब यह है: क्योंकि type फील्ड को शुरू से ही एक्सटेंड किए जाने के लिए डिज़ाइन किया गया था। यह बेसिकली एक प्लग-इन सिस्टम है। जब भी इंटरनेट को किसी नई चीज़ को ढूंढने की ज़रूरत पड़ी — एक मेल सर्वर, एक IPv6 एड्रेस, एक चैट सर्वर, एक सर्टिफिकेट पॉलिसी — किसी ने एक प्रोपोज़ल लिखा, IETF ने उसे एक RFC में बदला, और IANA ने एक नया type नंबर जारी कर दिया। चालीस-से-ज़्यादा सालों से “इंटरनेट को एक और चीज़ चाहिए थी” — यही वजह है कि आपका DNS पैनल किसी कंट्रोल रूम जैसा दिखता है।

ओरिजिनल टीम (1983–1987)

DNS खुद हमेशा से नहीं था। 1983 से पहले, पूरा इंटरनेट (तब ARPANET) एक सिंगल टेक्स्ट फाइल HOSTS.TXT पर निर्भर था, जिसे SRI International सेंट्रली मेंटेन करता था, और हर मशीन इसे डाउनलोड करके नामों को एड्रेसेस से मैप करती थी [4]। जब कुछ सौ होस्ट्स थे तब यह ठीक काम करता था। लेकिन जब नेटवर्क एक्सपोनेंशियली बढ़ने लगा, तो यह काम नहीं कर पाया।

पॉल मॉकेपेट्रिस (Paul Mockapetris), जो USC के इंफॉर्मेशन साइंसेज इंस्टीट्यूट में जॉन पॉस्टेल (Jon Postel) के अंडर काम कर रहे थे, को इसे ठीक करने का काम सौंपा गया। 1983 में उन्होंने RFC 882 और RFC 883 लिखे, जिनमें एक बड़ी फाइल के बजाय एक डिस्ट्रिब्यूटेड, हायरार्किकल डेटाबेस का प्रस्ताव दिया गया [3]। चार साल बाद इन्हें संशोधित करके नवंबर 1987 में RFC 1034 और RFC 1035 से बदल दिया गया [2], और यही वह डॉक्यूमेंट है जो उन मुख्य रिकॉर्ड टाइप्स को परिभाषित करता है जो आज भी ज़्यादातर काम करते हैं।

यहाँ ओरिजिनल लाइनअप है, और यह भी कि हर एक को किसी दूसरे रिकॉर्ड पर फ्लैग बनने के बजाय अपने खुद के टाइप के रूप में क्यों मौजूद होना पड़ा:

आखिरी रो असल में बहुत कुछ सिखाती है। हर डिफाइन किया गया रिकॉर्ड टाइप टिका नहीं रहता। HINFO का मकसद यह बताना था कि कोई होस्ट किस CPU और OS पर चल रहा है — जो आज प्राइवेसी के लिहाज़ से डरावना लगता है, और सच में अब लगभग कोई इसे पब्लिश नहीं करता। DNS सिर्फ जुड़ता ही नहीं जाता; यह कभी-कभी खुद की छंटाई भी करता है।

रुकिए — सब कुछ एक ही रिकॉर्ड में क्यों नहीं समेटा जा सकता?

वाजिब सवाल है। यहाँ बताया गया है कि यह क्यों काम नहीं करता, और यही इस आर्टिकल के बाकी हिस्से को समझने की कुंजी भी है।

हर रिकॉर्ड टाइप अपना खुद का वायर फॉर्मेट डिफाइन करता है — type फील्ड के बाद आने वाले डेटा का सटीक बाइनरी लेआउट। MX रिकॉर्ड का डेटा है “एक प्रायोरिटी नंबर प्लस एक होस्टनेम।” CAA रिकॉर्ड का डेटा है “एक फ्लैग, एक टैग, और एक वैल्यू।” SRV रिकॉर्ड का डेटा है “प्रायोरिटी, वेट, पोर्ट, और टारगेट।” ये शेप्स बुनियादी तौर पर अलग हैं, और सही तरीके से पार्स करने के लिए रिज़ॉल्वर को पहले से ही यह शेप पता होना चाहिए।

इस डिज़ाइन का स्मार्ट हिस्सा यह है कि पुराने सॉफ्टवेयर के लिए अनजान रिकॉर्ड टाइप्स बस ओपेक ब्लॉब्स होते हैं। 1990 के दशक का कोई DNS रिज़ॉल्वर जिसने कभी CAA रिकॉर्ड के बारे में नहीं सुना, वह क्रैश होने के बजाय बस इसे बिना पार्स किए आगे भेज देगा। यही ग्रेसफुल डिग्रेडेशन का सिद्धांत है जिसने 40 से ज़्यादा सालों तक DNS को बैकवर्ड-कम्पैटिबल रखा है — पुराने क्लाइंट्स नए टाइप्स पर अटकते नहीं, वे बस जो नहीं समझ पाते उसे नज़रअंदाज़ कर देते हैं [17]।

लेकिन यह फॉरवर्ड-कम्पैटिबिलिटी दोनों तरफ काम करती है। एक बिल्कुल नया रिकॉर्ड टाइप टेक्निकली “सपोर्टेड” तभी हो जाता है जब IANA उसे एक नंबर दे देता है, लेकिन यह उपयोगी तभी बनता है जब रजिस्ट्रार्स, DNS होस्टिंग पैनल्स, वैलिडेटर्स, और एप्लीकेशंस — सब इसके लिए साफ-साफ सपोर्ट जोड़ने की ज़हमत उठाएं। आगे हम एक बढ़िया उदाहरण देखेंगे जहाँ एक रिकॉर्ड टाइप डिफाइन हुआ और फिर एक पुराने टाइप के पक्ष में लगभग छोड़ ही दिया गया — पढ़ते रहिए।

टाइमलाइन: हर बार जब DNS को नया टाइप मिला, और क्यों

यही वह हिस्सा है जो असल में “इतने सारे क्यों हैं” का जवाब देता है — हर नया जोड़ एक खास पल से जुड़ा है, जब इंटरनेट की समस्याएं मौजूदा चीज़ों से आगे निकल गईं।

1995 (फिर 2003): AAAA — इंटरनेट के एड्रेसेस खत्म हो रहे थे

IPv4 आपको लगभग 4.3 बिलियन एड्रेसेस देता है। यह बहुत लगता है, जब तक आप यह याद नहीं करते कि हर फोन, लैपटॉप, स्मार्ट बल्ब, और फ्रिज को एक एड्रेस चाहिए। 90 के दशक के मध्य तक इंजीनियर्स को यह खत्म होते दिखने लगा था, इसलिए IPv6 को 128-बिट एड्रेसेस के साथ डिज़ाइन किया गया — यानी काफी ज़्यादा जगह।

लेकिन RFC 1035 का A रिकॉर्ड 32-बिट IPv4 एड्रेसेस के लिए हार्डकोडेड था। इसमें 128-बिट एड्रेस को फिट करने का कोई तरीका नहीं था। इसलिए दिसंबर 1995 में, AAAA (“क्वैड-A,” क्योंकि एक IPv6 एड्रेस एक IPv4 एड्रेस से चार गुना बड़ा होता है) को RFC 1886 में पेश किया गया [5]। इसे अक्टूबर 2003 में RFC 3596 के रूप में संशोधित किया गया, जिसने रिवर्स लुकअप्स को अजीब IP6.INT डोमेन से IP6.ARPA पर भी शिफ्ट कर दिया [5]। अगर आपकी वेबसाइट पर कभी A और AAAA दोनों रिकॉर्ड्स एक साथ रहे हैं, तो इसका मतलब है कि आपका सर्वर कह रहा है “IPv4 और IPv6 दोनों से पहुंचा जा सकता है, जो पसंद हो वो चुन लो।”

1996/2000: SRV — DNS वेब और मेल से आगे बढ़ा

यहाँ एक चीज़ है जो सालों तक प्रोटोकॉल डिज़ाइनर्स को परेशान करती रही: MX रिकॉर्ड्स से आप कह सकते थे कि “इस डोमेन के लिए मेल उस सर्वर पर जाएगी, जो वेबसाइट से अलग पोर्ट/होस्ट पर है।” बढ़िया। लेकिन अगर आप कोई चैट सर्वर, या डायरेक्टरी सर्विस, या वाकई कोई भी दूसरा प्रोटोकॉल चला रहे हों तो क्या होगा? SRV से पहले, हर नए प्रोटोकॉल को अपना MX-स्टाइल हैक बनाना पड़ता था, या बस एक पोर्ट हार्डकोड करके उम्मीद करनी पड़ती थी कि सब ठीक रहेगा।

SRV रिकॉर्ड्स ने इसे जनरलाइज़ कर दिया। पहली बार RFC 2052 (1996) में प्रोपोज़ किया गया और RFC 2782 (फरवरी 2000) में स्टैंडर्डाइज़ किया गया — एक SRV रिकॉर्ड एक प्रायोरिटी, एक वेट (लोड बैलेंसिंग के लिए), एक पोर्ट, और एक टारगेट होस्ट बताता है [6]। अब अचानक कोई भी सर्विस — XMPP चैट, SIP वॉइस कॉल्स, माइक्रोसॉफ्ट एक्टिव डायरेक्टरी, यहाँ तक कि माइनक्राफ्ट सर्वर्स — कह सकती थी कि “इस खास सर्विस के लिए एग्जैक्टली किस होस्ट और पोर्ट से कनेक्ट करना है,” और एडमिन क्लाइंट कॉन्फिग्स को तोड़े बिना चीज़ों को इधर-उधर कर सकते थे या फेलओवर सर्वर्स जोड़ सकते थे [6]।

2000: NAPTR — जब फोन नंबरों को भी DNS की ज़रूरत पड़ी

लगभग उसी समय, टेलिकॉम वर्ल्ड इंटरनेट के साथ मर्ज होने की कोशिश कर रही थी — खास तौर पर, ENUM नाम की किसी चीज़ के ज़रिए पारंपरिक फोन नंबरों (E.164 फॉर्मेट) को इंटरनेट सर्विसेज़ पर मैप करना, और SIP (Session Initiation Protocol) कॉल्स को रूट करना।

NAPTR (Naming Authority Pointer) रिकॉर्ड्स, जिन्हें RFC 2915 (2000) में डिफाइन किया गया, ने इसे एक नाम को एक रेगुलर-एक्सप्रेशन-बेस्ड रीराइट रूल से मैप करके हल किया, जो एक नया डोमेन नेम या URI बनाता है [7]। SRV रिकॉर्ड्स के साथ मिलकर, NAPTR ने एक सिंगल फोन नंबर को DNS के ज़रिए “यह है SIP सर्वर, यह है पोर्ट, यह है प्रोटोकॉल” में रिज़ॉल्व होने दिया [7]। ज़्यादातर लोगों के लिए यह एक निच रिकॉर्ड टाइप है, लेकिन अगर आपने कभी VoIP कॉल की है, तो NAPTR पर्दे के पीछे खामोशी से काम कर रहा था।

2005: DNSSEC का अल्फाबेट सूप — DNSKEY, RRSIG, NSEC, DS

अपने पहले ~20 सालों तक, DNS में ज़ीरो ऑथेंटिकेशन था। एक रिज़ॉल्वर सवाल पूछता है, जवाब मिलता है, और बस… उस पर भरोसा कर लेता है। यह एक बड़ी समस्या है अगर कोई उस जवाब को इंटरसेप्ट या फोर्ज कर सके — जिसे कैश पॉइज़निंग कहा जाता है, जहाँ एक अटैकर किसी रिज़ॉल्वर को किसी लेजिटिमेट डोमेन के लिए एक फेक IP एड्रेस कैश करने में चकमा देता है, और चुपचाप ट्रैफिक को एक मैलिशियस सर्वर पर भेज देता है।

DNSSEC (DNS Security Extensions) डिजिटल सिग्नेचर्स के ज़रिए इसे ठीक करता है, और इसके लिए चार नए रिकॉर्ड टाइप्स की ज़रूरत पड़ी, जिन्हें RFC 4034 (मार्च 2005) में औपचारिक रूप दिया गया, जिसने 1999 की एक पहले की और ज़्यादा अव्यवस्थित कोशिश को रिप्लेस कर दिया [8]:

• DNSKEY — किसी ज़ोन के सिग्नेचर्स को वेरीफाई करने के लिए इस्तेमाल होने वाली पब्लिक की (key) रखता है
• RRSIG — रिकॉर्ड्स के एक सेट को कवर करने वाला असली डिजिटल सिग्नेचर
• NSEC — साबित करता है कि कोई रिकॉर्ड मौजूद नहीं है (ताकि अटैकर्स बिना पकड़े “ऐसा कोई डोमेन नहीं है” का दावा न कर सकें)
• DS — एक हैश जो किसी चाइल्ड ज़ोन की की (key) को उसके पैरेंट ज़ोन से जोड़ता है, और एक चेन ऑफ ट्रस्ट बनाता है

इसे अपनाने की रफ्तार सालों तक धीमी रही — DNSSEC ज़ोन मैनेजमेंट में असली कॉम्प्लेक्सिटी जोड़ता है — लेकिन बाद के सालों में हाई-प्रोफाइल कैश-पॉइज़निंग रिसर्च की एक लहर ने इसे एक गंभीर धक्का दिया, और अब किसी भी ऐसे डोमेन के लिए DNSSEC को बेसिक ज़रूरत माना जाता है जो सुरक्षा को गंभीरता से लेता है।

2006–2015: SPF, DKIM, DMARC — ईमेल स्पूफिंग के खिलाफ जंग

अगर आपने कभी किसी कस्टम डोमेन के लिए ईमेल सेटअप किया है, तो आपका सामना इस तिकड़ी से हुआ होगा, और सच कहें तो यहीं से DNS सच में गड़बड़ हो गया — क्योंकि ये तीनों टेक्निकली उस सीधे-सादे TXT रिकॉर्ड के अंदर रहते हैं, जो शुरू में बस “यहाँ कोई फ्री-टेक्स्ट नोट लिखो” के लिए था।

• SPF (Sender Policy Framework) यह बताता है कि कौन से मेल सर्वर्स को आपके डोमेन की तरफ से ईमेल भेजने की इजाज़त है। यह RFC 4408 (अप्रैल 2006) में एक IETF एक्सपेरिमेंट के रूप में शुरू हुआ [9], और — यहाँ असल में अजीब बात है — इसे शुरू में अपना खुद का डेडिकेटेड रिकॉर्ड टाइप मिला था, टाइप 99, जिसे सीधे “SPF” कहा जाता था। किसी ने इसे इस्तेमाल नहीं किया। DNS सॉफ्टवेयर वेंडर्स और एडमिन्स SPF पॉलिसी को TXT रिकॉर्ड्स के रूप में ही पब्लिश करते रहे, क्योंकि यह पहले से ही हर जगह काम कर रहा था। RFC 7208 (अप्रैल 2014) तक, IETF ने हार मान ली और डेडिकेटेड SPF रिकॉर्ड टाइप को औपचारिक रूप से डेप्रिकेट कर दिया, और सिर्फ TXT को अनिवार्य बना दिया [9][10]। यह उस दुर्लभ केस का उदाहरण है जिसमें एक बिल्कुल नया रिकॉर्ड टाइप डिफाइन हुआ, लगभग पूरी तरह बेकार रहा, और फिर एक दशक से भी कम समय में आधिकारिक तौर पर खत्म कर दिया गया [10]।
• DKIM (DomainKeys Identified Mail), जिसे लगभग छह साल के डेवलपमेंट के बाद 2011 में RFC 6376 के रूप में स्टैंडर्डाइज़ किया गया, बाहर जाने वाली ईमेल्स में एक क्रिप्टोग्राफिक सिग्नेचर जोड़ता है ताकि रिसीवर्स यह वेरीफाई कर सकें कि मैसेज के साथ छेड़छाड़ नहीं हुई — यह selector._domainkey.yourdomain.com पर एक TXT रिकॉर्ड के रूप में पब्लिश होता है।
• DMARC (Domain-based Message Authentication, Reporting and Conformance) SPF और DKIM को आपस में जोड़ता है, और रिसीविंग सर्वर्स को बताता है कि अगर कोई मैसेज दोनों में फेल हो जाए तो क्या करना है — उसे क्वारंटीन करें, रिजेक्ट करें, या बस उसकी रिपोर्ट करें। यह एक इंडस्ट्री कंसोर्टियम (Google, Microsoft, Yahoo, PayPal, और DMARC.org के तहत अन्य) से निकला और मार्च 2015 में RFC 7489 के रूप में पब्लिश हुआ [11], जो _dmarc.yourdomain.com पर रहता है।

एक रिकॉर्ड टाइप के बजाय तीन अलग-अलग चीज़ें क्यों? क्योंकि ये तीन अलग-अलग ट्रस्ट प्रॉब्लम्स हल करते हैं — भेजने की इजाज़त किसे है (SPF), क्या इस मैसेज को बदला गया (DKIM), और अगर चेक्स फेल हो जाएं तो क्या होना चाहिए, साथ ही मुझे विज़िबिलिटी भी दो (DMARC) — और इन्हें अलग-अलग समूहों ने अलग-अलग समय पर बनाया, जो ईमानदारी से DNS के इवॉल्व होने के तरीके के बिल्कुल मुताबिक है।

2012–2013: TLSA और CAA — सर्टिफिकेट अथॉरिटीज़ के साथ भरोसे की समस्याएं

लगभग 2011–2012 में, वेब PKI सिस्टम — यानी वे सर्टिफिकेट अथॉरिटीज़ (CAs) जो HTTPS के लिए पैडलॉक-आइकॉन सर्टिफिकेट्स जारी करती हैं — के लिए कुछ मुश्किल साल रहे। कई CAs को गंभीर ब्रीचेस का सामना करना पड़ा, जिसने अटैकर्स को ऐसे डोमेन्स के लिए वैलिड सर्टिफिकेट्स जारी करवाने दिए जिनके वे मालिक नहीं थे [12]। बुनियादी समस्या यह थी: आपके ब्राउज़र में मौजूद सैकड़ों ट्रस्टेड CAs में से कोई भी किसी भी डोमेन के लिए सर्टिफिकेट जारी कर सकता है, और डोमेन ओनर के पास यह कहने का कोई तरीका नहीं था कि “सिर्फ इस CA को ऐसा करने की इजाज़त है।”

दो रिकॉर्ड टाइप्स ने इसे अलग-अलग नज़रियों से हल किया:

• TLSA, जिसे RFC 6698 (अगस्त 2012) में DANE (DNS-based Authentication of Named Entities) के हिस्से के रूप में डिफाइन किया गया, किसी डोमेन को वह एग्जैक्ट सर्टिफिकेट या CA पिन करने देता है जिसकी उसे उम्मीद है, और DNSSEC ट्रस्ट एंकर देता है — जो पूरी तरह से पारंपरिक CA सिस्टम को बायपास कर देता है [12]। प्रैक्टिस में, इसे अपनाना ज़्यादातर SMTP मेल सर्वर्स और कुछ XMPP डिप्लॉयमेंट्स तक ही सीमित रहा है [12]।
• CAA, जिसे पहली बार अक्टूबर 2010 में फिलिप हैलम-बेकर (Phillip Hallam-Baker) और रॉब स्ट्रैडलिंग (Rob Stradling) ने ड्राफ्ट किया, और जनवरी 2013 में RFC 6844 के रूप में पब्लिश किया गया — यह एक हल्के तरीके से काम करता है: यह डोमेन ओनर को एक सिंपल पॉलिसी पब्लिश करने देता है जो कहती है “मेरे लिए सर्टिफिकेट्स सिर्फ ये खास CAs ही जारी कर सकती हैं” [13][14]। CA/Browser Forum ने 8 सितंबर 2017 से CAA रिकॉर्ड्स की जांच को सभी पब्लिक CAs के लिए अनिवार्य बना दिया [14], और बाद में नवंबर 2019 में स्पेक को RFC 8659 के रूप में और बेहतर बनाया गया। अगर आपने कभी अपने डोमेन को Let’s Encrypt या DigiCert से लॉक करने के लिए CAA रिकॉर्ड सेट किया है, तो यही वजह है कि यह मौजूद है [15]।

2023: HTTPS और SVCB — DNS कनेक्शंस को लेकर ज़्यादा स्मार्ट हो गया

यह सबसे नई एंट्री है, और इस पर खत्म करना अच्छा है क्योंकि यह दिखाता है कि यह पैटर्न अभी भी पूरी तरह ज़िंदा है।

वेब के इतिहास के ज़्यादातर हिस्से में, किसी साइट पर जाने का मतलब था: A/AAAA रिकॉर्ड के लिए DNS लुकअप → एक TCP कनेक्शन खोलना → एक TLS हैंडशेक करना → फिर HTTP रिक्वेस्ट भेजना। हर स्टेप कुछ-कुछ अंधेरे में होता है — आपके ब्राउज़र को पहले से नहीं पता होता कि सर्वर HTTP/3 सपोर्ट करता है या नहीं, उसके अल्टरनेट एंडपॉइंट्स हैं या नहीं, या उसे कोई स्पेशल TLS कॉन्फिगरेशन चाहिए या नहीं।

SVCB (Service Binding) और HTTPS रिकॉर्ड्स, जिन्हें RFC 9460 (नवंबर 2023) में साथ में स्टैंडर्डाइज़ किया गया, एक सिंगल DNS आंसर को पहले से ही कनेक्शन हिंट्स देने देते हैं — जैसे HTTP/3 जैसे प्रिफर्ड प्रोटोकॉल्स, अल्टरनेट पोर्ट्स, IP हिंट्स, और एन्क्रिप्टेड ClientHello [प्राइवेसी-प्रोटेक्टिंग TLS एक्सटेंशन] के लिए पैरामीटर्स [16]। HTTPS रिकॉर्ड टाइप असल में SVCB का ही एक स्पेशलाइज़्ड वर्शन है जो सिर्फ वेब ट्रैफिक के लिए है, और यह वह काम कर सकता है जो CNAME कभी नहीं कर सका: एक एपेक्स डोमेन (जैसे खुद example.com, न सिर्फ www) को किसी दूसरे नाम का उपनाम (alias) बनाना [16]। ब्राउज़र्स और CDNs अभी भी सपोर्ट रोल आउट कर रहे हैं, लेकिन यह अब तक का सबसे साफ संकेत है कि वेब के अंदरूनी प्रोटोकॉल्स बदलने के साथ-साथ DNS भी खुद को ढालता रहता है।

चीट शीट: आपको असल में कौन सा रिकॉर्ड चाहिए?

अगर आप अभी किसी DNS पैनल को देख रहे हैं और यह समझने की कोशिश कर रहे हैं कि असल में क्या कॉन्फिगर करना है, तो यहाँ एक प्रैक्टिकल मैपिंग है:

अगर ध्यान से देखें, तो एक पैटर्न दिखता है

इस पूरी लिस्ट को शुरू से आखिर तक देखें, तो एक साफ पैटर्न नज़र आता है: DNS को फिर से डिज़ाइन नहीं किया जाता, इसे एक्सटेंड किया जाता है — रिएक्टिव तरीके से, उस समय इंटरनेट जिस संकट से गुज़र रहा होता है उसके जवाब में। एड्रेस खत्म होना → AAAA। प्रोटोकॉल्स का फैलाव → SRV। फोन/इंटरनेट का मिलन → NAPTR। कैश पॉइज़निंग → DNSSEC। स्पैम और फिशिंग → SPF/DKIM/DMARC। CA ब्रीचेस → CAA और TLSA। धीमा कनेक्शन सेटअप → SVCB/HTTPS।

SPF टाइप-99 की कहानी शायद इस पूरी बात में मेरी सबसे फेवरेट डिटेल है — एक बिल्कुल नया रिकॉर्ड टाइप औपचारिक रूप से स्टैंडर्डाइज़ हुआ, लगभग किसी ने इसे नहीं अपनाया, और कुछ साल बाद स्पेक को फिर से लिखकर आधिकारिक तौर पर कहा गया “हाँ, बस TXT इस्तेमाल करो, जैसा सब पहले से कर ही रहे थे” [10]। यह एक याद दिलाता है कि IANA रजिस्ट्री सफल डिज़ाइनों का म्यूज़ियम नहीं है — यह हर उस आइडिया का रिकॉर्ड है जो आज़माया गया, जिनमें से कुछ कामयाब हुए और कुछ खामोशी से फीके पड़ गए।

IANA रजिस्ट्री लगातार बढ़ती जा रही है [16], और इसके रुकने की कोई वजह नज़र नहीं आती। चाहे अगली इंटरनेट-वाइड सिरदर्दी जो भी हो — और हमेशा कोई न कोई पनप ही रही होती है — इस बात की अच्छी संभावना है कि उसका हल किसी की ज़ोन फाइल में एक नए तीन-या-चार-अक्षर वाले कोड के रूप में सामने आएगा।

स्रोत

1. DNS records | Cloudflare Learning Center
2. RFC 1035 - Domain Names: Implementation and Specification (IETF Datatracker)
3. Paul Mockapetris - Wikipedia
4. Celebrating 30 Years of the Domain Name System (DNS) - Internet Society
5. RFC 3596: DNS Extensions to Support IP Version 6
6. SRV record - Wikipedia
7. NAPTR record - Wikipedia
8. RFC 4034: Resource Records for the DNS Security Extensions
9. RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
10. Discontinuing the SPF Record (Type 99) - DNSimple Blog
11. RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
12. RFC 6698: The DNS-Based Authentication of Named Entities (DANE) TLSA Protocol
13. Certification Authority Authorization Checking: What is it, and Why Does it Matter? - DigiCert
14. DNS Certification Authority Authorization - Wikipedia
15. RFC 9460 - Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
16. Domain Name System (DNS) Parameters - IANA
17. DNS record types - Cloudflare Developers