क्या उप डोमेन (डोमेन नाम) में अंडरस्कोर _
हो सकता है?
क्या उप डोमेन (डोमेन नाम) में अंडरस्कोर _
हो सकता है?
जवाबों:
यहां दिए गए ज्यादातर जवाब झूठे हैं । डोमेन नाम में अंडरस्कोर होना पूरी तरह से कानूनी है। मुझे मानक, 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 "होस्ट नाम और संख्या" है जो होस्ट नामों को अक्षरों-अंकों-हाइफ़न तक सीमित करता है ।
_jabber._tcp.gmail.com
एक डोमेन नहीं है, यह एक FQDN है। क्योंकि URL में अंडरस्कोर नहीं हो सकता है, आप शायद कभी भी इसमें अंडरस्कोर वाला डोमेन नहीं खरीद पाएंगे। तो, यहां तक कि थोम डोमेन भी डीएनएस सिंटैक्स दृष्टिकोण से अंडरस्कोर हो सकते हैं, आप कभी भी मुठभेड़ नहीं करेंगे, जब तक कि यह स्थानीय न हो।
परिभाषाओं के बारे में स्पष्ट होना चाहिए। जैसा कि यहाँ प्रयोग किया गया है:
होस्ट नाम के प्रतिबंधों के अधीन है आरएफसी 952 और RFC 1123 की मामूली छूट
RFC 2181 स्पष्ट करता है कि डोमेन नाम और होस्टनाम के बीच अंतर है:
... [तथ्य यह है कि] किसी भी बाइनरी लेबल में एमएक्स रिकॉर्ड हो सकता है इसका मतलब यह नहीं है कि किसी भी बाइनरी नाम का उपयोग ई-मेल पते के मेजबान भाग के रूप में किया जा सकता है ...
तो होस्टनाम में अंडरस्कोर कोई नहीं-नहीं, डोमेन नामों में अंडरस्कोर है एक-ठीक हैं।
व्यवहार में, कोई अच्छी तरह से अंडरस्कोर वाले होस्टनाम को देख सकता है । रोबस्टनेस सिद्धांत के रूप में कहता है: "जो आप भेजते हैं उसमें रूढ़िवादी बनें, जो आप स्वीकार करते हैं उसमें उदारता"।
21 वीं सदी में, यह पता चलता है कि होस्टनाम के साथ-साथ डोमेन नामों का भी अंतर्राष्ट्रीयकरण हो सकता है! इसका मतलब है कि लेबल के मामले में एन्कोडिंग का सहारा लेना जिसमें ऐसे अक्षर शामिल हैं जो अनुमत सेट के बाहर हैं।
विशेष रूप से, यह होस्टनाम_
में एक को एनकोड करने की अनुमति देता है (अपडेट 2017-07: यह संदिग्ध है, टिप्पणियां देखें। अभी भी होस्टनाम में उपयोग नहीं किया जा सकता है। वास्तव में, इसका उपयोग अंतर्राष्ट्रीय लेबल में भी नहीं किया जा सकता है।)_
अंतर्राष्ट्रीयकरण के लिए पहला RFC मार्च 2003 का RFC 3490 था , "अंतर्राष्ट्रीयकरण अनुप्रयोग (IDNA) में डोमेन नाम"। आज, हमारे पास:
आप विकिपीडिया प्रविष्टि की जाँच करना भी चाह सकते हैं
आरएफसी 5890 प्रस्तुत किया जाने अवधि LDH (पत्र-डिजिट-Hypen) लेबल के लिए लेबल में प्रयोग किया जाता होस्ट नामों और कहते हैं:
यह शास्त्रीय लेबल रूप का उपयोग किया जाता है, कुछ अतिरिक्त प्रतिबंधों के साथ, होस्टनाम (RFC 952) में। इसका सिंटैक्स RFC 1123 द्वारा संशोधित RFC 1034 की धारा 3.5 में "पसंदीदा नाम सिंटैक्स" के रूप में वर्णित के समान है। संक्षेप में, यह ASCII अक्षरों, अंकों, और आगे प्रतिबंध के साथ हाइफ़न से युक्त एक स्ट्रिंग है जो हाइफ़न नहीं कर सकता है स्ट्रिंग की शुरुआत या अंत में दिखाई देते हैं। सभी DNS लेबल की तरह, इसकी कुल लंबाई 63 ओकटेट से अधिक नहीं होनी चाहिए।
सरल समय पर वापस जाना, यह इंटरनेट ड्राफ्ट hostname अंतर्राष्ट्रीयकरण के लिए एक प्रारंभिक प्रस्ताव है । अंतर्राष्ट्रीय वर्णों वाले होस्टनाम का उपयोग करके एन्कोड किया जा सकता है, उदाहरण के लिए, 'RACE' एन्कोडिंग ।
'RACE एन्कोडिंग' प्रस्ताव नोट्स के लेखक:
RFC 1035 के अनुसार, होस्ट भागों को केस-असंवेदनशील होना चाहिए, एक अक्षर या अंक के साथ शुरू और समाप्त होना चाहिए, और इसमें केवल अक्षर, अंक और हाइफ़न वर्ण ("-") शामिल होंगे। यह निश्चित रूप से, किसी भी अंतर्राष्ट्रीय वर्णों के साथ-साथ ASCII चरित्र प्रदर्शनों में कई अन्य पात्रों को छोड़कर। इसके अलावा, डोमेन नाम भागों की लंबाई 63 ओकटेट या उससे कम होनी चाहिए .... सभी पोस्ट-परिवर्तित नाम भाग जिनमें अंतर्राष्ट्रीयकृत वर्ण होते हैं वे स्ट्रिंग "bq--" से शुरू होते हैं। (...) स्ट्रिंग "bq--" को चुना गया क्योंकि यह विनिर्देशन निर्मित होने से पहले मेजबान भागों में मौजूद होने की बहुत संभावना नहीं है।
bar.baz.
(उदाहरण के लिए) केवल डोमेन नाम के पदानुक्रम के नीचे हैं का संग्रह है bar.baz.
, उदाहरण के लिए a.bar.baz.
, f.g.bar.baz.
, h.bar.baz.
, आदि इस "उपडोमेन" में वास्तविक होस्टनाम शामिल हो सकते हैं या नहीं ।
a.bar.baz
(एक डोमेन नाम) का उपडोमेन स्ट्रिंग (एक डोमेन नाम) को गलत तरीके से कह सकता है bar.baz
। डोमेन नाम (DNS डेटाबेस संसाधन) a.bar.baz
और होस्टनामbar.baz
हो सकते हैं या नहीं भी हो सकते हैं ।
एक अतिरिक्त बात है जो आपको जानना आवश्यक है: यदि होस्ट या url के उपडोमेन हिस्से में एक अंडरस्कोर होता है, तो IE9 (अन्य संस्करणों का परीक्षण नहीं किया गया है) कुकीज़ नहीं लिख सकता है।
इसलिए उससे सावधान रहें। :-)
स्पष्ट bortzmeyer और डेविड Tonhofer , डोमेन नाम और उप डोमेन नाम लेबल प्रमुख अंडरस्कोर कहीं और होते हैं, लेकिन कर सकते हैं।
जैसा कि डेविड टोनहोफर ने लिखा है, लेबल इन-द-इन-द-पीरियड पार्ट्स हैं और एलडीएच नियम का पालन करना चाहिए सिवाय जब सर्विस लेबल और पोर्ट लेबल को निर्दिष्ट किए उन्हें नियमित लेबल से अलग करने के लिए। फिर उन्हें लेबल की शुरुआत में होना चाहिए जो कि सेवा के नाम और पोर्ट नंबर रजिस्ट्री से "लघु नाम" होना चाहिए , पोर्ट नंबर बिना प्रमुख 0s या प्रोटोकॉल (यानी। tcp, udp)। ये सेवा लेबल 15 वर्णों तक सीमित हैं।
डेविड टोनहोफर के उत्तर के विपरीत , 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 द्वारा एक मानक के रूप में स्वीकार नहीं किया गया था और इसका उपयोग नहीं किया जाना चाहिए।
मैंने RFC1034 के लिंक का अनुसरण किया और इसे सबसे अधिक पढ़ा और यह देखकर आश्चर्यचकित रह गया:
लेबल ARPANET होस्ट नामों के लिए नियमों का पालन करना चाहिए। उन्हें एक पत्र के साथ शुरू करना चाहिए, एक पत्र या अंक के साथ समाप्त होना चाहिए, और केवल अक्षर, अंक और हाइफ़न के आंतरिक पात्रों के रूप में होना चाहिए। लंबाई पर भी कुछ प्रतिबंध हैं। लेबल 63 वर्ण या उससे कम का होना चाहिए।
स्पष्टीकरण के लिए, एक डोमेन नाम उन लेबलों से बना होता है जिन्हें डॉट्स द्वारा अलग किया जाता है ""। यह युक्ति पुरानी होनी चाहिए क्योंकि इसमें अंडरस्कोर के उपयोग का उल्लेख नहीं है। मैं भ्रम को समझ सकता हूं अगर कोई भी इस युक्ति पर ठोकर खाता है बिना यह जाने कि यह अप्रचलित है। यह अप्रचलित है, है ना?
मैंने RFC2181 के लिंक का अनुसरण किया और इसके बारे में कुछ पढ़ा। विशेष रूप से जहां यह एक आधिकारिक, या विहित, नाम और क्या एक वैध DNS लेबल बनाता है के मुद्दे से संबंधित है।
जैसा कि पहले पोस्ट किया गया था कि इसमें केवल एक लंबा प्रतिबंध है फिर इसे पढ़ने के लिए योग करने के लिए:
(नाम और वैध लेबल के बारे में)
ये पहले से ही पर्याप्त रूप से निर्दिष्ट हैं, हालांकि विनिर्देशों को कभी-कभी अनदेखा किया जाता है। हम मौजूदा विनिर्देशों को सुदृढ़ करना चाहते हैं।
अगर मुझे "केवल एक प्रतिबंध" "पर्याप्त" है, तो मुझे आश्चर्य होगा। क्या हम @ # $% जैसे डोमेन नाम देखना शुरू करने जा रहे हैं !! जल्द ही? क्या इंटरनेट पर्याप्त नहीं है?
हाल ही में कैब-फोरम (*) ने फैसला किया है
किसी भी 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) नीचे)।
व्यक्तिगत टीएलडी अपने स्वयं के नियमों और प्रतिबंधों को डोमेन के नाम पर रख सकते हैं जैसे वे फिट होते हैं, जैसे कि स्थानीय भाषाओं को समायोजित करना।
उदाहरण के लिए, CIRA के अनुसार , कनाडा के .ca
डोमेन नामों की अनुमति है:
पत्रों के
a
माध्यम सेz
, और निम्नलिखित उच्चारण वर्णé ë ê è â à æ ô œ ù û ü ç î ï ÿ
:। ध्यान दें कि डोमेन नाम संवेदनशील नहीं हैं। इसका मतलब है कि ऊपरी मामले के अक्षरों और निचले मामले के अक्षरों (A
=a
) के बीच कोई अंतर नहीं होगा ;संख्या
0123456789
, औरहाइफ़न वर्ण ("
-
) (हालांकि इसका उपयोग डोमेन नाम शुरू करने या समाप्त करने के लिए नहीं किया जा सकता है)।
अधिकतम लंबाई 63 वर्ण है, प्रत्येक उच्चारण चरित्र को छोड़कर, 4 वर्णों द्वारा उस सीमा को कम करता है ।
( स्रोत )
संयोग से, यह डॉट-सीए डोमेन के लिए लगभग 4 क्वाड्रैजेंटिलिन डोमेन नाम संभावनाओं (उप-डोमेन की गिनती नहीं) की अनुमति देता है ।
यहाँ जावा दुनिया से मेरे 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
यह निश्चित रूप से एक बुरा विचार है ^ ^
बस स्थानीय परियोजना (आवारा के साथ) बनाई गई थी और आईपी पते पर पहुंचने पर यह पूरी तरह से काम कर रही थी। फिर मैंने कुछ_नाम.टेस्ट्स को होस्ट फ़ाइल में जोड़ा और इसे इस तरह एक्सेस करने की कोशिश की, लेकिन मुझे हर समय "बुरा अनुरोध - 400" मिल रहा था। घंटों बर्बाद किया जब तक मुझे पता नहीं चला कि डोमेन नाम को कुछ name.est में बदलना समस्या को हल करता है। मैक ओएस पर कम से कम स्थानीय रूप से यह काम नहीं कर रहा है।
नहीं, आप उपडोमेन लेकिन हाइपेन (डैश) में अंडरस्कोर का उपयोग नहीं कर सकते। यानी my-subdomain.agahost.com स्वीकार्य है और my_subdomain.agahost.com स्वीकार्य नहीं होगा।
यदि आप इसे इंटरनेट पर हल करना चाहते हैं तो नहीं।
आपके पास नहीं हो सकता: http://my_subdomain.example.com अमान्य है।
आप कर सकते हैं: http://my-subdomain.example.com एक हाइफ़न के साथ।