ชื่อโฮสต์ตัวอักษรหนึ่งตัวถูกต้องหรือไม่


14

RFC-952 (ประโยคสุดท้ายของจุดที่ 1 ภายใต้สมมติฐาน) ห้ามใช้ชื่อโฮสต์ตัวละครเดี่ยวและฉันเคยมีประสบการณ์ ( เมื่อ 7 ปีที่แล้วเมื่อฤดูร้อนปี 2545) ซึ่งบริการบางอย่างจะปฏิเสธที่จะทำงานกับชื่อโฮสต์อักขระเดี่ยว (เพราะชื่อดังกล่าวคือ ไม่ใช่ตามมาตรฐาน) แต่ฉันเห็นชื่อโฮสต์อักขระเดี่ยวจำนวนหนึ่งที่ใช้งานในช่วงไม่กี่ปีที่ผ่านมา ชื่อโฮสต์ที่เป็นอักขระตัวเดียวตอนนี้ใช้ได้หรือไม่ (ถ้าเป็นเช่นนั้นการอ้างอิงการตรวจสอบความถูกต้องที่เหมาะสมคืออะไร)

แก้ไข (เพื่อรวบรวมข้อมูลบางอย่างจากคำตอบ): ด้านต่างๆของ DNS ดูเหมือนจะกำหนดไว้ในหลาย RFCs รวมทั้ง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

มีความแตกต่างระหว่าง 'ที่ถูกต้อง' และ 'มันใช้งานได้' เป็นไปได้อย่างสิ้นเชิงว่าชื่อโฮสต์จะไม่ถือว่าถูกต้องหากเป็นตัวอักษรเดียว อย่างไรก็ตามระบบค่อนข้างมากอนุญาตให้พวกเขา ระบบหลักหนึ่งระบบของ AD / DNS ของ Microsoft มีเหตุผลดั้งเดิมสำหรับการอนุญาตให้ใช้ชื่ออักขระเดี่ยว

ชื่อ NetBIOS โรงเรียนเก่าได้รับอนุญาตให้มีความยาว 1 ถึง 15 อักขระ ข้อมูลจำเพาะนี้ได้รับการพัฒนาโดยไม่ขึ้นกับ RFC952 ซึ่งมีพื้นฐานมาจากไฟล์อื่นที่เรียกว่า lmhosts ดังนั้นจึงสามารถใช้งานได้ ปัญหาเกิดขึ้นเมื่อ Microsoft ย้ายจาก NetBEUI (จริง ๆ แล้ว NBF, NetBIOS Frame Protocol) และเข้าสู่ TCP / IP (จริง ๆ NBT) และ Microsoft ต้องอนุญาตการตั้งชื่อผ่านเครือข่าย TCP / IP MS เลือกที่จะรักษาความละเอียดของสไตล์ NetBIOS ด้วยเซิร์ฟเวอร์ WINS โดยไม่จำเป็นต้องใช้โฮสต์ที่เข้ากันได้กับ RFC952

จากนั้น Active Directory และการขึ้นต่อกันของ DNS มา Dynamic DNS เป็นกฎดังนั้นลูกค้าจึงต้องลงทะเบียน ComputerName (15 ตัวอักษรแรกซึ่งเป็นชื่อ NetBIOS ด้วย) ในโดเมน DNS เนื่องจาก MS อนุญาตให้ชื่อ NetBIOS แบบอักขระเดียวสามารถลงทะเบียนใน DNS สิ่งนี้นำมาซึ่งความขัดแย้งกับ RFC952 พวกเขาตัดสินใจที่จะเขียนโค้ดระบบของตนเพื่ออนุญาตสิ่งนี้เนื่องจากนี่เป็นการเลียนแบบว่ามันเคยทำงานใน WINS วันหรือไม่

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 ที่เป็นปัญหาถูกสร้างขึ้นเพื่อนำไปใช้กับกลุ่มที่ค่อนข้างเล็กนั่นคือกระทรวงกลาโหม (สันนิษฐานว่าเป็นของสหรัฐอเมริกา)


RFC โดยคำจำกัดความไม่ได้มาตรฐาน "คำขอความคิดเห็น" ไม่ได้ส่งเสียงกรีดร้อง "มาตรฐาน" ให้กับทุกคน น่าสนใจที่พวกเขาเก็บมันไว้ในเอกสารของตัวเอง
Mark Henderson

1
en.wikipedia.org/wiki/Domain_name_system#Internet_standardsจะแสดงรายการ RFC จำนวนมากที่ "กำหนด" โปรโตคอล DNS RFC-1123 (ดังที่กล่าวไว้โดย sysadmin1138) เป็นหนึ่งในรายการที่ระบุไว้และอ้างอิงถึง RFC-952 เป็นประสบการณ์ของฉันที่ในขณะที่ RFC เป็นคำขอพวกเขากลายเป็นคำจำกัดความเมื่อพวกเขาได้รับการยอมรับ
Isaac

@ Farseeker ฉันไม่ได้พูดถึงเรื่องนี้ แต่ฉันประหลาดใจกับคนส่วนใหญ่ที่ควรรู้ดีกว่าซึ่งอ้าง RFCs ราวกับว่าพวกเขาเป็นผู้มีอำนาจสูงสุดในเรื่องใดเรื่องหนึ่ง ฉันค่อนข้างแน่ใจว่ามี RFC เกี่ยวกับที่ใดที่หนึ่ง ;)
John Gardeniers

1
RFC บางตัวเป็นมาตรฐาน - RFCs 1034 และ 1035 ด้วยกันตัวอย่างเช่นประกอบด้วย STD0013 เหตุผลที่พวกเขาถูกเรียกว่า "การร้องขอความคิดเห็น" เป็นเรื่องเกี่ยวกับประวัติศาสตร์และโดยพื้นฐานแล้วเกี่ยวข้องกับ postgrads คุณภาพต่ำจำนวนมากในช่วงปลายยุค 60 ซึ่งไม่ต้องการติ๊กหัวหน้าของพวกเขา ผู้เขียน RFC 1)
Alnitak

2
@ จอห์นฉันขอแนะนำให้คุณอ่าน RFC 2026 "ข้อมูลจำเพาะที่มาถึงสถานะมาตรฐานได้รับการกำหนดตัวเลขในซีรี่ส์ STD ในขณะที่ยังคงหมายเลข RFC ไว้" ฉันเขียนเอกสาร IETF สำหรับงานประจำวัน
Alnitak

1

ฉันคิดว่าชื่อโฮสต์ปัจจุบันขึ้นอยู่กับข้อมูลจำเพาะ DNS เนื่องจาก DNS เป็นชื่อที่คนส่วนใหญ่ใช้ในเครือข่ายหรือในอินเทอร์เน็ต กล่าวได้ว่า RFCs ทั้งสามมาถึงใจ (1,034 - แนวคิด, 1035 - การใช้งานและ 2181 - คำชี้แจงเกี่ยวกับ DNS)

ส่วนที่ 3ของ RFC 1034 กล่าวว่า:

พื้นที่ชื่อโดเมนเป็นโครงสร้างต้นไม้ แต่ละโหนดและใบไม้บนต้นไม้สอดคล้องกับชุดทรัพยากร (ซึ่งอาจว่างเปล่า) ระบบโดเมนไม่มีความแตกต่างระหว่างการใช้งานของโหนดภายในและใบไม้และบันทึกนี้ใช้คำว่า "โหนด" เพื่ออ้างอิงถึงทั้งสอง

แต่ละโหนดมีเลเบลซึ่งมีความยาวศูนย์ถึง 63 ออคเต็ต โหนดของ Brother อาจไม่มีป้ายชื่อเดียวกันแม้ว่าจะสามารถใช้ป้ายชื่อเดียวกันสำหรับโหนดที่ไม่ใช่พี่น้องได้ สงวนป้ายกำกับหนึ่งป้ายและนั่นคือป้ายกำกับว่าง (เช่นความยาวเป็นศูนย์) ที่ใช้สำหรับรูท

และในส่วนที่ 11 ของ RFC 2181เรามีคำชี้แจงเกี่ยวกับการตั้งชื่อแต่ละโหนดของที่อยู่:

ตัว DNS เองมีข้อ จำกัด เพียงข้อเดียวเท่านั้นบนป้ายกำกับเฉพาะ
ที่สามารถใช้เพื่อระบุระเบียนทรัพยากร ข้อ จำกัด หนึ่งข้อนั้น
เกี่ยวข้องกับความยาวของฉลากและชื่อเต็ม ความยาวของป้ายกำกับใด ๆ จะ จำกัด อยู่ระหว่าง 1 ถึง 63 octets ชื่อโดเมนแบบเต็มถูก จำกัด ไว้ที่ 255 octets (รวมถึงตัวคั่น)

ดังนั้นด้วยข้อกำหนดของ DNS คุณสามารถมี a.domain.tld


จากย่อหน้าถัดไปในส่วนที่ 11 ของ RFC-2181: 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. พื้นฐานเพราะ a.domain.tld นั้นถูกต้องใน DNS ไม่ได้ทำให้มันเป็นชื่อโฮสต์ที่ถูกต้อง การสิ้นสุดของส่วนที่ 11 อ้างอิงส่วน 6.1.3.5 ของ RFC-1123 ซึ่งอ้างอิงส่วน 2.1 ของตัวเองและ RFC-952 ตามที่กล่าวไว้ในคำตอบของ sysadmin1138
Isaac

การอ้างอิงในตอนท้ายของส่วน 6.1.3.5 พูดถึงข้อ จำกัด น้อยกว่าในอนุสัญญาการตั้งชื่อที่กำหนดไว้ที่ 952 นอกจากนี้ 952 กำหนดตารางโฮสต์ DOD และฉันไม่เชื่อว่ามันจะมีความเกี่ยวข้องมากกว่าข้อกำหนด DNS
coredump

ฉันคิดว่าการเปิดเสรีข้อ จำกัด ที่กล่าวถึงในตอนท้ายของ 6.1.3.5 หมายถึงการอนุญาตให้ตัวละครตัวแรกเป็นตัวเลขเท่านั้น - นี่เป็นการแก้ไขเฉพาะที่กล่าวถึงในส่วนที่ 2.1 ของ RFC เดียวกันนั้น (ซึ่งเป็นหัวข้อที่ 6.1 3.5 อ้างอิง) มันอยู่ในส่วนที่ 2.1 ว่าคำนิยามจาก RFC-952 ถูกอ้างถึงว่าเป็นคำนิยามของชื่อโฮสต์ทางกฎหมาย
Isaac

ตรวจสอบ RFC 920 และ 921 ที่ปฏิบัติต่อการย้ายข้อมูลจาก DARPA เก่าไปยังชื่อโดเมน
coredump

1

ตามที่คุณได้พิจารณาแล้ว RFC 1123 ยังไม่ชัดเจนในเรื่องความยาวนี้

ส่วนที่ 2.1 กล่าวว่า:

ซอฟต์แวร์โฮสต์ต้องจัดการชื่อโฮสต์ได้สูงสุด 63 ตัวอักษรและ SHOULD จัดการชื่อโฮสต์ได้สูงสุด 255 ตัวอักษร

ตั้งแต่ข้อความนี้ได้อย่างมีประสิทธิภาพอย่างสมบูรณ์แทนที่ข้อความจาก RFC 952 มันก็ควรจะถูกนำมาใช้เพื่อบ่งบอกว่าใด ๆ ที่มีความยาวถึง 255 ตัวอักษรเป็นกฎหมาย

โชคไม่ดีที่กลับมาในปี 1989 Internet Draft ไม่ได้รับการตรวจสอบอย่างเข้มงวดอย่างไม่น่าเชื่อที่พวกเขาได้รับในขณะนี้


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. การตีความหมายนี้ไม่เหมาะสมหรือไม่นั่นหมายความว่าคำพูดของคุณไม่ได้แทนที่ข้อความจาก RFC-952 อย่างสมบูรณ์หรือ
Isaac

มันบอกว่า แต่มันผิดอย่างชัดเจน RFC 1123 ยังเปลี่ยนความยาวของชื่อโฮสต์ที่อนุญาตอย่างชัดเจน
Alnitak
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.