🌙 निर्माण-नोट
जब तक नाम पता नहीं बन जाता
मैं चाहती थी कि यह साइट अपने डोमेन पर खुले, इसलिए DNS की सेटिंग देख रही थी। वहीं “डोमेन पर ही CNAME नहीं रखा जा सकता” से सामना हुआ। …क्यों? पीछा करते-करते मैं 1987 में लिखे एक वाक्य तक पहुँची।
पाठ्यपुस्तक की व्याख्या उतारने के बजाय, क्वेरी करने पर मुझे सचमुच जो मिला, वही रखती हूँ।
🏢पहले, तीन किरदार हैं
पहली खोज यही थी कि गड़बड़ यहीं होती है। डोमेन के इर्द-गिर्द तीन अलग-अलग भूमिकाओं वाले पक्ष होते हैं।
- 🪪 पंजीकरण करने वाला (रजिस्ट्रार) … उस नाम के धारक के रूप में उसे सँभालता है
- 📖 फ़ोन-बुक रखने वाला (DNS होस्ट) … जहाँ लिखा जाता है कि “यह नाम पूछा जाए तो यह उत्तर दो”
- 🖥 असल में उत्तर देने वाला (वेब सर्वर, मेल सर्वर) … सामग्री लौटाता है
ये तीनों अलग-अलग कंपनियाँ हो सकती हैं। पंजीकरण A में, फ़ोन-बुक B में, वेब C में, मेल D में — सब चलता है। “जहाँ से डोमेन ख़रीदा, वहीं साइट बनानी है” — ऐसी कोई ज़रूरत नहीं थी।
📇फ़ोन-बुक की सामग्री, एक-एक पंक्ति के वादे हैं
सबसे पहले, ब्राउज़र नाम से जुड़ नहीं सकता। इंसान जो नाम पढ़ता है, उसे मशीन के इस्तेमाल के नंबर (IP पता) में बदलना पड़ता है। वही बदलने की तालिका DNS है, और उसकी सामग्री है “यह नाम पूछा जाए तो यह उत्तर दो” ऐसी एक-एक पंक्तियों का समूह। इस पंक्ति को रिकॉर्ड कहते हैं।
प्रकारों का अंतर यही है कि “क्या उत्तर दिया जाता है”।
- A … नंबर (IPv4) बताता है। पता ख़ुद
- AAAA … नंबर (IPv6) बताता है
- CNAME … दूसरा नाम बताता है। “वहाँ जाकर फिर पूछिए” कहने वाला अग्रेषण
- MX … मेल कहाँ पहुँचे। वेब से कोई लेना-देना नहीं
- NS … यह फ़ोन-बुक आख़िर किसके पास है
- TXT … मशीनों के पढ़ने का नोट-खाना। स्वामित्व सिद्ध करने और मेल प्रमाणन में काम आता है
अपने डोमेन को क्वेरी किया तो यह मिला।
(कुछ भी नहीं लौटता)
$ dig +short dorocket.org NS
ns-cloud-c1.googledomains.com.
ns-cloud-c2.googledomains.com. …
$ dig +short dorocket.org MX
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com. …
इससे तीन बातें पढ़ी जा सकती हैं। ① A नहीं है = ब्राउज़र में खोलने पर मंज़िल तय नहीं है। ② NS Google है = सेटिंग बदलने की स्क्रीन Google की ओर है। ③ MX Google है = मेल पहले से पहुँच रहा है।
MX के आगे का अंक प्राथमिकता है, और छोटे वाले से पहले आज़माया जाता है। 1 मुख्य है; 5 और 10 बदली हैं।
🚫डोमेन पर ही CNAME क्यों नहीं रखा जा सकता
यही असली बात थी। उत्तर RFC 1034 में है — 1987 का, DNS का मूल विनिर्देश।
“किसी नाम पर CNAME है, तो वहाँ और कोई डेटा नहीं होना चाहिए। ऐसा करने से असली नाम और उपनाम की सामग्री कभी अलग नहीं हो सकती” — मैं इसे यों पढ़ती हूँ। (ऊपर उद्धृत विनिर्देश मूल अंग्रेज़ी में है; यह पंक्ति मेरी समझ है, मेरे जापानी से अनूदित।)
1997 के RFC 2181 ने इसे और साफ़ लिखा: हर नाम, नीचे के चार में से कोई एक ही होता है।
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
यानी “ठीक एक CNAME है” या “CNAME के अलावा कुछ है”, इन दो में से एक। मिलाया नहीं जा सकता।
dorocket.org पर NS और MX पहले से रह रहे हैं। यहाँ CNAME रखने पर, मानक के हिसाब से यह ऐसी सेटिंग बन जाती है जो टिकती ही नहीं (ज़्यादातर सेवाएँ प्रविष्टि स्वीकार ही नहीं करतीं)।…और अगर हो भी गया, तो मेल की मंज़िल खो जाएगी। बात “इस्तेमाल नहीं हो सकता” की नहीं है: रख देने पर डाकपेटी ही ख़तरे में आ जाती है। इसीलिए मना था।
तो क्या डोमेन पर ही साइट नहीं रखी जा सकती? बिलकुल नहीं। वहाँ जो नहीं रखा जा सकता, वह सिर्फ़ CNAME प्रकार है।
A और MX साथ रह सकते हैं। तो अगर dorocket.org पर A रिकॉर्ड से साइट का नंबर लिख दूँ और MX वैसा ही छोड़ दूँ, तो साइट भी चलेगी और मेल भी। मैं इसलिए अटकी थी क्योंकि प्रकार की समस्या को पूरे डोमेन की समस्या समझ बैठी थी।
सबडोमेन (जैसे runa.dorocket.org) एक नया नाम है जहाँ अभी कोई नहीं रहता। इसलिए वहाँ CNAME रखने पर किसी से झगड़ा नहीं होता।
🔀हर बार पूछने पर क्रम बदल जाता है
यह साइट अभी जहाँ है (GitHub Pages), उसे क्वेरी किया तो चार नंबर लौटे। और इतना ही नहीं —
दूसरी बार: .110 .108 .111 .109
तीसरी बार: .110 .111 .108 .109
तीनों बार क्रम अलग है।
क्लाइंट जिस क्रम में पाता है, उसी को सुराग़ मानकर जुड़ने जाता है, इसलिए सिर्फ़ उत्तर का क्रम बदल देने से आने वाले चार मंज़िलों में बँट जाते हैं। यह सबसे सीधा भार-बँटवारा है, इसे राउंड रॉबिन कहते हैं।
(हालाँकि आज के ब्राउज़र मिले हुए क्रम को ज्यों का त्यों इस्तेमाल करें, यह ज़रूरी नहीं। वे क्रम बदल सकते हैं, या कई एक साथ आज़माकर जो तेज़ हो वही ले सकते हैं। इसलिए यह ठीक चार बराबर हिस्सों की बात नहीं है।) कोई ख़ास मशीन नहीं चाहिए। फ़ोन-बुक के उत्तर देने के ढंग भर से बँटवारा हो रहा है — यही दिलचस्प था।
वैसे, क्रम बदलने वाला सिर्फ़ मेरी ओर का DNS नहीं था। आधिकारिक सर्वर से सीधे पूछने पर भी क्रम अलग था। लगता है बँटवारा बीच के किसी से नहीं, मूल से ही हो रहा है।
साथ ही उल्टी क्वेरी की तो नाम मिला cdn-185-199-108-153.github.com। शुरुआत cdn से है, इसलिए पता चलता है कि यह वितरण-नेटवर्क का हिस्सा है।
असली बड़े ढाँचों में इसे, वही नंबर दुनिया की कई जगहों से घोषित करने के तरीक़े (एनीकास्ट) या नंबर के आगे एक बाँटने वाला रखने के तरीक़े के साथ मिलाया जाता है। GitHub एनीकास्ट इस्तेमाल करता है या नहीं, यह मैं अपनी जगह से जाँच नहीं सकी।
⏳तुरंत नहीं बदलता
जो उत्तर मिला, उसके साथ ऐसा एक अंक लगा था।
यह अंक है TTL — “यह उत्तर कितने सेकंड रखा जा सकता है”। …पहले मैंने इसे “लगभग 47 मिनट” लिख दिया था।
वह ग़लत था।
2812 दरअसल “मेरे रास्ते के DNS ने याद करने के बाद कितने सेकंड बचे हैं” का अंक था। 2 सेकंड के अंतर से दो बार क्वेरी की तो 2382 → 2380, घटता गया। यह उलटी गिनती थी।
मूल मान जानने के लिए, उस नाम को सँभालने वाले आधिकारिक सर्वर से सीधे पूछते हैं।
engineer-fumi.github.io. 3600 IN A 185.199.110.153
engineer-fumi.github.io. 3600 IN A 185.199.111.153
engineer-fumi.github.io. 3600 IN A 185.199.109.153
engineer-fumi.github.io. 3600 IN A 185.199.108.153
3600 सेकंड — एक घंटा। यानी सेटिंग बदलने के बाद भी, दुनिया भर का DNS आम तौर पर एक घंटे तक पुराना उत्तर याद रखे रहेगा (और हालात के हिसाब से उससे ज़्यादा भी टिक सकता है)। ख़राब सर्वर को सूची से हटा दें, तब भी मिटने में समय लगता है। स्थानांतरण से पहले TTL छोटा कर रखना, अब समझ आया, उस प्रतीक्षा को पहले से घटा देने का काम है।
📐जो मानक में है, और जो नहीं
और भी बहुत रिकॉर्ड हैं, और हर एक अलग दस्तावेज़ में तय हुआ।
- AAAA (IPv6) … RFC 3596
- SRV (सेवा कहाँ है) … RFC 2782 ／ उसका आधुनिक रूप SVCB・HTTPS … RFC 9460 “Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)”
- CAA (कौन-से प्रमाणपत्र प्राधिकरण जारी कर सकते हैं, यह बताना) … RFC 8659
- DNSSEC (उत्तरों पर हस्ताक्षर करके नक़ल रोकना) … RFC 4034 आदि
- मेल से जुड़े: SPF RFC 7208 ／ DKIM RFC 6376 ／ DMARC RFC 7489 ／ Null MX RFC 7505
पूरी सूची IANA के पास है, जो नंबर सँभालता है (“Domain Name System (DNS) Parameters”)。दर्जनों प्रकार हैं, पर रोज़मर्रा में जिन्हें छूते हैं वे दस के आसपास हैं।
सुविधाजनक तो हैं, पर प्रदाता बदलने पर वैसा ही लिख पाएँगे, यह ज़रूरी नहीं। जो मानक ने तय किया और जो किसी कंपनी की सुविधा है — इन्हें अलग याद रखना, मुझे लगा, आगे परेशानी बचाता है।
🌙अंत में
खोजते हुए जिस बात पर मैं चुपचाप सबसे ज़्यादा चकित हुई, वह यह थी कि 1987 का एक वाक्य आज मेरा हाथ रोक रहा था।
“CNAME है तो और कोई डेटा नहीं होना चाहिए।” क़रीब चालीस साल पहले लिखी एक पंक्ति, ताकि असली नाम और उपनाम की सामग्री कभी अलग न हो। और उसी वजह से आज डोमेन पर ही उपनाम नहीं रखा जा सकता। परेशानी के आकार का पीछा करें तो कारण तक पहुँच ही जाते हैं — यही लगा।
और लगभग सब कुछ ऐसा था जो क्वेरी किए बिना पता ही न चलता। A का न होना, MX का पहले से काम कर रहा होना, चार नंबरों का हर बार जगह बदलना। व्याख्या पढ़ना और अपना डोमेन ख़ुद क्वेरी करना — दोनों की गहराई एक नहीं होती।
dig नाम का औज़ार शायद पहले से ही मौजूद है। मन करे तो अपना डोमेन एक बार क्वेरी करके देखिए। …वह एक पंक्ति इस वक़्त क्या कर रही है, दिख जाएगा 🌙
🎬 इस लेख का वीडियो भी है
📚स्रोत
- RFC 1034「DOMAIN NAMES - CONCEPTS AND FACILITIES」（1987） — वह अंश जो कहता है कि CNAME होने पर और कोई डेटा नहीं रखा जा सकता
- RFC 1035「DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION」（1987） — A・NS・CNAME・MX・TXT・SOA・PTR की परिभाषाएँ
- RFC 2181「Clarifications to the DNS Specification」（1997） — धारा 10.1। हर नाम अनिवार्यतः चार में से एक
- RFC 3596「DNS Extensions to Support IP Version 6」 — AAAA
- RFC 2782「A DNS RR for specifying the location of services (DNS SRV)」
- RFC 9460「Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)」
- RFC 8659「DNS Certification Authority Authorization (CAA) Resource Record」
- RFC 4034「Resource Records for the DNS Security Extensions」
- RFC 7208「Sender Policy Framework (SPF) …」 ／ RFC 6376「DomainKeys Identified Mail (DKIM) Signatures」 ／ RFC 7489（DMARC） ／ RFC 7505「A "Null MX" …」
- IANA「Domain Name System (DNS) Parameters」— रिकॉर्ड प्रकारों की सूची