अपने स्वयं के एज डीएनएस (Edge DNS) जैसी चीज़ बनाने की कोशिश पर शोध

नमस्ते, मैं मुनो (Munou) हूँ।

हाल ही में, ConoHa में आउटेज (outages) हुए हैं, और बैकएंड सर्वर (backend servers) कभी-कभी अचानक बंद हो जाते हैं (जो होस्ट मशीन माइग्रेशन (host machine migration) से हल हो गया था), जो परेशान करने वाला है। इसलिए मैं यह पता लगाने की कोशिश कर रहा हूँ कि अपना खुद का एज डीएनएस (Edge DNS) कैसे बनाया जाए।

सीनेम (CNAME) में पंजीकृत रिकॉर्ड के लिए दो ए रिकॉर्ड (A records) पंजीकृत करना

यह इस तरह दिखता है:

$ dig www.soulminingrig.com

; <<>> DiG 9.20.16 <<>> www.soulminingrig.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33051
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.soulminingrig.com.         IN      A

;; ANSWER SECTION:
www.soulminingrig.com.  300     IN      CNAME   edge.soulminingrig.com.
edge.soulminingrig.com. 300     IN      A       91.98.169.80
edge.soulminingrig.com. 300     IN      A       163.44.113.145

;; Query time: 94 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Mon Apr 06 20:40:33 JST 2026
;; MSG SIZE  rcvd: 101

आरएफसी (RFC) नियमों के अनुसार, रूट डोमेन (root domain) के लिए केवल एक CNAME पंजीकृत किया जा सकता है, इसलिए व्यावहारिक रूप से कई पंजीकृत करना संभव नहीं है। इसलिए, हम www.soulmingrig.com के लिए एक CNAME पंजीकृत करते हैं जिसका कंटेंट edge.soulminingrig.com. है, और फिर edge.soulminingrig.com. के लिए दो ए रिकॉर्ड (A records) पंजीकृत करते हैं।

कोई सोच सकता है कि रूट डोमेन (root domain) के लिए सीधे कई ए रिकॉर्ड (A records) क्यों न निर्दिष्ट किए जाएँ, लेकिन मैं इसे भविष्य की स्केलेबिलिटी (scalability) के लिए CNAME के रूप में पंजीकृत कर रहा हूँ।

मैंने यह देखने की कोशिश की कि क्या होगा, और मुझे लगा कि क्या ConoHa का डीएनएस (DNS) PowerDNS का उपयोग करता है? मैंने फिर निम्नलिखित सत्यापित किया:

• सर्वर 91.98.169.80 को रोका

• केवल 163.44.113.145 चल रहा था

अगर यह सिर्फ एक साधारण राउंड-रॉबिन (round-robin) होता, तो मुझे उम्मीद थी कि ट्रैफिक (traffic) कुछ हद तक 91.98.169.80 पर भी जाएगा, लेकिन यह पूरी तरह से केवल 163.44.113.145 पर ही गया। इससे मुझे आश्चर्य हुआ कि क्या PowerDNS, अपनी हेल्थ चेक (health check) क्षमताओं के साथ, उपयोग में हो सकता है।

※कृपया ध्यान दें कि आधिकारिक दस्तावेज़ में केवल राउंड-रॉबिन (round-robin) का उल्लेख है, इसलिए इस धारणा पर भरोसा न करें।

जियोडीएनएस (GeoDNS), मुश्किल है

यह प्रत्येक क्लाइंट (client) को सबसे उपयुक्त क्षेत्र (region) से सामग्री वितरित करने के लिए है, लेकिन जितना अधिक मैं इसके बारे में सोचता हूँ, इसे आसानी से लागू करना उतना ही मुश्किल लगता है।

फ्रीबीएसडी (FreeBSD) पर भी, बहुत कम पैकेज (packages) हैं, और ऐसा लगता है कि GeoIP.bat फ़ाइलों के लिए डेटाबेस (database) भी अब वितरित नहीं किया जा रहा है, लेकिन शायद यह कहीं और वितरित किया जा रहा हो?

https://gist.github.com/denji/9487759

वास्तव में, ऐसा लगता है कि एनजींक्स (Nginx) की तरफ से ट्रैफिक (traffic) को वितरित करना व्यक्तिगत वातावरण में काफी व्यवहार्य हो सकता है। तो, एनजींक्स (Nginx) की तरफ से ट्रैफिक को आसानी से कैसे वितरित किया जाए...?

तो, क्षेत्र-वार गति अंतर का क्या...

इस बार मैंने जो सर्वर (server) जोड़ा वह जर्मनी में स्थित एक अतिरिक्त सर्वर था।

वह 91.98.169.80 है। और जापान से प्रतिक्रिया में देरी काफी गंभीर है।

इसलिए, मैं इसे यथासंभव कम करने के लिए कर्नेल पैरामीटर (kernel parameters) में कॉन्फ़िगरेशन (configuration) परिवर्तन कर रहा हूँ। TCP Fast Open सहित निम्नलिखित जोड़ा गया:

TCP BBR को मूल रूप से सेटअप (setup) के दौरान सक्षम किया गया था, लेकिन मुझे लगता है कि KeepAlive को ठीक से शामिल करने के बाद इसमें और सुधार हुआ है।

net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=10
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_no_metrics_save=1
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_fastopen=3

अगर मैंने इसे ठीक से मापा होता, तो कोई संदेह नहीं होता...

GeoIP का रास्ता अब काफी दूर लग रहा है, इसलिए यह एक अस्थायी समाधान है।

कई ए रिकॉर्ड (A records) वाले एचटीटीपी (HTTP) सर्वर पर प्रमाणपत्र वितरित करना

इसने मुझे काफी सिरदर्द दिया।

बात यह है कि मैं certbot के साथ नवीनीकरण कर रहा हूँ, और मैंने सोचा था कि अगर मैं certbot के साथ डीएनएस (DNS) प्रमाणीकरण का उपयोग करता, तो मैं दो ए रिकॉर्ड (A records) वाले दोनों सर्वर पर प्रमाणपत्र अपडेट (update) कर सकता था, लेकिन यह इतना आसान नहीं था।

निष्कर्षतः, मैं एक समर्पित उपयोगकर्ता (dedicated user) से प्रमाणपत्रों को काफी ज़बरदस्ती rsync कर रहा हूँ।

0 0 1,15 * * /usr/local/bin/certbot renew --nginx --deploy-hook "/usr/local/bin/rsync -azL --no-perms --no-owner --no-group --omit-dir-times --no-times /usr/local/etc/letsencrypt/live/ certsync@10.1.0.999:/usr/local/etc/letsencrypt/live/"

मैं वास्तव में ऐसा नहीं करना चाहता, लेकिन ऐसा लगता है कि आप नवीनीकरण के बाद --deploy-hook का उपयोग करके एक सबशेल (subshell) जैसा स्क्रिप्ट (script) चला सकते हैं।

इसका कारण यह है कि, जब certbot कई ए रिकॉर्ड (A records) वाले सर्वर पर प्रमाणपत्र के लिए एसीएमई (ACME) चुनौती करता है, तो मैंने सोचा था कि यह उनमें से किसी एक पर वितरित हो जाएगा, इसलिए एक सफल होगा और दूसरा विफल। लेकिन किसी कारण से, यह केवल उस सर्वर पर ही पास हुआ जिसने इसे मूल रूप से जारी किया था? (यह विनिर्देश के अनुसार पूरी तरह से समझ में नहीं आता है, इसलिए मुझे लगता है कि इसमें कुछ और है।) डिफ़ॉल्ट certbot के मामले में, इसे फ़ाइल प्रमाणीकरण के लिए एक फ़ाइल को अस्थायी रूप से रखने के लिए डिज़ाइन किया गया है, और एक बार एसीएमई (ACME) चुनौती पास हो जाने के बाद, यह अस्थायी फ़ाइल को तुरंत हटा देता है। इसलिए, एक राउंड-रॉबिन (round-robin) वातावरण में, इसे सैद्धांतिक रूप से उनमें से किसी एक को सौंपा जाना चाहिए।

और DNS प्रमाणीकरण के संबंध में, मैंने इसका उपयोग करना बंद कर दिया क्योंकि --nginx विकल्प, जो स्वचालित रूप से nginx की तरफ प्रमाणपत्र फ़ाइलों को गतिशील रूप से जोड़ता है, का उपयोग नहीं किया जा सकता था। लेकिन चूंकि प्रमाणपत्र पथ वास्तव में बदलते नहीं हैं, मुझे अब एहसास हुआ कि DNS प्रमाणीकरण बेहतर होता – मैं तब पूरी तरह से नींद में था...

ConoHa एपीआई (API) के माध्यम से डीएनएस (DNS) रिकॉर्ड परिवर्तनों को सूचित करना वास्तव में संभव है, इसलिए यह एक ऐसा मामला है जिसे उस तरह से हल किया जा सकता है...