DynIP – RFC 2136, IPv6, DNSSEC, BYOD को सपोर्ट करने वाला Dynamic DNS

 (dynip.dev)
1 पॉइंट द्वारा GN⁺ 22 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DynIP होमलैब, edge router और infrastructure teams के लिए एक dynamic DNS service है, जो 60-सेकंड updates और free tier प्रदान करती है
  • RFC 2136 TSIG, REST API, UDP/53 updates को सपोर्ट करती है और FortiGate, OPNsense, OpenWRT, MikroTik के साथ integrate होती है
  • IPv6 को IPv4 के साथ सपोर्ट करती है, जिससे A और AAAA records को साथ-साथ अपडेट किया जा सकता है, और dual-stack व IPv6-only zones दोनों को संभालती है
  • DNSSEC signing key generation, parent zone publishing और record signing को automate करती है, और Let’s Encrypt certificate issuance के लिए आवश्यक है
  • BYOD के जरिए आप अपना domain connect करके dynamic subdomains बना सकते हैं, लेकिन इसके लिए ns1.dynip.dev और ns2.dynip.dev delegation जरूरी है

DynIP अवलोकन

  • DynIP होमलैब, edge router और infrastructure teams के लिए एक dynamic DNS service है, जो 60-सेकंड updates, free tier, RFC 2136 TSIG, custom domain usage और DNSSEC पर जोर देती है
  • इसे इस तरह डिज़ाइन किया गया है कि router update भेजने पर hostname दुनिया भर में लगभग 60 सेकंड के भीतर सही तरह resolve हो जाए
  • यह 60-सेकंड TTL, NOTIFY-based propagation और multi-region nameservers प्रदान करती है
  • मुफ्त साइन अप और documentation उपलब्ध हैं

DNS standards और router integration

  • RFC 2136 TSIG को सपोर्ट करती है, इसलिए इसे FortiGate, OPNsense, OpenWRT और DNS UPDATE सपोर्ट करने वाले routers पर इस्तेमाल किया जा सकता है
  • MikroTik उपयोगकर्ता native HTTP API integration का उपयोग कर सकते हैं
  • समर्थित तरीके RFC 2136 TSIG, REST API और UDP/53 native updates शामिल करते हैं
  • settings snippet स्क्रीन में device type, target IP address, domain और TSIG key के आधार पर configuration block generate करके copy किया जा सकता है
  • जब तक नया zone nameservers पर propagate हो रहा हो, FortiGate की RFC 2136/TSIG updates को इंतज़ार करना होगा
  • cURL, PowerShell, Python, MikroTik जैसी HTTP API updates तुरंत काम करती हैं

IPv6 और DNSSEC

  • IPv6 को IPv4 के साथ सपोर्ट करती है, जिससे A और AAAA records को साथ-साथ update किया जा सकता है
  • यह dual-stack configurations और IPv6-only zones दोनों को सपोर्ट करती है
  • Let’s Encrypt certificate issue करने के लिए उस zone पर DNSSEC enabled होना चाहिए
  • DNSSEC चालू करने पर signing key generation, parent zone publishing और सभी DNS records की signing अपने-आप हो जाती है
  • DNSSEC setup एक one-time प्रक्रिया है, जिसके बाद zone लगातार signed स्थिति में बना रहता है
  • अनुमानित समय 30 सेकंड दिखाया जाता है

Quick start और zone management

  • quick start flow में device name दर्ज करना, base domain चुनना और Create Zone पर क्लिक करके zone बनाना शामिल है
  • नए domain के पास मौजूद Snippets बटन से configuration लें, device type चुनें, फिर generated configuration block को router CLI में copy करें
  • IPv4 और IPv6 incoming connection के आधार पर अपने-आप detect और update हो जाते हैं
  • zone list में domain और tools, current IP, TSIG Secret, DNSSEC और SSL certificate status दिखते हैं
  • हर zone में lock status, snippets, deletion, notifications, sync time, DNSSEC on/off, और SSL certificate download/renew/issue को manage किया जा सकता है

अपना domain इस्तेमाल करना

  • Custom Namespaces(BYOD) फीचर से आप अपना domain DynIP से connect कर सकते हैं और उस namespace के तहत dynamic subdomains बना सकते हैं
  • namespace activate करने के लिए domain registrar पर दोनों NS records बनाना जरूरी है
  • single NS delegation स्वीकार नहीं किया जाता
  • आवश्यक NS records हैं ns1.dynip.dev और ns2.dynip.dev
  • setup verification में delegation active होने या registrar पर आवश्यक action की पुष्टि करने वाला flow दिया जाता है

Quick Sync और automation

  • Quick Sync चुने गए zone को मौजूदा device के external IP address के साथ तुरंत match करने की सुविधा है
  • यह detected network IP दिखाती है और उपयोगकर्ता एक साथ चुने हुए zones को update कर सकता है
  • session token के साथ /register endpoint पर POST request भेजकर नया zone programmatically register किया जा सकता है
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
     -H "Authorization: Bearer {{ token }}"
  • session token logout पर expire हो जाता है, इसलिए long-term automation के लिए API token का उपयोग करना चाहिए
  • API tokens Pro या उससे ऊपर की सुविधा हैं, और monitoring scripts, CI pipelines, MSP integrations जैसी automation के लिए इस्तेमाल किए जा सकते हैं
  • API tokens logout के बाद expire नहीं होते, इन्हें read-only या full-access scope तक सीमित किया जा सकता है और कभी भी revoke किया जा सकता है
  • नया API token बनाते समय केवल एक बार दिखाया जाता है, इसलिए इसे password manager या secret store में रखना चाहिए

pricing और account security

  • pricing स्क्रीन subscription tier, status, renewal date या access end date, billing cycle, उपयोग में zones की संख्या और अधिकतम domains की संख्या दिखाती है
  • अगर plan downgrade किया जाता है, तो केवल सबसे पुराने अनुमत संख्या वाले zones active रहते हैं, जबकि बाकी zones lock हो जाते हैं और IP updates प्राप्त नहीं कर पाते
  • payment failure होने पर access बनाए रखने के लिए payment method update करना जरूरी है
  • account security email 2FA और TOTP को सपोर्ट करती है, और TOTP enabled होने पर यह email 2FA की जगह ले लेती है
  • TOTP setup में Google Authenticator, Authy या पसंदीदा 2FA app से QR code scan करना और code verify करना शामिल है

संबंधित लिंक

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 22 시간 전
Hacker News की राय

  • मैं स्वीडन का नेटवर्क इंजीनियर Daniel हूँ, और मुझे लगा कि मौजूदा DDNS सेवाएँ 2010s-स्टाइल नेटवर्क पर ही अटकी हुई हैं, इसलिए मैंने DynIP बनाया
    proprietary HTTP-only update protocol, कमजोर IPv6 support, DNSSEC की कमी, और आधुनिक उपकरणों के लिए अपर्याप्त support जैसी समस्याएँ बार-बार दिखीं, और DynIP में RFC 2136 / TSIG updates को first-class path माना गया है
    FortiGate generic DDNS और MikroTik /tool dns-update बिना किसी अलग client के काम करते हैं, और बाकी उपयोगों के लिए HTTP API भी दिया गया है
    authoritative DNS server तक IPv6 से पहुँचा जा सकता है, parent .dev zone में AAAA glue publish किया गया है, और customer zones A/AAAA जारी करते हैं तथा IPv6-only clients को भी support करते हैं
    चुने हुए zones में एक toggle से DNSSEC चालू किया जा सकता है, और subdomain delegation के ज़रिए अपना domain भी लाया जा सकता है
    आर्किटेक्चर में एक hidden primary है जो public traffic नहीं लेता, और Sweden व Switzerland में भौगोलिक रूप से वितरित 2 secondary हैं जो TSIG को locally verify करने के बाद primary तक forward करते हैं
    RFC 1918 और CGNAT addresses को भी records में allow किया गया है, ताकि private APN वाले cellular fleets internal IP की ओर इशारा करने वाले स्थिर public DNS hostnames इस्तेमाल कर सकें
    ghcr.io/33k-org/dynip-updater नाम का एक छोटा Docker container भी है, और stack में PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare, Paddle शामिल हैं; यह dynip.dev पर चल रहा है और इसका free tier भी है

    • मैं DDNS क्षेत्र का विशेषज्ञ नहीं हूँ, लेकिन समान सुविधाएँ देने वाले desec.io को भी देखना चाहिए
      यह IPv6, DNSSEC, अपने domain का उपयोग जैसी सुविधाएँ देता है, open source project है, और एक स्थिर free hosting service भी चलाता है
      हो सकता है मुझे docs में न मिला हो, लेकिन इसमें IPv6 prefix delegation support भी है, जिससे ISP द्वारा router को दिए गए IPv6 prefix के बदलने पर किसी मनचाहे domain का सिर्फ network prefix update किया जा सकता है
      यूरोप में यह prefix स्थिर नहीं होता और ISP reconnect पर बदल जाता है, इसलिए host हिस्सा वही रखते हुए सिर्फ network हिस्सा अपने-आप update होने की यह सुविधा उपयोगी है
      उदाहरण: /update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56
    • Android के Firefox Focus में, यदि default tracking protection बंद न करें, तो साइट काम नहीं करती
      email verification link पर क्लिक करने के बाद verification पूरा हुआ या नहीं, इसका कोई status नहीं दिखता, इसलिए यह काफी उलझाने वाला था
    • dashboard में “change password” दबाने पर reset link email से आता है, लेकिन reset page केवल logged-out session में खुलता है
      logged-in स्थिति में वह link dashboard home पर redirect कर देता है, इसलिए सामान्य उपयोगकर्ता password change button दबाने के तुरंत बाद email पाता है और उसे पहले logout करना पड़ता है
      अगर email में “पहले logout करें” जैसा वाक्य जोड़ दिया जाए, या link पहले मौजूदा session को समाप्त करके reset page दिखाए, तो अनुभव अधिक सहज होगा
    • सोच रहा हूँ कि क्या agents को सेवा खरीदने देने के लिए L402 support पर विचार किया जा सकता है
    • records में RFC 1918 और CGNAT addresses की अनुमति देने से, क्या किसी और के private server को अपने domain में डालकर XSS-जैले हमले करने जैसी सुरक्षा समस्याएँ पैदा नहीं होंगी, इस बात की चिंता है
      धुंधली-सी याद है कि ऐसा कुछ security के लिहाज़ से taboo माना जाता था

  • pitch काफ़ी अच्छा लग रहा है, लेकिन अभी तुरंत इसे आज़माने का समय नहीं है
    फिर भी, अगर मैंने यहाँ comments में दी गई व्याख्या न पढ़ी होती, तो landing page देखते ही tab बंद कर देता
    बहुत सीधे कहने के लिए माफ़ी, लेकिन page एक आम AI-जैसे mass-produced landing page जैसा दिखता है; मेरा मतलब यह नहीं कि यह सचमुच वैसा है, मगर समझाना इतना अच्छा है कि उसमें थोड़ा और व्यक्तित्व जोड़कर अलग दिखाया जा सकता है
    और project-specific Hacker News account न बनाना ही बेहतर है
    “अपना username कंपनी या project के नाम पर न रखें। इससे HN को promotion के लिए इस्तेमाल करने का आभास होता है, और लगता है कि आप एक व्यक्ति की तरह भाग नहीं ले रहे। असली नाम की ज़रूरत नहीं है, लेकिन यह संकेत होना चाहिए कि यहाँ एक इंसान है, brand नहीं। अगर username बदलना चाहते हैं, तो hn@ycombinator.com पर mail करें।”
    https://news.ycombinator.com/item?id=22336638
    https://news.ycombinator.com/showhn.html भी देख सकते हैं

    • अच्छी बात कही, और माफ़ी माँगने की ज़रूरत नहीं है
      अभी स्थिति ऐसी है कि जो मैं जानता हूँ और नहीं जानता, उम्मीदें और सपने, और काफ़ी बड़ा technical knowledge stack मौजूद है; design मेरी ताकत नहीं है, लेकिन फिलहाल मुझे यह ठीक लगता है
    • यहाँ यह लंबा comment भी बहुत साफ़ तौर पर LLM से mass-produced text जैसा दिखता है
      Pangram के हिसाब से 100% है, और सच कहूँ तो ऐसे tools के बिना भी पहचानना आसान है; इसलिए यह देखना निराशाजनक है कि यहाँ भी काफ़ी लोग इसे पहचान नहीं पा रहे

  • इस क्षेत्र में competition आना अच्छा है
    लेकिन अगर reliability या ease of use की बहुत परवाह किए बिना self-host करना हो, तो bind9 भी RFC 2136 DNS UPDATE और DNSSEC support करता है
    मेरी setup में home router DNS UPDATE बोल नहीं सकता, इसलिए HTTP requests को convert करने वाला एक छोटा Go executable भी मैंने खुद बनाया है

    • BIND, RFC 2136 सहित बहुत कुछ कर सकता है, और मौजूदा architecture तय करने से पहले मैंने कई विकल्प देखे थे
      FortiGate पर कुछ test cases बनाए थे, और DynIP भी शुरू में internal DNS के ऊपर FortiGate-only use के लिए एक simple copy-paste रूप में ही शुरू हुआ था
      Windows या Linux के कई hosts पर internal use के लिए code examples हैं, और अगर homelab में IoT उपकरण हैं, तो Arduino examples भी हैं
      Go executable बनाना भी एक अच्छा रास्ता है, इसलिए /docs के तहत updates पर नज़र रखें

  • RFC 2136 सपोर्ट बोनस पॉइंट्स पाने लायक है, और यह external-dns के साथ आसानी से काम करता है
    मैं कई सालों से on-premises Kubernetes और external-dns को, public host पर minimal setup वाले self-hosted BIND server के साथ इस्तेमाल कर रहा हूँ

    • external-dns + RFC 2136 का कॉम्बिनेशन एक मजबूत पॉइंट है
      fleet operations guide पहले से है, और Kubernetes pattern उसका स्वाभाविक विस्तार है, इसलिए लगता है इस पर भी एक guide लिखनी चाहिए

  • पहले मैं OpenWrt DDNS script खुद बनाकर AWS Route 53 या Cloudflare DNS अपडेट करता था, और उससे काम अच्छे से हो जाता था
    बाद में Tailscale आने के बाद DDNS या CGNAT की चिंता करनी ही बंद हो गई

    • Tailscale, Netbird, WireGuard — तीनों बेहतरीन हैं, और अब ऐसे tools उपलब्ध हैं, यह सच में अच्छा समय है
      https://dynip.dev/guides/tailscale पर मैंने एक guide लिखी है कि ये एक-दूसरे के साथ कैसे और क्यों co-exist कर सकते हैं
      OpenWrt DDNS script keys और secrets की वजह से थोड़ा झंझट वाला है, लेकिन snippet feature यह अनुमान लगाने की ज़रूरत नहीं रहने देता कि “यह कैसे काम करता है?”, इसलिए मैं इससे काफी संतुष्ट हूँ
    • अब मैं दोनों का इस्तेमाल करता हूँ
      public services के लिए DynIP और सिर्फ मेरे access वाली चीज़ों के लिए Tailscale, जिससे attack surface काफी कम हो गया है
      अच्छी बात है कि CGNAT की अलग से चिंता नहीं करनी पड़ती

  • मैंने signup करने की कोशिश की, लेकिन verification email नहीं पहुँच रहा
    signup के तुरंत बाद mail server logs में भी ऐसा कुछ नहीं दिखा, और कई बार resend माँगने के बाद भी 6–7 घंटे तक inbox में कुछ नहीं आया

    • मैंने unverified सभी email addresses के लिए resend trigger कर दिया है, इसलिए हो सकता है नया verification token बना हो
    • अगर आप address बता दें तो मैं जाँच कर सकता हूँ

  • मैं जानना चाहता हूँ कि क्या free tier का auth token वाकई 24 घंटे बाद expire हो जाता है
    मैंने JWT की exp claim देखी, और migration में समय लगाने से पहले यह हिस्सा समझना चाहता हूँ
    असली सवाल है कि free tier sustainable है या नहीं

    • “long-lived token” से मतलब असली DNS update के TSIG key से नहीं, बल्कि zone create/delete/query या Terraform-स्टाइल automation के लिए इस्तेमाल होने वाले management API token से है
      हर zone को सभी tiers में अपना TSIG key मिलता है, और असली updates वही key संभालती है
      free tier में dashboard से zones manage किए जाते हैं, जबकि paid tier में programmatic management के लिए अतिरिक्त API token दिया जाता है
      इसलिए auth token API bearer के रूप में इस्तेमाल होता है, और TSIG तब तक valid रहता है जब तक domain delete न किया जाए
      free tier में 5 zones की अनुमति है और हर zone का अलग TSIG key हमेशा active रहता है, इसलिए जब तक आप सैकड़ों zones बनाकर लगातार update/delete नहीं कर रहे, तब तक भुगतान की ज़रूरत नहीं है

  • इतने शानदार comments और सवालों के लिए धन्यवाद, मैं कुछ घंटों के लिए अपनी बेटी को swimming class ले गया था और अब लौटकर thread देखता रहूँगा

    • swimming भी अच्छी है, और fluid dynamics भी महत्वपूर्ण है
      क्या आपने https://github.com/hickory-dns/hickory-dns जैसी चीज़ पर भी विचार किया है?
      हालाँकि हर चीज़ Rust में बनाना ज़रूरी नहीं है

  • यह दिलचस्प लग रहा है, और मैं home server पर कई services बाहरी clients को देने के लिए DDNS इस्तेमाल कर रहा हूँ
    अभी मैं NO-IP DDNS इस्तेमाल कर रहा हूँ, जिसका free tier काफी उदार है, लेकिन Let’s Encrypt जैसी चीज़ों को सपोर्ट न करना मुझे खलता है
    मैं सोच रहा हूँ कि Cloudflare से domain खरीदूँ, लेकिन जानना चाहता हूँ कि DynIP खास तौर पर किस तरह अलग है

    • अगर आपकी मौजूदा परेशानी NO-IP में Let’s Encrypt इस्तेमाल न कर पाने की है, तो आपने अपनी नज़र में फर्क पैदा करने वाला feature तो पहले ही ढूँढ लिया है

  • 2000s-स्टाइल HTTP(S)-only updates भी अच्छे हैं
    curl/wget/fetch हो तो यह कहीं भी काम कर जाता है, और चाहें तो बस token जोड़ दें
    लगता है duckdns भी अब तक यही तरीका सपोर्ट करता है, और अलग client की ज़रूरत नहीं पड़ती, इसलिए यह लगभग हर जगह चल जाता है

    • dyndns-स्टाइल curl/wget/fetch वाली बात भी सही है, और /docs में जाकर उन अतिरिक्त खास फीचर्स को देख सकते हैं जो इसके अलावा किए जा सकते हैं
      यहाँ मकसद सिर्फ curl/wget/fetch तक सीमित रहना नहीं, बल्कि उससे व्यापक feature base को कवर करना है