เหตุใดรูทของโดเมนจึงเป็น CNAME ไม่ได้ — และเกร็ดความรู้อื่นๆ เกี่ยวกับ DNS

โพสต์นี้จะใช้คำถามด้านบนเพื่อสำรวจ DNS , dig , A บันทึก CNAME บันทึก และ ALIAS/ANAME บันทึกจากมุมมองของผู้เริ่มต้น มาเริ่มกันเลย

ขั้นแรก ให้คำจำกัดความบางส่วน

• ระบบชื่อโดเมน (DNS):ระบบโดยรวมสำหรับการแปลงชื่อโดเมนที่น่าจดจำของมนุษย์ (example.com) เป็นที่อยู่ IP (93.184.216.34) ที่อยู่ IP เป็นของเซิร์ฟเวอร์ โดยทั่วไปคือเว็บเซิร์ฟเวอร์ ซึ่งจัดเก็บไฟล์ที่จำเป็นในการแสดงหน้าเว็บไว้
• เซิร์ฟเวอร์ DNS (เรียกอีกอย่างว่าเนมเซิร์ฟเวอร์หรือเนมเซิร์ฟเวอร์):ใช้ซอฟต์แวร์ DNS เพื่อเก็บข้อมูลเกี่ยวกับที่อยู่โดเมน มีหลายระดับ — ระดับเหล่านั้นเป็นของ ISP แต่ละรายการ, รูท (ทั้งหมด 13 ระดับทั่วโลก), โดเมนระดับบนสุด (TLD, เช่น '.com') และเซิร์ฟเวอร์ DNS ระดับโดเมน
• ชื่อโดเมน :โดเมน (ตัวอย่าง) ที่รวมกับ TLD (.com) คำว่า 'โดเมน' มักใช้ตรงกันกับชื่อโดเมน แม้ว่าจะต่างกัน เมื่อคุณซื้อ 'โดเมน' จากผู้รับจดทะเบียนหรือผู้ค้าปลีก เท่ากับว่าคุณซื้อสิทธิ์ในชื่อโดเมนเฉพาะ (example.com) และโดเมนย่อยใดๆ ที่คุณต้องการสร้าง (my-site.example.com, mail.example.com, เป็นต้น)

ขั้นตอนการค้นหาระดับสูง

ขั้นตอนระดับสูงของสิ่งที่เกิดขึ้นเมื่อคุณพิมพ์ “example.com” ลงในเบราว์เซอร์ของคุณสามารถทำให้ง่ายขึ้นเพื่อลบการกระโดดไปยังเซิร์ฟเวอร์ ISP, Root และ TLD DNS ดังนี้:

โดยทั่วไป โดเมนจะมีเนมเซิร์ฟเวอร์ตั้งแต่สองเครื่องขึ้นไป ซึ่งประกอบด้วยบันทึกที่เกี่ยวข้องกับชื่อโดเมน (example.com)

สามารถจัดเก็บบันทึกได้หลายประเภท ซึ่งส่วนใหญ่สามารถมีได้หลายรายการต่อประเภท:

• A :ระเบียนที่อยู่ที่จับคู่ชื่อโดเมนกับที่อยู่ IP
• CNAME :บันทึกชื่อที่เป็นที่ยอมรับ ใช้แทนชื่อโดเมนหนึ่ง (หรือชื่อโดเมนย่อย) ไปยังอีกชื่อหนึ่ง เราจะดูรายละเอียดเพิ่มเติมในภายหลัง
• MX :บันทึก Mail eXchange ที่บอกตัวแทนจัดส่งอีเมลว่าควรส่งอีเมลของคุณไปที่ใด
• TXT :บันทึกข้อความแบบยืดหยุ่น สำหรับจัดเก็บสตริงเพื่อการใช้งานที่หลากหลาย
• SOA :ระเบียน Start of Authority เอกพจน์เก็บไว้ที่ระดับบนสุดของโดเมน ประกอบด้วยข้อมูลที่จำเป็นเฉพาะเกี่ยวกับโดเมน เช่น เนมเซิร์ฟเวอร์หลัก
• NS :เนมเซิร์ฟเวอร์ที่เชื่อมโยงกับโดเมน

เมื่ออุปกรณ์ของคุณส่งแบบสอบถามที่ไปถึงเนมเซิร์ฟเวอร์ เซิร์ฟเวอร์จะค้นหา A ในโหนดระเบียนของโดเมน บันทึก และที่อยู่ IP ที่เก็บไว้ที่เกี่ยวข้อง (example.com:93.184.216.34) จากนั้นจะส่งกลับไปยังอุปกรณ์เพื่อใช้ส่งคำขอไปยังเว็บเซิร์ฟเวอร์ที่ถูกต้องเพื่อเรียกข้อมูลหน้าเว็บหรือทรัพยากรที่ร้องขอ

ใช้ 'ขุด'

dig (ข้อมูลโดเมน groper ) เป็นเครื่องมือบรรทัดคำสั่งสำหรับการสืบค้นเซิร์ฟเวอร์ DNS โดยทั่วไปคำสั่งนี้ใช้สำหรับการแก้ปัญหา หรือตอนนี้เพื่อทำความเข้าใจเพิ่มเติมเกี่ยวกับการตั้งค่าระบบ

$ dig example.com ส่งผลให้มีการพิมพ์ตอบกลับที่ยาวนานไปยังเทอร์มินัล ซึ่งเป็นเอาต์พุตเริ่มต้นที่มีรายละเอียดที่นี่ ซึ่งเราสนใจใน ANSWER SECTION .

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

และแล้วเราจะเห็นว่า example.com ส่งกลับ A บันทึกของ 93.184.216.34 . บางครั้งโดเมนจะมี A . มากกว่าหนึ่งรายการ บันทึก หากเว็บเซิร์ฟเวอร์มากกว่าหนึ่งเครื่องสามารถให้ข้อมูลที่จำเป็นได้

ยังมีอีก! หากเราลองใช้ตัวอย่างอื่นๆ เราจะพบว่ามีบันทึกทั่วไปอีกรายการหนึ่งปรากฏขึ้น:CNAME .

$ dig www.skyscanner.net :

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.

e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

การใช้ +short ธงทำให้เรามองเห็นเส้นทางที่เกิดขึ้นได้อย่างชัดเจน:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

A CNAME บันทึกอนุญาตให้ใช้ชื่อโดเมนเป็นชื่อแทนสำหรับโดเมนตามรูปแบบบัญญัติ (จริง) อื่นได้

เมื่อเซิร์ฟเวอร์ DNS ส่งคืน CNAME บันทึกจะไม่ส่งคืนให้กับลูกค้า แต่จะค้นหาชื่อโดเมนที่ส่งคืนอีกครั้ง และในทางกลับกัน A ที่อยู่ IP ของบันทึก ห่วงโซ่นี้สามารถดำเนินการต่อได้หลาย CNAME ระดับลึก แต่จากนั้นก็ประสบปัญหาประสิทธิภาพเล็กน้อยจากการค้นหาหลายครั้งก่อนที่จะทำการแคช

ตัวอย่างง่ายๆ ของสิ่งนี้อาจเป็นได้ถ้าคุณมีเซิร์ฟเวอร์ที่คุณเก็บรูปภาพทั้งหมดไว้ ปกติคุณสามารถเข้าถึงได้ผ่าน photos.example.com . อย่างไรก็ตาม คุณอาจต้องการอนุญาตให้เข้าถึงผ่าน photographs.example.com . วิธีหนึ่งที่จะทำให้สิ่งนี้เป็นไปได้คือการเพิ่ม CNAME บันทึกว่าจุด photographs ถึง photos . ซึ่งหมายความว่าเมื่อมีผู้เยี่ยมชม photographs.example.com พวกเขาจะได้รับเนื้อหาเช่นเดียวกับ photos.example.com .

การใช้แบบสอบถาม $ dig photographs.example.com เราจะเห็น:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

สิ่งสำคัญที่ควรทราบคือ CNAME คือชิ้นนั้นทางด้านขวามือ ด้านซ้ายมือคือชื่อนามแฝงหรือป้ายกำกับ

การใช้งานทั่วไปอีกอย่างสำหรับ www โดเมนย่อย หลังจากซื้อ example.com คุณยังต้องการผู้ใช้ที่พิมพ์ www.example.com เพื่อดูเนื้อหาเดียวกัน

เป็นที่น่าสังเกตว่า example.com สามารถเรียกว่า apex, root หรือชื่อโดเมนเปล่าได้

ทางเลือกหนึ่งคือตั้งค่าอีก A บันทึกชี้ไปที่ที่อยู่ IP เดียวกันกับ example.com . นี้ถูกต้องสมบูรณ์และเป็นสิ่งที่ example.com จริง ทำได้ แต่ก็ไม่ได้ขยายขนาดได้ดี จะเกิดอะไรขึ้นหากคุณต้องการอัปเดตที่อยู่ IP ที่ example.com ชี้ไปที่? คุณจะต้องอัปเดตสำหรับ www โดเมนย่อยและอื่น ๆ ที่คุณอาจใช้

ถ้าเป็น CNAME บันทึกถูกใช้เป็นนามแฝง www.example.com ให้ชี้ไปที่ example.com ดังนั้นจะต้องอัปเดตเฉพาะโดเมนรูทเท่านั้น เนื่องจากโหนดอื่นๆ ทั้งหมดชี้ไปที่โดเมนนั้น

ข้อจำกัด CNAME

ในขณะที่มีการเขียนมาตรฐาน DNS มีการกำหนดกฎบางอย่างเพื่อควบคุมการใช้งาน RFC 1912 และ RFC 2181 กำหนดว่า:

• SOA และ NS ระเบียนจำเป็นต้องแสดงที่โดเมนราก
• CNAME ระเบียนสามารถมีได้เพียงระเบียนเดียวและไม่สามารถใช้ร่วมกับระเบียนทรัพยากรอื่น ( DNSSEC SIG , NXT และ KEY RR บันทึกยกเว้น)

ไม่รวม CNAME ถูกใช้บนโดเมนราก เนื่องจากกฎทั้งสองข้อจะขัดแย้งกันเอง

สิ่งสำคัญที่นี่คือข้อจำกัดตามสัญญา ไม่ใช่ข้อจำกัดทางเทคนิค สามารถใช้ CNAME . ได้ ที่รูท แต่อาจส่งผลให้เกิดข้อผิดพลาดที่ไม่คาดคิดได้ เนื่องจากเป็นการทำลายสัญญาของพฤติกรรมที่คาดไว้

Cloudflare ได้ยกตัวอย่างเรื่องนี้ โดยอธิบายถึงปัญหาที่พวกเขาพบกับเมลเซิร์ฟเวอร์ Microsoft Exchange หลังจากใช้ CNAME บนโดเมนราก:

โดยทั่วไปโดเมนจะกำหนดเซิร์ฟเวอร์ที่จัดการอีเมลผ่านสิ่งที่เรียกว่า MX Record ปัญหาคือเซิร์ฟเวอร์ Exchange … สามารถรับ CNAME ที่ระเบียนรูท และจากนั้นไม่ปฏิบัติตามการตั้งค่า CNAME ที่ระเบียน MX อย่างเหมาะสม คุณไม่สามารถตำหนิการแลกเปลี่ยนได้จริงๆ ทำงานภายใต้สมมติฐานที่กำหนดโดยข้อกำหนด DNS

ที่นี่คุณจะเห็นข้อเสียที่อาจปรากฏในซอฟต์แวร์เซิร์ฟเวอร์หรือไลบรารีต่างๆ เนื่องจากมีการกำหนดมาตรฐานสำหรับ CNAME ที่จะเป็นเท่านั้น บันทึกที่โหนด ไม่มีการค้นหาระเบียนอื่น บันทึกอื่น ๆ ทั้งหมดจะถูกละเว้นโดยไม่มีข้อความเตือนหรือข้อผิดพลาด แม้ว่า MX บันทึกถูกตั้งค่าให้รับอีเมล MX จะถูกละเลยราวกับว่าไม่มีอยู่จริงเพราะว่า CNAME จะได้รับการประเมินก่อน เช่นเดียวกับถ้ามี A บันทึก:CNAME จะมีความสำคัญกว่าและ A บันทึกจะไม่ถูกอ่าน

อินเทอร์เน็ตยุคใหม่

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

ในภูมิทัศน์อินเทอร์เน็ตสมัยใหม่ สิ่งนั้นจะไม่เป็นเช่นนั้นอีกต่อไป โลกนี้แตกต่างจากตอนที่เขียนมาตรฐาน DNS มาก

คุณอาจเลือกใช้แพลตฟอร์มเป็นผู้ให้บริการ (PaaS) เช่น Heroku และจัดเก็บเนื้อหาบนเว็บเซิร์ฟเวอร์ของพวกเขา คุณควบคุมเนื้อหาได้ แต่ไม่ใช่โครงสร้างพื้นฐาน และผู้ให้บริการ PaaS ทำหน้าที่ดูแลเครือข่ายอย่างหนัก โดยทั่วไปพวกเขาจะให้ URL แก่คุณ (my-app.herokuapp.com ) ซึ่งเป็นโดเมนย่อยของโดเมนราก และคุณสามารถดูที่อยู่ IP สำหรับเว็บเซิร์ฟเวอร์ที่เนื้อหาของคุณเปิดอยู่ แต่ทั้งหมดนี้อยู่ภายใต้การควบคุมของผู้ให้บริการ PaaS และจะเปลี่ยนแปลงโดยไม่มีการเตือน

ขนาดและความถี่ของการเปลี่ยนแปลงแบ็กเอนด์ที่ทำโดยผู้ให้บริการ PaaS อาจทำให้การรักษาโดเมนรากของคุณ A ทำได้ยาก บันทึกชี้ไปที่ที่อยู่ IP เดียว คุณควรจะทำสิ่งนี้:

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

เพื่อให้ Heroku (หรือผู้ให้บริการโฮสต์ที่คุณเลือก) สามารถจัดการการอัปเดต A บันทึกว่า CNAME ชี้ไปโดยไม่มีการเปลี่ยนแปลงใด ๆ ในด้านของคุณ อย่างไรก็ตาม อย่างที่เราทราบกันดีอยู่แล้วว่าสิ่งนี้ทำให้ข้อกำหนด DNS เสียหาย ดังนั้นจึงเป็นความคิดที่แย่มาก

เป็นไปได้ที่จะใช้การเปลี่ยนเส้นทาง 301/302 จาก example.com ถึง www.example.com. อย่างไรก็ตาม คำสั่งนั้นเกิดขึ้นบนเว็บเซิร์ฟเวอร์ (ดังนั้น ยังคงมีปัญหาในการใช้ A ที่แก้ไขแล้ว บันทึกใน DNS เพื่อชี้ไปที่เว็บเซิร์ฟเวอร์นั้น) หรือผู้ให้บริการ DNS ที่กำหนดเองเปลี่ยนเส้นทาง (ที่มีปัญหากับ HTTPS)

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

วิธีแก้ปัญหา

ขณะนี้ผู้ให้บริการ DNS หลายรายได้พัฒนาโซลูชันแบบกำหนดเองเพื่อแก้ไขปัญหานี้ รวมถึง:

• ALIAS ที่ DNSimple
• ANAME ที่ DNS Made Easy
• ANAME ที่ easyDNS
• CNAME (เสมือน) ที่ CloudFlare

เหล่านี้เป็นประเภทบันทึกเสมือนทั้งหมดที่มี CNAME เช่นพฤติกรรมที่ไม่มีข้อเสีย การใช้งานที่แน่นอนอาจแตกต่างกัน แต่ในระดับสูงเมื่อเซิร์ฟเวอร์ DNS เห็นประเภทระเบียนเสมือนประเภทใดประเภทหนึ่งเหล่านี้จะทำหน้าที่เป็นตัวแก้ไข DNS มันติดตามลูกโซ่ที่สร้างโดยนามแฝงจนกว่าจะแก้ไขที่ A บันทึก (หรือบันทึก) และส่งคืน A . เหล่านี้ บันทึกไปยังเซิร์ฟเวอร์ DNS สิ่งนี้ 'แผ่' CNAME โยงเข้ากับ A ระเบียนที่ส่งคืน และแยกไม่ออกจากแบบสอบถามที่ส่ง แบบสอบถามเห็นเฉพาะ A . ล้วนๆ ซึ่งไม่ทำลายข้อกำหนด DNS และไม่มีข้อเสียของ CNAME .

บันทึกเสมือนเหล่านี้สามารถนั่งข้างบันทึกอื่น ๆ ที่รูทโดยไม่ต้องกลัวว่าจะมีพฤติกรรมที่ไม่ได้ตั้งใจ ขึ้นอยู่กับวิธีการของผู้ให้บริการในการแก้ปัญหา DNS เมื่อทำตาม CNAME เครือข่ายอาจมีประโยชน์ด้านประสิทธิภาพจากการแคชการค้นหาก่อนหน้า

สำหรับการตั้งค่า DNSimple เราจะกำหนดค่าดังต่อไปนี้ โซลูชันนี้มีข้อดีทั้งหมดของการสร้างนามแฝงชื่อโดเมน และไม่มีความเสี่ยงใด ๆ ในการใช้งานที่ระดับราก

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

ขอบคุณที่อ่าน! ?

เช่นเคย เปิดสำหรับการแก้ไขหรือจุดเพิ่มเติม

ทรัพยากร

• เซิร์ฟเวอร์ DNS คืออะไร
• ตั้งค่าเซิร์ฟเวอร์ชื่อ DNS
• หน้าสนับสนุน DNSimple และบล็อก ALIAS
• การสนับสนุน Cloudflare และบล็อก CNAME
• dig วิธีการ
• โพสต์ Stack Overflow หรือ StackExchange ที่ยอดเยี่ยมหลายรายการ
• รายการ Wikipedia ที่เขียนได้ดี
• บล็อก Netlify 'ถึง www หรือไม่ www'