_ (ขีดล่าง) ผิดกฎหมายในระเบียน CNAME หรือไม่


9

เราประสบปัญหาในการสร้างระเบียน TXT แบบยาวสำหรับคีย์ DKIM บนเว็บอินเตอร์เฟสของผู้ให้บริการของเรา

แต่ละบรรทัดสามารถยอมรับ 256 อักขระเท่านั้น

เราลองหลายบรรทัดแล้วลองเพิ่ม("ในตอนแรกและ")หลังจากครั้งสุดท้ายตามคำแนะนำ ไม่ทำงาน

จากนั้นเราพยายามสร้าง cname ให้กับเรกคอร์ดบน hoster อื่นซึ่งเราสามารถสร้างเร็กคอร์ด DKIM TXT

แต่ตอนนี้ webinterface บ่นเกี่ยวกับชื่อที่ผิดกฎหมายในการCNAMEบันทึก

mail._domainkey.example.com TXTเป็น ok
mail._domainkey.example.com CNAMEไม่ ok
mail.domainkey.example.com CNAMEก็โอเค แต่ไม่ได้สิ่งที่เราต้องการ

เว็บอินเทอร์เฟซแค่มุ่งมั่นที่จะทำให้เราบ้าหรือเป็น "ผิดกฎหมาย" จริงๆที่จะมีการขีดเส้นใต้CNAMEหรือไม่


1
ผู้ให้บริการกำลังแก้ไขหน้าเว็บขณะที่ฉันกำลังเขียนสิ่งนี้!
Lenne

คำตอบ:


18

ใช่ชื่อ DNS (รวมถึง A / AAAA) อาจมีเฉพาะ[0-9], [a-z], -ดังนั้นขีดเส้นใต้จึงไม่ถูกต้อง โปรดทราบว่าระเบียน TXT ไม่ใช่ชื่อโฮสต์และข้อ จำกัด นี้ไม่มีผลกับมัน และการแก้ไขครั้งสุดท้ายหนึ่งครั้ง: -ไม่สามารถใช้เป็นอักขระตัวแรกได้ดังนั้นmail.-domainkey.our.domจะไม่ถูกต้อง

https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames


การแก้ไขครั้งสุดท้าย: ฉันผิดบางส่วน เมื่อใช้ CNAME เป็นชื่อโฮสต์ข้อ จำกัด ข้างต้นจะถูกนำมาใช้ ดูเหมือนว่า CNAME จะไม่ถือว่าเป็นชื่อโฮสต์ในบริบท DKIM และในกรณีนั้น_ควรเป็นส่วนที่ถูกต้องของรายการ CNAME ดู/programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491


แต่ CNAME เป็นชื่อโฮสต์หรือไม่ เอกสารบางอย่างแสดงให้เห็นว่าใช้ขีดล่างใน cname ดังนั้นจึงใช้งานได้ kb.mailchimp.com/accounts/email-authentication/ …
Lenne

นอกจากนี้ขีดเส้นใต้จะปรากฏในรายการ DNS ในโซนรวมของ Microsoft Windows Active Directory ที่รองรับ Windows Domains อย่างน้อยในเครื่องมือจัดการ DNS ของ Microsoft แต่ฉันไม่แน่ใจว่าขีดเส้นใต้เหล่านั้นเป็นส่วนหนึ่งของชื่อจริงหรือไม่และ Windows รองรับขีดล่างใน DNS คำขอหรือถ้าขีดล่างปรากฏเฉพาะในสแน็ปอินการจัดการ DNS และจริง ๆ แล้วไม่ได้เป็นส่วนหนึ่งของชื่อ
ทอดด์วิลคอกซ์

โปรดทราบว่ารายการ Wikipedia ที่อ้างถึงเกี่ยวข้องกับชื่ออินเทอร์เน็ตไม่ใช่ DNS
Jim B

@ Lenne: CNAME เป็นชื่อโฮสต์ที่ถูกต้องเพราะเป็นชื่อแทนสำหรับโฮสต์ @ToddWilcox: ใช่เรื่องนี้เป็นที่รู้จักกันดีและนี่คือการละเมิดข้อมูลจำเพาะ (โดยเจตนา?) ที่ทำให้ระบบอื่น ๆ ไม่มีปัญหาจำนวนมากอย่างที่ปรากฏใน DNS, DHCP, …แพ็คเก็ตแม้จะไม่ถูกกฎหมายก็ตาม
mirabilos

2
@mirabilos "CNAME เป็นชื่อโฮสต์ที่ถูกต้อง" ไม่เป้าหมาย (RDATA) ของ CNAME เป็นชื่อโดเมนไม่ใช่ชื่อโฮสต์ (ชื่อโดเมนคือชื่อของชื่อโฮสต์ที่เป็นไปได้ทั้งหมด) _foo CNAME _barถูกต้องสมบูรณ์คุณสามารถทดสอบnamed-checkzoneได้
Patrick Mevzek

2

อักขระที่ถูกต้องใด ๆ ที่ได้รับอนุญาตใน DNS ดูhttps://tools.ietf.org/html/rfc2181#section-11

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

ลูกค้าจะต้องตรวจสอบค่าชื่อ EG บันทึก MX อาจมีค่า "Alice" แต่หลังจากค้นหาค่าที่ควรถูกปฏิเสธเนื่องจาก "Alice" ไม่ใช่ที่อยู่อีเมลที่ถูกต้อง

ในกรณีนี้ดูเหมือนว่า hoster ของคุณจะ "ตรวจสอบความถูกต้อง" การป้อนข้อมูลของคุณและพวกเขาควรจะป้อนด้วยตนเองสำหรับคุณ


"อนุญาตให้ใช้อักขระที่ถูกต้องใน DNS" มีความซับซ้อนมากกว่านั้นเล็กน้อย มีชื่อโดเมนและชื่อโฮสต์ ยกเว้นว่ามีการกล่าวเป็นอย่างอื่นทุกที่ที่คุณมีป้ายกำกับซึ่งเป็นชื่อโดเมนซึ่งหมายถึงตัวอักษรใด ๆ ดังนั้น_หรือสิ่งอื่นที่คุณคิดเช่นกัน แต่สำหรับบางระเบียนคุณสามารถใช้ชื่อโฮสต์เท่านั้นและไม่ใช่ชื่อโดเมน ชื่อโฮสต์เป็นเพียงตัวเลขตัวอักษรและเครื่องหมายขีดกลางเท่านั้น ตัวอย่างเช่นเจ้าของAหรือAAAAบันทึกเป็นชื่อโฮสต์ไม่ใช่ชื่อโดเมน RDATA (เป้าหมาย) ของNSระเบียนเป็นชื่อโฮสต์ด้วยไม่ใช่ชื่อโดเมน
Patrick Mevzek

1
"ระเบียน MX อาจมีค่า" Alice "แต่หลังจากค้นหาค่านั้นควรถูกปฏิเสธเนื่องจาก" Alice "ไม่ใช่ที่อยู่อีเมลที่ถูกต้อง" MX RR อ้างอิงที่อยู่อีเมลตั้งแต่เมื่อใด
CVN

0

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


ฉันยังมีปัญหากับ Arduino ซึ่ง libs บางตัวให้ชื่อโฮสต์เช่น ESP_245537 ชื่อนี้จะถูกปฏิเสธเมื่อ DHCPserver พยายามอัปเดต DNS
Lenne

นี่เป็นสิ่งที่ผิด ฉลากของ CNAME _ไม่จำเป็นต้องเป็นชื่อโฮสต์เพื่อให้ตัวละครทุกตัวที่ถูกต้องที่นี่รวมทั้ง
Patrick Mevzek

1
และถึงอย่างนั้นก็ไม่มีกฎเหล่านี้เป็นกฎเก่า พวกเขาถูกห้ามไม่ให้ชื่อโฮสต์ที่เริ่มต้นด้วยหลัก แต่เพื่อรองรับ3com.comตัวอย่างเช่นกฎนี้ผ่อนคลายดูtools.ietf.org/html/rfc1123#page-13 "การเปลี่ยนแปลงหนึ่งในไวยากรณ์ชื่อโฮสต์จะเปลี่ยนไป: ข้อ จำกัด ของอักขระตัวแรก ผ่อนคลายเพื่อให้ตัวอักษรหรือตัวเลข "
Patrick Mevzek

@Lenne หากesp_245537ใช้เป็นชื่อโฮสต์ดังนั้นการอัปเดต DNS จะต้องถูกปฏิเสธเนื่องจากไม่ใช่ชื่อโฮสต์ที่ถูกต้อง หากใช้เป็นชื่อโดเมนการอัปเดต DNS ควรสำเร็จ (ไม่เช่นนั้นจะเป็นข้อผิดพลาด) เนื่องจากเป็นป้ายกำกับ DNS ที่ถูกต้อง
Patrick Mevzek

ฉันเห็นคำใบ้ว่าเป็นไปได้ที่จะแปลอักขระที่ไม่ถูกต้องจาก DHCP ไปเป็น DNS แต่ไม่สามารถใช้งานได้
Lenne

0

@ คำตอบของ Sven ที่มีการแก้ไขนั้นถูกต้องแล้ว แต่เพื่อพูดวลีโดยตรง

TL; DRใช่ขีดเส้นใต้นั้นใช้ได้ในCNAMEเร็กคอร์ดทั้งสองด้านอ่านเหตุผลด้านล่าง

RFC 1034และอื่น ๆ กำหนดบันทึกบนพื้นฐานของ "ชื่อโดเมน" ซึ่งเป็นฉลากที่มีตัวอักษรใด ๆ _เพื่อให้รวมถึง

แต่บางระเบียนมีกฎที่เข้มงวดสำหรับทั้งชื่อเจ้าของและ / หรือข้อมูลทรัพยากร (RDATA) มีเพียงชื่อโฮสต์เท่านั้นที่จะได้รับการยอมรับและแน่นอนว่ากฎอยู่ในขณะนี้ (พวกเขาผ่อนคลายในอดีตที่ชื่อโฮสต์ไม่สามารถเริ่มต้นด้วยตัวเลข) ที่คุณสามารถใช้ตัวอักษร ASCII ใด ๆ (ไม่คำนึงถึงตัวพิมพ์ใหญ่), ASCII ใด ๆ และยัติภังค์ และเพิ่มกฎตำแหน่งพิเศษบางประการ: ไม่มียัติภังค์ที่จุดเริ่มต้นหรือจุดสิ้นสุดและไม่มียัติภังค์สองตำแหน่งที่ตำแหน่ง 3 และ 4 (เพราะ "การจอง" สำหรับ IDNs ที่อยู่ในรูปแบบxn--ที่อนุญาตให้ใช้กับกรณีเท่านั้น)

ตัวอย่างเช่นชื่อเจ้าของAหรือAAAAระเบียนเป็นชื่อโฮสต์ไม่ใช่ชื่อโดเมน ดังนั้น test.example.com A 192.0.2.1สิ่งเหล่านี้จึงไม่ถูกต้อง:

_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1

ง่ายต่อการทดสอบสิ่งต่าง ๆ ด้วยnamed-checkzoneโปรแกรม (ส่วนหนึ่งของbindซอฟต์แวร์ nameserver แต่อาจใช้และติดตั้งแยกต่างหากและเซิร์ฟเวอร์อื่น ๆ อาจมีเครื่องมือตรวจสอบที่คล้ายกันและอาจมีอินเทอร์เฟซออนไลน์สำหรับสิ่งนั้นด้วย) มันเกี่ยวกับ:

$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)

(จำนวนก่อนหน้าINนี้คือ TTL นี่ไม่เกี่ยวข้องกับปัญหาของเราที่นี่ แต่จำเป็นต้องผ่านการตรวจสอบความถูกต้องทางไวยากรณ์ของเรกคอร์ด)

สำหรับเร็กคอร์ดอื่นมันเป็นสิ่งตรงกันข้าม: NSเนื่องจากไม่มีข้อ จำกัด สำหรับเจ้าของ แต่มีข้อ จำกัด ใน "เป้าหมาย" ที่เป็นข้อมูล ข้อมูลสามารถเป็นชื่อโฮสต์เท่านั้นไม่ใช่ชื่อโดเมนเนื่องจากคุณต้องชี้ไปที่เซิร์ฟเวอร์ชื่อที่เชื่อถือได้ซึ่งเป็นโฮสต์ทางกายภาพที่ตอบสนองต่อแบบสอบถาม DNS

ต่อไปนี้CNAMEเป็นคำพูดที่เกี่ยวข้องจาก RFC 1034 ในหัวข้อ 3.6:

"เจ้าของ: ซึ่งเป็นชื่อโดเมนที่พบ RR" ซึ่งหมายความว่าโดยค่าเริ่มต้นชื่อใด ๆ ไม่ใช่แค่ชื่อโฮสต์ (เป็นแหล่งที่มาของระเบียน CNAME)

"RDATA: ซึ่งเป็นประเภทและบางครั้งข้อมูลที่พึ่งพาระดับซึ่งอธิบายถึงทรัพยากร:"

"CNAME ชื่อโดเมน"

ดังนั้นทั้งเจ้าของCNAME(สิ่งที่อยู่ทางซ้ายของมัน) และข้อมูลทรัพยากรที่แนบไปกับมันปลายทาง / เป้าหมาย (สิ่งที่อยู่ทางขวาของมัน) คือชื่อโดเมนไม่ใช่ชื่อโฮสต์เท่านั้น โดยทั่วไปตัวละครใด ๆ ดังนั้นรวมทั้ง_ได้รับอนุญาตทั้งสองด้าน

ง่ายต่อการทดสอบอีกครั้งด้วยnamed-checkzone:

$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.

ไม่มีข้อผิดพลาดใด ๆ เกี่ยวกับCNAME(คาดว่าจะเกิดข้อผิดพลาดอื่น ๆ ตั้งแต่ในโซนปลอมของฉันฉันไม่ได้ใส่SOAหรือNSบันทึกเช่นโซนจริงจะมี)

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