โดเมนย่อย (ชื่อโดเมน) สามารถมีขีดล่าง“ _” อยู่ในนั้นได้หรือไม่?

โดเมนย่อย (ชื่อโดเมน) มีขีดล่าง_ได้หรือไม่?

คำตอบส่วนใหญ่ให้ที่นี่เป็นเท็จ มันถูกกฎหมายอย่างสมบูรณ์แบบที่จะมีการขีดเส้นใต้ในชื่อโดเมน ให้ฉันอ้างอิงมาตรฐาน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 "ชื่อโฮสต์และตัวเลข" ซึ่ง จำกัดชื่อโฮสต์ไว้ที่ตัวอักษร - ตัวเลข - เครื่องหมายขีดกลาง

หมายเหตุเกี่ยวกับคำศัพท์เพิ่มเติมจากคำตอบของ Bortzmeyer

หนึ่งควรมีความชัดเจนเกี่ยวกับคำจำกัดความ ตามที่ใช้ที่นี่:

• ชื่อโดเมนคือตัวระบุของทรัพยากรในฐานข้อมูล DNS
• labelเป็นส่วนหนึ่งของชื่อโดเมนระหว่างจุด
• ชื่อโฮสต์เป็นชื่อโดเมนชนิดพิเศษที่ระบุโฮสต์อินเทอร์เน็ต

ชื่อโฮสต์อยู่ภายใต้ข้อ จำกัด ของRFC 952และผ่อนคลายเล็กน้อยของ RFC 1123

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

... [ความจริงที่ว่า] ฉลากไบนารีใด ๆ สามารถมีระเบียน MX ไม่ได้หมายความว่าชื่อไบนารีใด ๆ ที่สามารถใช้เป็นส่วนโฮสต์ของที่อยู่อีเมล ...

ดังนั้นขีดล่างในชื่อโฮสต์จึงเป็นแบบไม่ต้องขีดเส้นใต้ในชื่อโดเมนจึงเป็น -a

ในทางปฏิบัติเราอาจเห็นชื่อโฮสต์ที่มีเครื่องหมายขีดล่าง ดังที่หลักการความแข็งแกร่งกล่าวไว้ว่า: "จงระมัดระวังในสิ่งที่คุณส่งให้เสรีในสิ่งที่คุณยอมรับ"

หมายเหตุเกี่ยวกับการเข้ารหัส

ในศตวรรษที่ 21 ปรากฎว่าชื่อโฮสต์และชื่อโดเมนอาจเป็นสากล! นี่หมายถึงการหันไปเข้ารหัสในกรณีของฉลากที่มีตัวละครที่อยู่นอกชุดที่อนุญาต

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

RFC ครั้งแรกสำหรับการทำให้เป็นสากลคือRFC 3490ของเดือนมีนาคม 2003, "Internationalizing Domain Names in Applications (IDNA)" วันนี้เรามี:

• RFC 5890 "IDNA: คำจำกัดความและกรอบงานเอกสาร"
• RFC 5891 "IDNA: โปรโตคอล"
• RFC 5892 "คะแนนโค้ด Unicode และ IDNA"
• RFC 5893 "สคริปต์จากขวาไปซ้ายสำหรับ IDNA"
• RFC 5894 "IDNA: พื้นหลัง, คำอธิบาย, และเหตุผล"
• RFC 5895 "อักขระการแมปสำหรับ IDNA 2008"

คุณอาจต้องการตรวจสอบรายการ Wikipedia

RFC 5890แนะนำคำว่าฉลาก LDH (Letter-Digit-Hypen)สำหรับฉลากที่ใช้ในชื่อโฮสต์และพูดว่า:

นี่คือรูปแบบฉลากคลาสสิกที่ใช้แม้ว่าจะมีข้อ จำกัด เพิ่มเติมบางอย่างในชื่อโฮสต์ (RFC 952) ไวยากรณ์ของมันเหมือนกับที่อธิบายไว้ว่า "ไวยากรณ์ชื่อที่ต้องการ" ในส่วน 3.5 ของ RFC 1034 ตามที่แก้ไขโดย RFC 1123 โดยสังเขปมันเป็นสตริงที่ประกอบด้วยตัวอักษร ASCII ตัวเลขและยัติภังค์ที่มีข้อ จำกัด เพิ่มเติมที่ยัติภังค์ไม่สามารถทำได้ ปรากฏที่จุดเริ่มต้นหรือจุดสิ้นสุดของสตริง เช่นเดียวกับป้ายกำกับ DNS ทั้งหมดความยาวทั้งหมดต้องไม่เกิน 63 octets

ย้อนกลับไปสู่ช่วงเวลาที่เรียบง่ายขึ้นร่างอินเทอร์เน็ตนี้เป็นข้อเสนอเริ่มต้นสำหรับการทำให้ชื่อโฮสต์เป็นสากล ชื่อโฮสต์ที่มีตัวอักษรต่างประเทศอาจจะถูกเข้ารหัสโดยใช้ตัวอย่างเช่น'RACE' เข้ารหัส

ผู้เขียนบันทึกข้อเสนอ 'การเข้ารหัส RACE':

ตาม RFC 1035 ส่วนของโฮสต์จะต้องตรงตามตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เริ่มต้นและลงท้ายด้วยตัวอักษรหรือตัวเลขและมีเฉพาะตัวอักษรตัวเลขและอักขระยัติภังค์ ("-") แน่นอนว่านี้ไม่รวมอักขระสากลและตัวละครอื่น ๆ อีกมากมายในละคร ASCII นอกจากนี้ส่วนของชื่อโดเมนจะต้องมีความยาว 63 octets หรือสั้นกว่า .... ส่วนของชื่อหลังการแปลงทั้งหมดที่มีอักขระสากลเริ่มต้นด้วยสตริง "bq--" (... ) สตริง "bq--" ถูกเลือกเพราะมันไม่น่าเป็นไปได้อย่างยิ่งที่จะมีอยู่ในส่วนของโฮสต์ก่อนที่จะสร้างสเปคนี้

มีอีกสิ่งหนึ่งที่คุณอาจต้องทราบคือ: หากส่วนโฮสต์หรือโดเมนย่อยของ url มีขีดล่าง IE9 (ไม่ได้ทดสอบรุ่นอื่น) จะไม่สามารถเขียนคุกกี้ได้

ดังนั้นควรระวังให้ดี :-)

การชี้แจงbortzmeyerและDavid Tonhoferป้ายชื่อโดเมนและชื่อโดเมนย่อยสามารถมีขีดล่างชั้นนำ แต่ไม่มีที่อื่นเลย

ดังที่David Tonhoferเขียนไว้ฉลากเป็นชิ้นส่วนที่อยู่ในช่วงระหว่างกำหนดและควรปฏิบัติตามกฎ LDH ยกเว้นเมื่อระบุป้ายบริการและป้ายพอร์ตเพื่อแยกความแตกต่างจากป้ายกำกับปกติ จากนั้นจะต้องเกิดขึ้นที่จุดเริ่มต้นของป้ายกำกับซึ่งควรเป็น " ชื่อย่อ " จากชื่อบริการและหมายเลขพอร์ตของรีจิสทรีหมายเลขพอร์ตที่ไม่มีการนำ 0 หรือโพรโทคอล (เช่น. tcp, udp) ฉลากบริการเหล่านี้จำกัดความยาวไม่เกิน 15 อักขระ

• RFC2782ระบุคำนำหน้าบริการย่อยโดเมนย่อยที่มีเครื่องหมายขีดล่าง
• RFC6698ระบุหมายเลขพอร์ตที่นำหน้าด้วยขีดล่างในบันทึกใบรับรอง TLSA

ตรงกันข้ามกับคำตอบของDavid Tonhofer IDN ไม่อนุญาตให้เข้ารหัสขีดล่าง ('_' U + 005F LOW LINE) หรืออักขระ ASCII ที่ไม่ถูกต้องอื่น ๆ

จากRFC5890

[.. ] สองชุดย่อยใหม่ของฉลาก LDH ถูกสร้างขึ้นโดยการแนะนำ IDNA สิ่งเหล่านี้เรียกว่าป้ายกำกับ LDH สำรอง (ป้าย R-LDH) และป้ายกำกับ LDH ที่ไม่สงวน (ป้าย NR-LDH) ป้าย LDH ลิขสิทธิ์ที่เรียกว่า "ชื่อโดเมนที่ติดแท็ก" ในบริบทอื่น ๆ บางมีคุณสมบัติที่พวกเขามี "-" ในตัวละครที่สามและสี่แต่ที่อื่นให้สอดคล้องกับกฎระเบียบของฉลาก LDH

Punycode เข้ารหัสรหัส ASCII ทั้งหมดเป็น ASCII โดยตรงรวมถึงขีดล่าง ผลลัพธ์ R-LDH จะไม่สอดคล้องกับกฎฉลาก LDH ตัวอย่างเช่นΣ_.comจะถูกเข้ารหัสตามxn--_-zmb.comที่ละเมิดกฎ อาจมี codepoint homographic ซึ่งดูเหมือนว่าขีดเส้นใต้ที่สามารถเข้ารหัสตามกฎหมาย (อาจเป็น '＿' U + FF3F full bandwidth low line) แต่ codepoints ชนิดนี้จะถูกจัดประเภทเป็น DISALLOWED โดยRFC5892ภายใต้ 2.3 IgnorableProperties

RACE (รูปแบบการเข้ารหัส IDN อื่น ๆ ที่เสนอ) ไม่ได้รับการยอมรับว่าเป็นมาตรฐานโดย IETF และไม่ควรใช้

ฉันติดตามลิงก์ไปยัง RFC1034 และอ่านส่วนใหญ่และรู้สึกประหลาดใจที่เห็นสิ่งนี้:

เลเบลต้องเป็นไปตามกฎสำหรับชื่อโฮสต์ ARPANET พวกเขาจะต้องเริ่มต้นด้วยตัวอักษรลงท้ายด้วยตัวอักษรหรือตัวเลขและมีการตกแต่งภายในเป็นตัวอักษรภายในตัวอักษรตัวเลขและเครื่องหมายขีดคั่น นอกจากนี้ยังมีข้อ จำกัด บางอย่างเกี่ยวกับความยาว ป้ายกำกับต้องมีความยาวไม่เกิน 63 อักขระ

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

ฉันติดตามลิงก์ไปยัง RFC2181 และอ่านบางส่วน โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับปัญหาของชื่อที่มีสิทธิ์หรือเป็นที่ยอมรับชื่อและปัญหาของสิ่งที่ทำให้ป้ายชื่อ DNS ที่ถูกต้อง

ตามที่โพสต์ไว้ก่อนหน้านี้ระบุว่ามีข้อจำกัดความยาวและรวมเข้าด้วยกัน:

(เกี่ยวกับชื่อและป้ายกำกับที่ถูกต้อง)

สิ่งเหล่านี้มีการระบุไว้อย่างเพียงพอแล้วอย่างไรก็ตามบางครั้งข้อมูลจำเพาะก็อาจถูกเพิกเฉย เราพยายามที่จะเสริมรายละเอียดที่มีอยู่

ชนิดของใบฉันสงสัยว่า "จำกัด เพียงความยาว" คือ "เพียงพอ" พวกเราจะเริ่มเห็นชื่อโดเมนเช่น @ # $% !! เร็ว ๆ นี้? อินเทอร์เน็ตไม่เพียงพอหรือไม่

เมื่อเร็ว ๆ นี้ฟอรัม CAB (*) ตัดสินใจว่า

ใบรับรองทั้งหมดที่มีอักขระขีดล่างในรายการ dNSName ใด ๆ และมีระยะเวลาที่ถูกต้องมากกว่า 30 วันจะต้องถูกเพิกถอนก่อนวันที่ 15 มกราคม 2019 https://cabforum.org/2018/11/12/ballot-sc-12- พระอาทิตย์ตกของขีดใน dnsnames /

ซึ่งหมายความว่าคุณไม่ได้รับอนุญาตให้ใช้ขีดล่างในโดเมนที่จะมีใบรับรอง ssl / tls

(*) ฟอรัมผู้ออกใบรับรอง (CA / เบราว์เซอร์ฟอรัม) เป็นการรวบรวมอาสาสมัครของผู้ออกใบรับรองชั้นนำ (ตามที่กำหนดไว้ในส่วน 2.1 (a) (1) และ (2) ด้านล่าง) และผู้จำหน่ายซอฟต์แวร์อินเทอร์เน็ตเบราว์เซอร์ ใช้ใบรับรอง (ผู้บริโภคใบรับรองตามที่กำหนดไว้ในส่วน 2.1 (a) (3) ด้านล่าง)

TLD ของแต่ละบุคคลสามารถวางกฎและข้อ จำกัด ของตนเองในชื่อโดเมนตามที่เห็นสมควรเช่นเพื่อรองรับภาษาท้องถิ่น

ตัวอย่างเช่นตามCIRA.caอนุญาตให้ใช้ชื่อโดเมนของแคนาดา:

• ตัวอักษรaผ่านzและอักขระที่เน้นเสียงต่อไปนี้: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. โปรดทราบว่าชื่อโดเมนจะไม่ตรงตามตัวพิมพ์ใหญ่ - เล็ก ซึ่งหมายความว่าจะไม่มีความแตกต่างระหว่างตัวอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ( A= a)

• ตัวเลข0123456789และ

• อักขระยัติภังค์ (" -) (แม้ว่าจะไม่สามารถใช้ในการเริ่มต้นหรือสิ้นสุดชื่อโดเมน)

ความยาวสูงสุดคือ 63 อักขระยกเว้นอักขระที่เน้นเสียงแต่ละตัวจะลดจำนวนที่ จำกัด ไว้4ตัว

( ที่มา )

_{อนึ่งสิ่งนี้จะช่วยให้มีความเป็นไปได้ของชื่อโดเมนประมาณ4 Quadragintillion}

นี่ 2 เซ็นต์ของฉันจากโลก Java:

จากคอนโซล Spark Scala ด้วย Java 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

มันเป็นความคิดที่ไม่ดีแน่นอน ^^

เพิ่งสร้างโครงการในท้องถิ่น (พร้อมคนจรจัด) และมันทำงานได้อย่างสมบูรณ์แบบเมื่อเข้าถึงผ่านที่อยู่ IP จากนั้นฉันเพิ่ม some_name.test ไปยังไฟล์โฮสต์และพยายามเข้าถึงด้วยวิธีนั้น แต่ฉันได้รับ "คำขอไม่ดี - 400" ตลอดเวลา เสียเวลาหลายชั่วโมงจนกระทั่งฉันพบว่าเพิ่งเปลี่ยนชื่อโดเมนเป็น some-name.test แก้ปัญหาได้ อย่างน้อยก็ในเครื่องบน Mac OS มันไม่ทำงาน

ไม่คุณไม่สามารถใช้ขีดล่างในโดเมนย่อย แต่ใช้ไฮเปอร์ (เครื่องหมายขีดกลาง) เช่น my-subdomain.agahost.com เป็นที่ยอมรับและ my_subdomain.agahost.com จะไม่เป็นที่ยอมรับ

ไม่ใช่ถ้าคุณต้องการให้มันแก้ไขบนอินเทอร์เน็ต

คุณไม่สามารถ: http://my_subdomain.example.comไม่ถูกต้อง

คุณสามารถมี: http://my-subdomain.example.comพร้อมกับยัติภังค์