क्या (डोमेन नाम) उपडोमेन में एक अंडरस्कोर "_" हो सकता है?


212

क्या उप डोमेन (डोमेन नाम) में अंडरस्कोर _हो सकता है?


12
मैंने आपके प्रश्न को संक्षेप में लिया है: कि आप वास्तव में DOMAIN NAMES थे। यदि, इसके बजाय, आपको HOST NAMES से मतलब है, तो अपने प्रश्न को संपादित करें, क्योंकि उत्तर अलग होगा।
bortzmeyer

जवाबों:


362

यहां दिए गए ज्यादातर जवाब झूठे हैं । डोमेन नाम में अंडरस्कोर होना पूरी तरह से कानूनी है। मुझे मानक, RFC 2181, धारा 11, "नाम वाक्यविन्यास" उद्धृत करें :

DNS खुद को विशेष लेबल पर केवल एक प्रतिबंध लगाता है जिसका उपयोग संसाधन रिकॉर्ड की पहचान करने के लिए किया जा सकता है। यह प्रतिबंध लेबल की लंबाई और पूर्ण नाम से संबंधित है। [...] DNS प्रोटोकॉल के कार्यान्वयन का उपयोग किए जा सकने वाले लेबल पर कोई प्रतिबंध नहीं होना चाहिए। विशेष रूप से, DNS सर्वरों को किसी क्षेत्र की सेवा करने से इंकार नहीं करना चाहिए क्योंकि इसमें ऐसे लेबल होते हैं जो कुछ DNS क्लाइंट प्रोग्राम के लिए स्वीकार्य नहीं हो सकते हैं।

मूल DNS विनिर्देश, RFC 1034 भी देखें , अनुभाग 3.5 "पसंदीदा नाम सिंटैक्स" , लेकिन इसे ध्यान से पढ़ें।

अंडरस्कोर वाले डोमेन जंगल में बहुत आम हैं। जांच _jabber._tcp.gmail.comया_sip._udp.apnic.net

यहां उल्लेखित अन्य RFC अलग-अलग चीजों से निपटते हैं। मूल प्रश्न डोमेन नामों के लिए था । यदि प्रश्न होस्ट नामों (या URL के लिए, जिसमें होस्ट नाम शामिल है) के लिए है, तो यह अलग है, प्रासंगिक मानक RFC 1123 , खंड 2.1 "होस्ट नाम और संख्या" है जो होस्ट नामों को अक्षरों-अंकों-हाइफ़न तक सीमित करता है


73
"डोमेन नाम" और "होस्ट नाम" के बीच अंतर के लिए +1
Alnitak

3
सवाल (जब तक इसे संपादित नहीं किया गया) सबडोमेन के बारे में है। होस्ट नामों। आप अपने तथ्यात्मक बयानों के बारे में गलत नहीं हैं, सिवाय इसके कि यह इंगित करने के लिए कि प्रश्न वर्तमान में कैसे शब्द के आधार पर झूठे हैं।
Redreinard

4
मैं उलझन में हूं, 1034 में कहा गया है "लेबल को ARPANET होस्ट नामों के लिए नियमों का पालन करना चाहिए। उन्हें एक अक्षर से शुरू होना चाहिए, एक अक्षर या अंक के साथ समाप्त होना चाहिए, और केवल अक्षर, अंक और हाइफ़न के रूप में आंतरिक वर्ण हैं।" उस का कौन सा हिस्सा अंडरस्कोर की अनुमति देता है?
क्लेउडेकेनिलोल

2
शब्दांकन भ्रामक है। URL में अंडरस्कोर नहीं हो सकते। एक URL हमेशा एक FQDN होता है, यह एक होस्ट नाम नहीं है। FQDN के पास एक खाली होस्ट नाम हो सकता है, इस मामले में FQDN = डोमेन। _jabber._tcp.gmail.comएक डोमेन नहीं है, यह एक FQDN है। क्योंकि URL में अंडरस्कोर नहीं हो सकता है, आप शायद कभी भी इसमें अंडरस्कोर वाला डोमेन नहीं खरीद पाएंगे। तो, यहां तक ​​कि थोम डोमेन भी डीएनएस सिंटैक्स दृष्टिकोण से अंडरस्कोर हो सकते हैं, आप कभी भी मुठभेड़ नहीं करेंगे, जब तक कि यह स्थानीय न हो।
कैप्सूल

1
मैं rfc1123 के 2.1 में बोली नहीं देख सकता कि इसमें हाइफ़न की अनुमति के बारे में कुछ भी उल्लेख किया गया है। मैं rfc952 में देख सकता हूं कि एक नाम <let-or-digit-or-hyphen> हो सकता है। क्या आप इसका जिक्र कर रहे हैं?
AJP

93

Bortzmeyer के उत्तर में शब्दावली पर एक नोट

परिभाषाओं के बारे में स्पष्ट होना चाहिए। जैसा कि यहाँ प्रयोग किया गया है:

  • डोमेन नाम एक DNS डेटाबेस में एक संसाधन का पहचानकर्ता है
  • लेबल है बिंदुओं के बीच में एक डोमेन नाम का हिस्सा
  • hostname एक विशेष प्रकार का डोमेन नाम है जो इंटरनेट होस्ट की पहचान करता है

होस्ट नाम के प्रतिबंधों के अधीन है आरएफसी 952 और RFC 1123 की मामूली छूट

RFC 2181 स्पष्ट करता है कि डोमेन नाम और होस्टनाम के बीच अंतर है:

... [तथ्य यह है कि] किसी भी बाइनरी लेबल में एमएक्स रिकॉर्ड हो सकता है इसका मतलब यह नहीं है कि किसी भी बाइनरी नाम का उपयोग ई-मेल पते के मेजबान भाग के रूप में किया जा सकता है ...

तो होस्टनाम में अंडरस्कोर कोई नहीं-नहीं, डोमेन नामों में अंडरस्कोर है एक-ठीक हैं।

व्यवहार में, कोई अच्छी तरह से अंडरस्कोर वाले होस्टनाम को देख सकता है । रोबस्टनेस सिद्धांत के रूप में कहता है: "जो आप भेजते हैं उसमें रूढ़िवादी बनें, जो आप स्वीकार करते हैं उसमें उदारता"।

एन्कोडिंग पर एक नोट

21 वीं सदी में, यह पता चलता है कि होस्टनाम के साथ-साथ डोमेन नामों का भी अंतर्राष्ट्रीयकरण हो सकता है! इसका मतलब है कि लेबल के मामले में एन्कोडिंग का सहारा लेना जिसमें ऐसे अक्षर शामिल हैं जो अनुमत सेट के बाहर हैं।

विशेष रूप से, यह होस्टनाम_ में एक को एनकोड करने की अनुमति देता है (अपडेट 2017-07: यह संदिग्ध है, टिप्पणियां देखें। अभी भी होस्टनाम में उपयोग नहीं किया जा सकता है। वास्तव में, इसका उपयोग अंतर्राष्ट्रीय लेबल में भी नहीं किया जा सकता है।)_

अंतर्राष्ट्रीयकरण के लिए पहला RFC मार्च 2003 का RFC 3490 था , "अंतर्राष्ट्रीयकरण अनुप्रयोग (IDNA) में डोमेन नाम"। आज, हमारे पास:

  • RFC 5890 "IDNA: परिभाषाएँ और दस्तावेज़ रूपरेखा"
  • RFC 5891 "IDNA: प्रोटोकॉल"
  • RFC 5892 "द यूनिकोड कोड पॉइंट्स और IDNA"
  • RFC 5893 "IDNA के लिए राइट-टू-लेफ्ट स्क्रिप्ट्स"
  • RFC 5894 "IDNA: बैकग्राउंड, एक्सप्लोरेशन, और राशनेल"
  • RFC 5895 "IDNA 2008 के लिए वर्ण मैपिंग"

आप विकिपीडिया प्रविष्टि की जाँच करना भी चाह सकते हैं

आरएफसी 5890 प्रस्तुत किया जाने अवधि LDH (पत्र-डिजिट-Hypen) लेबल के लिए लेबल में प्रयोग किया जाता होस्ट नामों और कहते हैं:

यह शास्त्रीय लेबल रूप का उपयोग किया जाता है, कुछ अतिरिक्त प्रतिबंधों के साथ, होस्टनाम (RFC 952) में। इसका सिंटैक्स RFC 1123 द्वारा संशोधित RFC 1034 की धारा 3.5 में "पसंदीदा नाम सिंटैक्स" के रूप में वर्णित के समान है। संक्षेप में, यह ASCII अक्षरों, अंकों, और आगे प्रतिबंध के साथ हाइफ़न से युक्त एक स्ट्रिंग है जो हाइफ़न नहीं कर सकता है स्ट्रिंग की शुरुआत या अंत में दिखाई देते हैं। सभी DNS लेबल की तरह, इसकी कुल लंबाई 63 ओकटेट से अधिक नहीं होनी चाहिए।

सरल समय पर वापस जाना, यह इंटरनेट ड्राफ्ट hostname अंतर्राष्ट्रीयकरण के लिए एक प्रारंभिक प्रस्ताव है । अंतर्राष्ट्रीय वर्णों वाले होस्टनाम का उपयोग करके एन्कोड किया जा सकता है, उदाहरण के लिए, 'RACE' एन्कोडिंग

'RACE एन्कोडिंग' प्रस्ताव नोट्स के लेखक:

RFC 1035 के अनुसार, होस्ट भागों को केस-असंवेदनशील होना चाहिए, एक अक्षर या अंक के साथ शुरू और समाप्त होना चाहिए, और इसमें केवल अक्षर, अंक और हाइफ़न वर्ण ("-") शामिल होंगे। यह निश्चित रूप से, किसी भी अंतर्राष्ट्रीय वर्णों के साथ-साथ ASCII चरित्र प्रदर्शनों में कई अन्य पात्रों को छोड़कर। इसके अलावा, डोमेन नाम भागों की लंबाई 63 ओकटेट या उससे कम होनी चाहिए .... सभी पोस्ट-परिवर्तित नाम भाग जिनमें अंतर्राष्ट्रीयकृत वर्ण होते हैं वे स्ट्रिंग "bq--" से शुरू होते हैं। (...) स्ट्रिंग "bq--" को चुना गया क्योंकि यह विनिर्देशन निर्मित होने से पहले मेजबान भागों में मौजूद होने की बहुत संभावना नहीं है।


एक ओर ध्यान दें, "डोमेनकी और सर्विस रिकॉर्ड जैसे सिस्टम अंडरस्कोर का उपयोग इस बात का आश्वासन देने के लिए करते हैं कि उनका विशेष वर्ण होस्टनामों के साथ भ्रमित नहीं है। उदाहरण के लिए, _http._sctp.www.example.com एक SCTP के लिए एक सर्विस पॉइंटर निर्दिष्ट करता है। डोमेन example.com में सक्षम वेबसर्वर होस्ट (www)। " ( लिंक )
x- यूरी

RACE एन्कोडिंग भागों पर ध्यान न दें, IDN ने पहले से ही इंटैकिटोनलाइज़ किए गए वर्ण को 'xn--' उपसर्ग का उपयोग करके ASCII में बदल दिया।
मटूटूट

2
@ Nelda.techspiress कुछ समय लेकिन के अनुसार किया गया है RFC 1034: डोमेन नाम - विचार और सुविधाएं , क्या एक डोमेन के हिस्से को "उप डोमेन" कहा जाता है bar.baz.(उदाहरण के लिए) केवल डोमेन नाम के पदानुक्रम के नीचे हैं का संग्रह है bar.baz., उदाहरण के लिए a.bar.baz., f.g.bar.baz., h.bar.baz., आदि इस "उपडोमेन" में वास्तविक होस्टनाम शामिल हो सकते हैं या नहीं ।
डेविड टोनहोफर

2
दैनिक उपयोग में, कोई व्यक्ति स्ट्रिंग a.bar.baz(एक डोमेन नाम) का उपडोमेन स्ट्रिंग (एक डोमेन नाम) को गलत तरीके से कह सकता है bar.baz। डोमेन नाम (DNS डेटाबेस संसाधन) a.bar.bazऔर होस्टनामbar.baz हो सकते हैं या नहीं भी हो सकते हैं ।
डेविड टोनहोफर

1
RFC 1034 के पेज 8 पर , हम पढ़ते हैं: एक डोमेन की पहचान एक डोमेन नाम से होती है, और इसमें डोमेन नाम स्पेस का वह हिस्सा होता है जो डोमेन नाम के नीचे या डोमेन नाम के नीचे होता है जो डोमेन को निर्दिष्ट करता है। एक डोमेन दूसरे डोमेन का एक उपडोमेन है अगर यह उस डोमेन के भीतर समाहित है। इस संबंध का परीक्षण यह देखने के द्वारा किया जा सकता है कि उप डोमेन के नाम के साथ उपडोमेन का नाम समाप्त होता है या नहीं। उदाहरण के लिए, एबीसीडी बीसीडी, सीडी, डी, और "" का एक उपडोमेन है।
डेविड टोनहोफर

47

एक अतिरिक्त बात है जो आपको जानना आवश्यक है: यदि होस्ट या url के उपडोमेन हिस्से में एक अंडरस्कोर होता है, तो IE9 (अन्य संस्करणों का परीक्षण नहीं किया गया है) कुकीज़ नहीं लिख सकता है।

इसलिए उससे सावधान रहें। :-)



3
हमारे पास बस एक परियोजना थी - और मैं वहाँ अजीब IE मुद्दों के बारे में पागल हो जाने वाला था। जब तक हम उपडोमेन में अंडरस्कोर की खोज नहीं करते। ; ओ)
काई मेटर्न

3
अभी भी IE10 में एक मुद्दा है। क्या MS को इस बारे में पता है?
पायोत्र कुला

15
अधिक प्रासंगिक: क्या एमएस इस बारे में परवाह करता है?
अजाक्स


11

स्पष्ट bortzmeyer और डेविड Tonhofer , डोमेन नाम और उप डोमेन नाम लेबल प्रमुख अंडरस्कोर कहीं और होते हैं, लेकिन कर सकते हैं।

जैसा कि डेविड टोनहोफर ने लिखा है, लेबल इन-द-इन-द-पीरियड पार्ट्स हैं और एलडीएच नियम का पालन करना चाहिए सिवाय जब सर्विस लेबल और पोर्ट लेबल को निर्दिष्ट किए उन्हें नियमित लेबल से अलग करने के लिए। फिर उन्हें लेबल की शुरुआत में होना चाहिए जो कि सेवा के नाम और पोर्ट नंबर रजिस्ट्री से "लघु नाम" होना चाहिए , पोर्ट नंबर बिना प्रमुख 0s या प्रोटोकॉल (यानी। tcp, udp)। ये सेवा लेबल 15 वर्णों तक सीमित हैं।

  • RFC2782 अंडरस्कोर के साथ प्रीफ़िक्सिंग सेवा रिकॉर्ड उप-डोमेन निर्दिष्ट करता है।
  • RFC6698 TLSA सर्टिफिकेट रिकॉर्ड में अंडरस्कोर के साथ पोर्ट संख्या को बढ़ाता है।

डेविड टोनहोफर के उत्तर के विपरीत , IDN अंडरस्कोर ('_' U + 005F कम लाइन) या किसी अन्य अमान्य ASCII वर्ण को एन्कोडिंग की अनुमति नहीं देता है।

से RFC5890

[..] LDH लेबल के दो नए उपसमूह IDNA की शुरूआत के द्वारा बनाए गए हैं। इन्हें आरक्षित एलडीएच लेबल (आर-एलडीएच लेबल) और गैर-आरक्षित एलडीएच लेबल (एनआर-एलडीएच लेबल) कहा जाता है। आरक्षित एलडीएच लेबल, जिन्हें कुछ अन्य संदर्भों में "टैग किए गए डोमेन नाम" के रूप में जाना जाता है, उनके पास तीसरे और चौथे वर्ण में "-" संपत्ति है , जो अन्यथा एलडीएच लेबल नियमों के अनुरूप है

पुनीकोड ​​सभी ASCII कोडपॉइंट्स को सीधे ASCII के रूप में बताता है, जिसमें अंडरस्कोर भी शामिल है। परिणामस्वरूप R-LDH LDH लेबल नियमों के अनुरूप नहीं होगा। उदाहरण के लिए, Σ_.comइनकोड किया जाएगा xn--_-zmb.comजो नियमों का उल्लंघन करता है। एक होम कोडोग्राफ हो सकता है जो अंडरस्कोर की तरह दिखता है जिसे कानूनी रूप से कोडित किया जा सकता है (शायद '_' U + FF3F पूर्णविराम कम लाइन), लेकिन इन प्रकार के कोडपॉइंट्स को RFC5892 के तहत 2.3 इग्नाग्रोप्रोटेक्ट्स के रूप में एक Noncharacter_Code_Point के रूप में वर्गीकृत किया जाएगा।

RACE (अन्य प्रस्तावित IDN एन्कोडिंग योजना) IETF द्वारा एक मानक के रूप में स्वीकार नहीं किया गया था और इसका उपयोग नहीं किया जाना चाहिए।


1
आखिरकार। विश्वास नहीं कर सकता कि यह पूरे पृष्ठ का एकमात्र ऐसा पद है जो यहां तक ​​कि पंचकोश की बात करता है।
1

6

मैंने RFC1034 के लिंक का अनुसरण किया और इसे सबसे अधिक पढ़ा और यह देखकर आश्चर्यचकित रह गया:

लेबल ARPANET होस्ट नामों के लिए नियमों का पालन करना चाहिए। उन्हें एक पत्र के साथ शुरू करना चाहिए, एक पत्र या अंक के साथ समाप्त होना चाहिए, और केवल अक्षर, अंक और हाइफ़न के आंतरिक पात्रों के रूप में होना चाहिए। लंबाई पर भी कुछ प्रतिबंध हैं। लेबल 63 वर्ण या उससे कम का होना चाहिए।

स्पष्टीकरण के लिए, एक डोमेन नाम उन लेबलों से बना होता है जिन्हें डॉट्स द्वारा अलग किया जाता है ""। यह युक्ति पुरानी होनी चाहिए क्योंकि इसमें अंडरस्कोर के उपयोग का उल्लेख नहीं है। मैं भ्रम को समझ सकता हूं अगर कोई भी इस युक्ति पर ठोकर खाता है बिना यह जाने कि यह अप्रचलित है। यह अप्रचलित है, है ना?

मैंने RFC2181 के लिंक का अनुसरण किया और इसके बारे में कुछ पढ़ा। विशेष रूप से जहां यह एक आधिकारिक, या विहित, नाम और क्या एक वैध DNS लेबल बनाता है के मुद्दे से संबंधित है।

जैसा कि पहले पोस्ट किया गया था कि इसमें केवल एक लंबा प्रतिबंध है फिर इसे पढ़ने के लिए योग करने के लिए:

(नाम और वैध लेबल के बारे में)

ये पहले से ही पर्याप्त रूप से निर्दिष्ट हैं, हालांकि विनिर्देशों को कभी-कभी अनदेखा किया जाता है। हम मौजूदा विनिर्देशों को सुदृढ़ करना चाहते हैं।

अगर मुझे "केवल एक प्रतिबंध" "पर्याप्त" है, तो मुझे आश्चर्य होगा। क्या हम @ # $% जैसे डोमेन नाम देखना शुरू करने जा रहे हैं !! जल्द ही? क्या इंटरनेट पर्याप्त नहीं है?


3
नहीं, यह अप्रचलित नहीं है। RFC1034 होस्ट नामों के बारे में एक विनिर्देश है , डोमेन नामों का एक विशेष मामला है , जो DNS डेटाबेस में संसाधनों के सामान्य पहचानकर्ता हैं। उदाहरण के लिए, URI के "होस्ट" भाग को आराम से परिभाषित किया गया है ( tools.ietf.org/html/rfc3986#section-3.2.2 ) लेकिन RFC सावधान करता है: "पंजीकृत नाम से पहचाने जाने वाला होस्ट आमतौर पर वर्णों का अनुक्रम होता है। स्थानीय रूप से परिभाषित होस्ट या सेवा नाम रजिस्ट्री के भीतर देखने के लिए इरादा ... DNS में देखने के लिए पंजीकृत एक पंजीकृत नाम [RFC1034] की धारा 3.5 [RFC1123] की धारा 2.1 में परिभाषित वाक्यविन्यास का उपयोग करता है। "
डेविड टोनहोफर

3

हाल ही में कैब-फोरम (*) ने फैसला किया है

किसी भी dNSName प्रविष्टि में अंडरस्कोर वर्ण वाले सभी प्रमाणपत्र और 30 दिनों से अधिक की वैधता अवधि 15 जनवरी, 2019 से पहले रद्द कर दी जानी चाहिए। https://cabforum.org/2018/11/12/ballot-sc-12- सूर्यास्त के- अंडरस्कोर-इन-dnsnames /

इसका मतलब है कि अब आपको उन डोमेन में अंडरस्कोर का उपयोग करने की अनुमति नहीं है जिनके पास ssl / tls प्रमाणपत्र होगा।

(*) प्रमाणन प्राधिकरण ब्राउज़र फ़ोरम (CA / ब्राउज़र फ़ोरम) प्रमुख प्रमाणपत्र जारीकर्ताओं की स्वैच्छिक सभा है (जैसा कि नीचे धारा 2.1 (a) (1) और (2) में परिभाषित है) और इंटरनेट ब्राउज़र सॉफ़्टवेयर और अन्य अनुप्रयोगों के विक्रेताओं प्रमाणपत्र का उपयोग करें (प्रमाणपत्र उपभोक्ता, जैसा कि धारा 2.1 (ए) में परिभाषित किया गया है) (3) नीचे)।


1

व्यक्तिगत टीएलडी अपने स्वयं के नियमों और प्रतिबंधों को डोमेन के नाम पर रख सकते हैं जैसे वे फिट होते हैं, जैसे कि स्थानीय भाषाओं को समायोजित करना।

उदाहरण के लिए, CIRA के अनुसार , कनाडा के .caडोमेन नामों की अनुमति है:

  • पत्रों के aमाध्यम से z, और निम्नलिखित उच्चारण वर्ण é ë ê è â à æ ô œ ù û ü ç î ï ÿ:। ध्यान दें कि डोमेन नाम संवेदनशील नहीं हैं। इसका मतलब है कि ऊपरी मामले के अक्षरों और निचले मामले के अक्षरों ( A= a) के बीच कोई अंतर नहीं होगा ;

  • संख्या 0123456789, और

  • हाइफ़न वर्ण (" -) (हालांकि इसका उपयोग डोमेन नाम शुरू करने या समाप्त करने के लिए नहीं किया जा सकता है)।

अधिकतम लंबाई 63 वर्ण है, प्रत्येक उच्चारण चरित्र को छोड़कर, 4 वर्णों द्वारा उस सीमा को कम करता है ।

( स्रोत )


संयोग से, यह डॉट-सीए डोमेन के लिए लगभग 4 क्वाड्रैजेंटिलिन डोमेन नाम संभावनाओं (उप-डोमेन की गिनती नहीं) की अनुमति देता है ।


0

यहाँ जावा दुनिया से मेरे 2 सेंट:

जावा 8 के साथ स्पार्क स्काला कंसोल से:

scala> new java.net.URI("spark://spark_master").getHost
res10: String = null

scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master

scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null

scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr

scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr

scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null

यह निश्चित रूप से एक बुरा विचार है ^ ^


0

बस स्थानीय परियोजना (आवारा के साथ) बनाई गई थी और आईपी पते पर पहुंचने पर यह पूरी तरह से काम कर रही थी। फिर मैंने कुछ_नाम.टेस्ट्स को होस्ट फ़ाइल में जोड़ा और इसे इस तरह एक्सेस करने की कोशिश की, लेकिन मुझे हर समय "बुरा अनुरोध - 400" मिल रहा था। घंटों बर्बाद किया जब तक मुझे पता नहीं चला कि डोमेन नाम को कुछ name.est में बदलना समस्या को हल करता है। मैक ओएस पर कम से कम स्थानीय रूप से यह काम नहीं कर रहा है।


0

नहीं, आप उपडोमेन लेकिन हाइपेन (डैश) में अंडरस्कोर का उपयोग नहीं कर सकते। यानी my-subdomain.agahost.com स्वीकार्य है और my_subdomain.agahost.com स्वीकार्य नहीं होगा।


-2

यदि आप इसे इंटरनेट पर हल करना चाहते हैं तो नहीं।

आपके पास नहीं हो सकता: http://my_subdomain.example.com अमान्य है।

आप कर सकते हैं: http://my-subdomain.example.com एक हाइफ़न के साथ।


यह 15 जनवरी, 2019 के बाद है - आपका काउंटर उदाहरण काम नहीं करता है।
जोइन

@JoeInwap क्या आप कृपया मुझे अपनी टिप्पणी के लिए एक स्रोत की ओर इशारा कर सकते हैं?
अक्षाह

मैं cabforum.org/2018/11/12/… और इस तथ्य से जा रहा था कि o_o.lgms.nl एक प्रमाणपत्र प्रस्तुत करता है जो उस होस्टनाम के लिए मान्य नहीं है। हालाँकि, नाम हल करता है।
जोई
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.