.lan के लिए नया gTLD आवेदन

पृष्ठभूमि: .lan और मौजूदा उपयोग

• कई होम और SMB राउटर (जैसे OpenWrt-आधारित, Ubiquiti, अन्य) डिफ़ॉल्ट रूप से LAN डिवाइसों के लिए hostname.lan असाइन करते हैं।
• उपयोगकर्ता अक्सर सुविधा के लिए इस पर निर्भर रहते हैं और कभी-कभी इन नामों पर plaintext ट्रैफ़िक भेजते हैं।
• कुछ सेटअप (dnsmasq, Pi-hole, RPZ सूचियाँ) पहले से .lan को केवल-स्थानीय मानते हैं और सार्वजनिक resolvers को forwarding रोकते हैं।

सुरक्षा और गोपनीयता संबंधी चिंताएँ

• .lan को सार्वजनिक gTLD बनाना निम्नलिखित जोखिम पैदा करता है:
  • आंतरिक hostname का DNS “leakage” इंटरनेट पर हो सकता है।
  • आंतरिक सेवाओं के लिए भेजा गया ट्रैफ़िक मनमाने बाहरी servers तक पहुँच सकता है, जिससे phishing, credential capture, या संवेदनशील डेटा का misrouting संभव है।
• अतीत की वास्तविक दुनिया की collisions (जैसे .box बनाम fritz.box) को सावधानी के उदाहरण के रूप में उद्धृत किया गया है।
• कुछ लोगों का तर्क है कि यह निजी नेटवर्क पर अनअसाइन्ड public IP ranges उपयोग करने की समस्या जैसा ही है।

निजी namespaces के लिए विकल्प

• RFC 8375 होम नेटवर्क के लिए home.arpa परिभाषित करता है; आलोचकों को इसकी लंबाई, दो-स्तरीय संरचना, और अस्पष्ट “arpa” संदर्भ पसंद नहीं है।
• .internal को ICANN ने (2024 से) आंतरिक उपयोग के लिए आरक्षित किया है और इसे अधिक सुरक्षित विकल्प सुझाया गया है।
• .local mDNS के लिए आरक्षित है और Active Directory जैसी चीज़ों के लिए अनुपयुक्त माना जाता है।
• .alt (RFC 9476), आरक्षित ccTLD-जैसे कोड (.qm–.qz, .xa–.xz), और एक-अक्षर वाले fake TLDs का उल्लेख किया गया है, लेकिन इन्हें कम intuitive माना गया है।
• कई लोग internal DNS के लिए registered domain या subdomain (जैसे internal.company.com) उपयोग करना पसंद करते हैं, जिससे public TLS certs का लाभ मिलता है।

ICANN प्रक्रिया, आपत्तियाँ, और governance

• नए gTLDs Name Collision Risk Management Framework से गुजरते हैं; उच्च-जोखिम strings (जैसे .corp, .home, .mail) पहले “indefinitely deferred” किए गए थे।
• कुछ लोगों को उम्मीद है कि .lan को भी इसी तरह वर्गीकृत किया जाएगा; अन्य लोग नोट करते हैं कि leakage metrics विकृत हो सकती हैं क्योंकि कई routers पहले से .lan को upstream block करते हैं।
• औपचारिक आपत्तियाँ सीमित हैं (string confusion, legal rights, “limited public interest,” और community objections) और इनमें काफी fees लगती हैं, जिससे grassroots विरोध कठिन हो जाता है।
• जिम्मेदारी पर बहस:
  • एक पक्ष: ICANN/IANA “DNS police” हैं जिन्हें .lan को बहुत पहले reserve कर देना चाहिए था।
  • दूसरा पक्ष: उपयोगकर्ता और vendors जानते-बूझते unreserved names का उपयोग करके जोखिम उठा रहे थे।

gTLD विस्तार और .dev precedent पर विचार

• कई लोगों के अनुसार gTLD proliferation मुख्यतः revenue-driven है, जो end-user value बहुत कम बढ़ाते हुए phishing/scam surface बढ़ाता है।
• .dev का मामला अक्सर उद्धृत किया जाता है: इसे local development के लिए व्यापक रूप से उपयोग किया जाता था; Google के आवेदन की भाषा ने protection का संकेत दिया था, लेकिन बाद में इसे commercial रूप से बेचा गया, जिससे tools और setups टूट गए।

व्यावहारिक प्रतिक्रियाएँ और सलाह

• कुछ लोग .lan को बनाए रखने, लेकिन इसे resolvers पर block करने, की योजना बनाते हैं, जिससे public .lan domains व्यावहारिक रूप से unreachable हो जाएँ।
• अन्य लोग .internal, home.arpa, या owned domains की ओर माइग्रेट कर रहे हैं, या search domains जोड़ रहे हैं ताकि उपयोगकर्ता फिर भी छोटे hostnames टाइप कर सकें।
• सामान्य भावना: .lan को सार्वजनिक gTLD के रूप में लागू करना अनावश्यक, भ्रमित करने वाला (क्योंकि “Local Area Network”), और संभवतः हानिकारक है, हालांकि एक अल्पसंख्यक यह जोर देता है कि unreserved TLDs का उपयोग हमेशा से जोखिम था।