क्या एक-अक्षर के होस्ट नाम मान्य हैं?


14

RFC-952 (मान्यताओं के तहत बिंदु 1 का अंतिम वाक्य) एकल-चरित्र होस्ट नामों पर प्रतिबंध लगाता है और मेरे पास अनुभव हैं ( 7 साल पहले 2002 की गर्मियों में) जहां कुछ सेवाएं एकल-चरित्र होस्ट नामों के साथ काम करने से मना कर देती थीं (क्योंकि ऐसे नाम थे) मानक-अनुरूप नहीं), लेकिन मैंने पिछले कुछ वर्षों में कई एकल-चरित्र होस्ट नामों का उपयोग किया है। क्या एकल-पात्र होस्ट नाम अब मान्य हैं? (यदि हां, तो उचित सत्यापन संदर्भ क्या है?)

संपादित करें (उत्तरों से कुछ जानकारी को समेकित करने के लिए): DNS के विभिन्न पहलुओं को कई RFC में परिभाषित किया गया है, जिसमें 1035 , 1123 और 2181 शामिल हैं । से RFC-2181 धारा 11 :

Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment.  For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address.
[ ... ]
See also [RFC1123] section 6.1.3.5.

से RFC-1123 खंड 6.1.3.5 :

The DNS defines domain name syntax very generally -- a
string of labels each containing up to 63 8-bit octets,
separated by dots, and with a maximum total of 255
octets.  Particular applications of the DNS are
permitted to further constrain the syntax of the domain
names they use, although the DNS deployment has led to
some applications allowing more general names.  In
particular, Section 2.1 of this document liberalizes
slightly the syntax of a legal Internet host name that
was defined in RFC-952 [DNS:4].

से RFC-1123 खंड 2.1 :

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4].  One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit.  Host software MUST support this more liberal
syntax.

और अंत में, जैसा कि मूल रूप से संदर्भित है, RFC-952 से :

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.).  Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background).  No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case.  The first
character must be an alpha character.  The last character must not be
a minus sign or period.
[ ... ]
Single character names or nicknames are not allowed.

यह इस श्रृंखला का अनुसरण करने से है कि मैं मूल रूप से यह कहने आया था कि RFC-952 एकल-चरित्र होस्ट नामों पर प्रतिबंध लगाता है।

जवाबों:


2

'मान्य' और 'यह काम करता है' के बीच अंतर है। यह पूरी तरह से संभव है कि होस्टनाम को वैध नहीं माना जाता है यदि वे एकल वर्ण हैं (मेरी पिछली पोस्ट समझ में नहीं आई)। हालांकि, काफी सिस्टम उन्हें अनुमति देते हैं। एक प्रमुख प्रणाली, Microsoft का AD / DNS सिस्टम, एकल वर्ण नामों की अनुमति के लिए एक विरासत कारण है।

पुराने स्कूल NetBIOS नामों की लंबाई 1 से 15 वर्ण होने की अनुमति है। यह कल्पना RFC952 के स्वतंत्र रूप से विकसित की गई थी, यह एक अलग फ़ाइल के आसपास आधारित है जिसे lmhosts कहा जाता है, इसलिए यह काम करती है। समस्या तब आई जब Microsoft NetBEUI (वास्तव में NBF, NetBIOS फ़्रेम प्रोटोकॉल) और TCP / IP (वास्तव में NBT) पर चला गया, और Microsoft को TCP / IP नेटवर्क पर नामकरण रिज़ॉल्यूशन की अनुमति देनी पड़ी। विजेता को RFC952 आज्ञाकारी मेजबानों की आवश्यकता को दरकिनार करते हुए WinS सर्वर के साथ NetBIOS स्टाइल रिज़ॉल्यूशन बनाए रखने के लिए MS चुना गया।

फिर सक्रिय निर्देशिका और इसके DNS निर्भरताएं आईं। डायनेमिक DNS नियम था, इसलिए क्लाइंट्स को DNS डोमेन में अपना ComputerName (पहले 15 अक्षर जिनमें से उनका NetBIOS नाम भी है) रजिस्टर करना था। चूंकि MS DNS में एकल-वर्ण NetBIOS नामों को पंजीकृत करने की अनुमति देता है, इसने इसे RFC952 के साथ विरोध में लाया। उन्होंने इसे अनुमति देने के लिए अपने सिस्टम को कोड करने का फैसला किया, क्योंकि यह इस बात का अनुकरण करता था कि यह हमेशा जीत के दिनों में कैसे काम करता था।

BIND DNS एकल वर्ण होस्टनाम की भी अनुमति देता है। लेकिन RFC2181 बहुत अधिक बताता है कि अनुप्रयोगों को अपने स्वयं के डेटा को वीटो करने की आवश्यकता है, DNS को और अधिक नहीं। जो हमें उपकरणों और सॉफ़्टवेयर की एक बड़ी आबादी के साथ छोड़ देता है जिसके लिए एकल वर्ण होस्ट नाम ठीक हैं, और कुछ आउटलेयर जो RFC952- सख्त हैं जो इसे अनुमति नहीं देते हैं।


There is a difference between 'valid' and 'it works'. अंततः, मुझे लगता है कि यह सबसे उचित जवाब है, हालांकि मैंने सभी चर्चाओं की बहुत सराहना की है। मैं यह निष्कर्ष निकालूंगा कि एक-वर्ण होस्ट नाम अभी भी तकनीकी रूप से अमान्य हैं, लेकिन इस बिंदु पर बहुत अधिक सार्वभौमिक रूप से काम करते हैं। (इसी तरह, अंडरस्कोर निषिद्ध हैं, लेकिन अधिकांश भाग के लिए काम करते हैं।)
इसहाक

11

आपको लगता है कि वे मान्य हैं क्योंकि रूट नाम-सर्वर सभी एकल-अक्षर होस्ट (a.root-servers.net) हैं, और DNS कल्पना उनके लिए एक विशिष्ट अपवाद नहीं बनाती है। प्रश्न में RFC विशेष रूप से होस्ट-फ़ाइल प्रारूप के लिए है, DNS के लिए नहीं। DNS को बाद में RFC में परिभाषित किया गया ( RFC 1035 इसे शुरू करता है)। RFC 1123 (1989) यह स्पष्ट रूप से बताता है।

 The syntax of a legal Internet host name was specified in RFC-952
 [DNS:4].  One aspect of host name syntax is hereby changed: the
 restriction on the first character is relaxed to allow either a
 letter or a digit.  Host software MUST support this more liberal
 syntax.

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


ठीक है, मैं इसे RFC-1123 में पढ़ूंगा, लेकिन मैंने इसका मतलब यह निकाला कि मैंने RFC-952 में जो स्पेक्स पढ़े हैं, वे लागू होते हैं, सिवाय इसके कि एक अंक भी प्रथम वर्ण के रूप में अनुमेय है (जैसा कि आपने उद्धृत किया है, यह परिवर्तन नहीं करता है एकल-चरित्र नामों पर प्रतिबंध)। रूट सर्वर के रूप में, मुझे कुछ बिंदु पर बताया गया कि वे नियम के कुछ विशेष अपवाद थे।
इसहाक

2

जैसा कि होस्ट नाम के आसपास थे, इससे पहले कि किसी ने भी उनके बारे में RFC लिखने के बारे में सोचा था, मैं किसी भी कारण से नहीं देख सकता कि एकल चरित्र होस्ट नाम अचानक "अवैध" हो जाना चाहिए। उस विशेष RFC ने मुझे खो दिया जब यह कहा गया

यह RFC आधिकारिक विनिर्देश है

क्योंकि RFC एक मानक नहीं है। आस - पास भी नहीं।

पूर्वगामी के बावजूद, यह ध्यान दिया जाना चाहिए कि प्रश्न में RFC एक अपेक्षाकृत छोटे समूह, अर्थात् रक्षा विभाग (संयुक्त राज्य अमेरिका के संभवतः) पर लागू करने के लिए बनाया गया था।


बहुत परिभाषा के अनुसार आरएफसी एक मानक नहीं है। "टिप्पणियों के लिए अनुरोध" किसी को भी "मानक" नहीं चिल्लाता है। दिलचस्प है कि वे अपने स्वयं के दस्तावेजों में इसके साथ भाग गए।
मार्क हेंडरसन

1
en.wikipedia.org/wiki/Domain_name_system#Internet_standards कई RFC को सूचीबद्ध करता है जो DNS प्रोटोकॉल को "परिभाषित" करते हैं। RFC-1123 (जैसा कि sysadmin1138 द्वारा बताया गया है) सूचीबद्ध लोगों में से है और यह RFC-952 का संदर्भ देता है। यह मेरा अनुभव रहा है कि, जबकि RFC के अनुरोध हैं, वे स्वीकार किए जाने पर परिभाषा बन जाते हैं।
इसहाक

@Farseeker, मैं यह नहीं कह रहा हूं कि यहां मामला है, लेकिन मैं हमेशा लोगों को आश्चर्यचकित करता हूं, जिनमें से अधिकांश को बेहतर पता होना चाहिए, जो आरएफसी को उद्धृत करते हैं जैसे कि वे किसी विशेष विषय पर अंतिम अधिकार हैं। मुझे पूरा यकीन है कि कहीं न कहीं इसके बारे में एक RFC है। ;)
जॉन गार्डनियर्स 3

1
कुछ RFC वास्तव में मानक हैं - RFCs 1034 और 1035 एक साथ, उदाहरण के लिए, STD0013 शामिल हैं। जिस कारण से उन्हें "टिप्पणियों के लिए अनुरोध" कहा जाता है वह ऐतिहासिक है, और संक्षेप में 60 के दशक के उत्तरार्ध में निचले स्तर के पोस्टग्राउंड का एक गुच्छा के साथ करना था 60 के दशक में अपने वरिष्ठों को टिक नहीं करना चाहते थे (मैंने सुना है कि उस व्यक्ति में सीधे से RFC 1 के लेखक)।
अलनीतक

2
@ जॉन मैं आपके पढ़े RFC 2026 का सुझाव देता हूं। "मानक की स्थिति तक पहुँचने वाला एक विनिर्देश इसके RFC नंबर को बनाए रखते हुए STD श्रृंखला में एक नंबर दिया गया है"। मैं अपने दिन के काम के लिए IETF दस्तावेज़ लिखता हूँ।
अलनीतक

1

मुझे लगता है कि DNS के स्पेक्स पर वर्तमान होस्टनाम अधिक निर्भर हैं क्योंकि ज्यादातर लोग नेटवर्क के अंदर या इंटरनेट में उपयोग करेंगे। कहा कि, तीन RFC दिमाग में आते हैं (1034 - अवधारणाएं, 1035 - कार्यान्वयन और 2181 - DNS के बारे में स्पष्टीकरण)।

RFC 1034 की धारा 3 कहती है:

डोमेन नेम स्पेस एक ट्री स्ट्रक्चर है। पेड़ पर प्रत्येक नोड और पत्ती एक संसाधन सेट (जो खाली हो सकता है) से मेल खाती है। डोमेन सिस्टम आंतरिक नोड्स और पत्तियों के उपयोग के बीच कोई अंतर नहीं करता है, और यह मेमो दोनों को संदर्भित करने के लिए "नोड" शब्द का उपयोग करता है।

प्रत्येक नोड में एक लेबल होता है, जिसकी लंबाई शून्य से 63 ओकटेट होती है। भाई नोड में एक ही लेबल नहीं हो सकता है, हालांकि उसी लेबल का उपयोग नोड्स के लिए किया जा सकता है जो भाई नहीं हैं। एक लेबल आरक्षित है, और यह रूट के लिए उपयोग किया जाने वाला अशक्त (यानी, शून्य लंबाई) लेबल है।

और RFC 2181 की धारा 11 में हमारे पास पते के प्रत्येक नोड के नामकरण के बारे में स्पष्टीकरण है:

DNS खुद को विशेष लेबल पर केवल एक प्रतिबंध लगाता
है जिसका उपयोग संसाधन रिकॉर्ड की पहचान करने के लिए किया जा सकता है। यह प्रतिबंध
लेबल की लंबाई और पूर्ण नाम से संबंधित है। किसी एक लेबल की लंबाई 1 और 63 ऑक्टेट के बीच सीमित है। एक पूर्ण डोमेन नाम 255 ऑक्टेट (विभाजकों सहित) तक सीमित है

तो, DNS चश्मे के प्रकाश से, आप a.domain.tld कर सकते हैं


RFC-2181 की धारा 11 में अगले पैराग्राफ से: Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address. मूल रूप से, क्योंकि DNS में मान्य a.domain.tld इसे एक मान्य होस्टनाम नहीं बनाता है। RFC-1123 की धारा 11 का संदर्भ खंड 6.1.3.5, जो स्वयं और RFC-952 की धारा 2.1 का हवाला देता है, जैसा कि sysadmin1138 के उत्तर में चर्चा की गई है।
इसहाक

अनुभाग 6.1.3.5 के अंत में प्रशस्ति पत्र 952 पर परिभाषित नामकरण सम्मेलन में कम बाधाओं के बारे में बात करता है। इसके अलावा 952 एक डीओडी होस्ट तालिका को परिभाषित करता है और मुझे पूरी तरह से यकीन नहीं है कि यह डीएनएस चश्मे की तुलना में अधिक प्रासंगिक है।
coredump

मुझे लगता है कि 6.1.3.5 के अंत में उल्लिखित बाधाओं का उदारीकरण केवल पहले चरित्र को एक संख्या की अनुमति देने के लिए संदर्भित करता है - यह केवल उसी RFC की धारा 2.1 में उल्लिखित संशोधन है (जो कि खंड 6.1 है। 3.5 को संदर्भित करता है)। यह धारा 2.1 में है कि RFC-952 से परिभाषा को कानूनी मेजबान नाम की परिभाषा के रूप में संदर्भित किया जाता है।
इसहाक

इसके अलावा RFC 920 और 921 की जाँच करें जो पुराने DARPA से डोमेन नाम में माइग्रेशन का व्यवहार करता है।
coredump

1

जैसा कि आपने निर्धारित किया है, RFC 1123 इस लंबाई के मुद्दे पर पूरी तरह से स्पष्ट नहीं है।

धारा 2.1 कहता है:

होस्ट सॉफ्टवेयर 63 अक्षरों तक के होस्ट नामों को संभालना चाहिए और 255 अक्षरों तक के होस्ट नामों को संभालना चाहिए

चूँकि यह पाठ RFC 952 से पाठ को पूरी तरह से प्रभावित करता है, इसलिए यह भी माना जाना चाहिए कि 255 वर्ण तक की कोई भी विधि कानूनी है।

दुर्भाग्य से 1989 के इंटरनेट ड्राफ्ट में अविश्वसनीय रूप से कठोर समीक्षा नहीं हुई जो उन्हें अब मिलती है, इसलिए अस्पष्टता शायद बस नहीं देखी गई थी।


1
लेकिन 2.1 यह भी कहना The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. उचित नहीं है कि इसका मतलब यह नहीं है कि आपका उद्धरण आरएफसी -952 से पाठ को पूरी तरह से ओवरराइड नहीं करता है?
इसहाक

यह कहता है कि, लेकिन यह स्पष्ट रूप से गलत है। RFC 1123 भी होस्टनाम की अनुमेय लंबाई को स्पष्ट रूप से बदलता है।
अलनीतक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.