home

หน้าแรก
 Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> ระบบเครือข่าย >> อินเทอร์เน็ต

เข้าใจ DNS: ทำไม Domain Root ไม่สามารถเป็น CNAME ได้ และพื้นฐาน DNS

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

ก่อนอื่น 定义 一些 定义

  • Domain Name System (DNS): ระบบแปลง Domain Name ที่มนุษย์จำง่าย (example.com) เป็น IP Address (93.184.216.34) IP Address ของ Server (มักเป็น Web Server) ที่เก็บไฟล์แสดง Webpage
  • DNS Server (Name Server/Nameserver): ใช้ DNS Software เก็บข้อมูล Domain Addresses มีหลาย Level — ISP, Root (13 ตัว worldwide), TLD (เช่น .com), และ Domain-level DNS Servers
  • Domain Name: Domain (example) + TLD (.com) คำว่า 'Domain' ใช้แทน Domain Name บ่อย แต่ต่างกัน ตอนซื้อ 'Domain' จาก Registrar/Reseller ซื้อสิทธิ์ Domain Name (example.com) และ Subdomains ที่ต้องการ (my-site.example.com, mail.example.com, etc)

High-level Query Flow (ขั้นตอน Query ระดับสูง)

Flow ระดับสูงตอนพิมพ์ "example.com" ใน Browser ลด Hops ไป ISP, Root, TLD DNS Servers ได้แบบนี้:

เข้าใจ DNS: ทำไม Domain Root ไม่สามารถเป็น CNAME ได้ และพื้นฐาน DNS
Simplified DNS Request Flow, รายละเอียดมากกว่านี้ใน Detailed Flow

Domain ปกติมี Name Servers 2 ตัวขึ้นไป เก็บ Records เกี่ยว Domain Name (example.com)

Record Types หลายแบบ เก็บได้หลาย Entry ต่อ Type:

  • A: Address Records Map Domain Name ไป IP Address
  • CNAME: Canonical Name Record Alias Domain/Subdomain ไป Domain อื่น ดูรายละเอียดหลัง
  • MX: Mail eXchange Records บอก Email Delivery Agents ส่ง Email ไปไหน
  • TXT: Text Records ยืดหย่น เก็บ Strings หลายวัตถุประสงค์
  • SOA: Start of Authority Record เดียวที่ Top Level Domain มี Info บังคับ เช่น Primary Name Server
  • NS: Name Servers ของ Domain

Device ส่ง Query ถึง Name Server Server หา A Record ใน Domain's Record Node และ IP Address ที่เก็บ (example.com: 93.184.216.34) คืนให้ Device ใช้ Request Web Server ให้ Webpage/Resource ที่ขอ

ใช้ 'dig'

dig (Domain Information Groper) Command-line Tool Query DNS Servers ใช้ Troubleshooting หรือเข้าใจ Setup ระบบ

$ dig example.com ได้ Response ยาวใน Terminal Default Output รายละเอียดที่นี่ สนใจ ANSWER SECTION

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

เห็น example.com คืน A Record 93.184.216.34 Domain บางอันมี A Records หลายตัว ถ้ามี Web Servers หลายตัวให้ Info

ยังมีอีก! ลองตัวอย่างอื่น จะเห็น Record พบบ่อย: 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

Flag +short แสดง Path ชัดเจน:

$ dig www.skyscanner.net +short

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

CNAME

CNAME Record ให้ Domain Name ใช้เป็น Alias สำหรับ Canonical (True) Domain อื่น

DNS Server คืน CNAME Record ไม่คืนให้ Client ตรงๆ แต่ Look Up Domain Name ที่คืนมาใหม่ คืน A Record IP Address Chain นี้ลึกหลาย CNAME Levels ได้ แต่มี Minor Performance Hits จาก Multiple Lookups ก่อน Caching

ตัวอย่างง่าย: มี Server เก็บรูป เข้าถึงปกติ photos.example.com อยากให้เข้าถึง photographs.example.com ได้ วิธีหนึ่งเพิ่ม CNAME Point photographs ไป photos ผู้ใช้เยี่ยม photographs.example.com ได้ Content เหมือน photos.example.com

Query $ dig photographs.example.com จะเห็น:

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

สำคัญ: CNAME คือข้างขวา ด้านซ้ายคือ Alias Name หรือ Label

Use Case พบบ่อย: Subdomain www ซื้อ example.com อยากให้ www.example.com แสดง Content เดียวกัน

ค่าเรียก example.com ว่า Apex, Root, หรือ Naked Domain Name

วิธีหนึ่ง: Setup A Record อีกตัว Point IP เดียวกับ example.com Valid ทั้งหมด example.com จริงทำแบบนี้ แต่ไม่ Scale Good ถ้าต้อง Update IP ของ example.com ต้อง Update www Subdomain และ Subdomains อื่นๆ ด้วย

ถ้าใช้ CNAME Alias www.example.com Point ไป example.com แค่ Root Domain ต้อง Update อื่นๆ Point ไป Root แล้ว

CNAME Limitations (ข้อจำกัด CNAME)

ตอนเขียน DNS Standards กำหนด Rules ระเบียบการใช้ RFC 1912 และ RFC 2181 ระบุ:

  • SOA และ NS Records Mandatory อยู่ที่ Root Domain
  • CNAME Records มีได้แค่ Single Record ไม่รวมกับ Resource Records อื่นได้ (DNSSEC SIG, NXT, KEY RR Records ยกเว้น)

Exception CNAME ใช้ที่ Root ได้ไม่ได้ เพราะ 2 Rules ขัดแย้งกัน

สำคัญ: นี่เป็น Contractual Limitation ไม่ใช่ Technical ใช้ CNAME ที่ Root ได้ แต่อาจเกิด Unexpected Errors เพราะฝ่าฝืน Contract ของพฤติกรรมที่คาดหวัง

ตัวอย่างจาก Cloudflare ปัญหากับ Microsoft Exchange Mail Servers หลังใช้ CNAME ที่ Root Domain:

Domains กำหนด Servers จัดการ Email ผ่าน MX Record ปัญหาคือ Exchange Servers … ดึง CNAME ที่ Root Record แล้วไม่ Respect CNAME ที่ MX Record ตั้งไว้ ไม่ว่า Exchange จะผิด พวกเขาทำงานภายใต้ Assumptions ของ DNS Specification

เห็น Downside ใน Server Softwares/Libraries หลายตัว เพราะ Standard ระบุ CNAME เป็น Only Record ที่ Node Records อื่นไม่ถูกมองหา ทั้งหมด Ignored เงียบๆ ไม่มี Warning/Error ถ้า MX Record ตั้งไว้รับ Email MX จะถูก Ignore ถ้ามี CNAME Evaluated First แม้มี A Record: CNAME Takes Precedence A Record ไม่ถูกอ่าน

The Modern Internet (อินเทอร์เน็ตสมัยใหม่)

ทำไมเป็นปัญหา? ทำไมอยาก用 CNAME สำหรับ Root Domain? นั่นคือ End of Path ตอนหา IP Web Server Host Content?

ใน Internet สมัยใหม่ ไม่ใช่แล้ว โลกต่างจากตอนเขียน DNS Standards

อาจใช้ PaaS Provider เช่น Heroku เก็บ Content บน Web Servers ของพวกเขา คุณควบคุม Content แต่อย่าง Infrastructure PaaS ทำ Heavy Lifting Network Maintenance พวกเขาให้ URL (my-app.herokuapp.com) เป็น Subdomain ของ Root Domain พวกเขา ดู IP Web Servers ได้ แต่อยู่ภายใต้ Control ของ PaaS เปลี่ยนได้โดยไม่แจ้งเตือน

Scale และ Frequency ของ Backend Changes โดย PaaS ทำให้ยาก Maintain Root Domain A Record Point Single 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 (หรือ Host Provider) Manage Update A Record ที่ CNAME Point โดยไม่ต้องเปลี่ยนอะไรฝั่งคุณ แต่เรารู้แล้วว่านี้ Break DNS Spec ดังนั้น Bad Idea

ทำ 301/302 Redirect จาก example.com ไป www.example.com ได้ แต่ Instruction เกิดบน Web Server (ยังมีปัญหา A Record Fixed ใน DNS Point ไป Web Server) หรือ Custom DNS Provider Redirect (Complications กับ HTTPS)

Side Effect: เปลี่ยน Domain ใน URL Bar ซึ่งอาจไม่อยาก นี่สำหรับ Website Moved Permanently หรือ Preserve SEO Rankings ไม่ใช่แก้ปัญหา Point ไป Complex Changing Backend แบบ Scalable

The Solution (วิธีแก้)

DNS Providers หลายแห่งพัฒนา Custom Solutions แก้ปัญหานี้ รวม:

  • ALIAS ที่ DNSimple
  • ANAME ที่ DNS Made Easy
  • ANAME ที่ easyDNS
  • CNAME (Virtual) ที่ CloudFlare

ทั้งหมดเป็น Virtual Record Types ให้ CNAME Like Behavior โดยไม่มี Downsides Implementation แตกต่างกันแต่ High Level: DNS Server เห็น Virtual Record Types นี้ Act as DNS Resolver Follow Chain ที่ Alias สร้าง จน Resolve ที่ A Record(s) คืน A Records ให้ DNS Server 'Flatten' CNAME Chain เป็น A Record(s) ที่คืน ไม่แตกต่างจาก Query ทั่วไป Query เห็นแค่ Pure A Record ไม่ Break DNS Spec ไม่มี Disadvantages ของ CNAME

Virtual Records นี้อยู่คู่ Records อื่นๆ ที่ Root ได้โดยไม่กลัว Unintended Behaviors ขึ้นอยู่กับ Provider's DNS Resolution Method Follow CNAME Chain อาจมี Performance Benefits จาก Caching Previous Lookups

DNSimple Setup จะเป็นแบบนี้ Solution นี้มี Advantages ของ Domain Name Aliasing ทั้งหมด ไม่มี Risks 用ที่ Root Level

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

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

ยินดีรับ Corrections และ Additional Points เสมอ

Resources (แหล่งข้อมูล)

  • What is a DNS Server
  • Set Up a DNS Name Server
  • DNSimple Support Pages และ ALIAS Blog
  • Cloudflare Support และ CNAME Blog
  • dig HowTo
  • Stack Overflow/StackExchange Posts หลายอันดี
  • Wikipedia Entries ที่เขียนดี
  • Netlify Blog 'To www or not www'