Tại sao bản ghi CNAME không thể được sử dụng ở đỉnh (còn gọi là root) của tên miền?

Đây là Câu hỏi Canonical về CNAME tại các điểm (hoặc gốc) của các khu vực

Đó là kiến ​​thức tương đối phổ biến rằng CNAMEcác bản ghi ở đỉnh của một tên miền là một thực tiễn cấm kỵ.

Thí dụ: example.com. IN CNAME ithurts.example.net.

Trong trường hợp tốt nhất, phần mềm máy chủ tên có thể từ chối tải cấu hình và trong trường hợp xấu nhất, phần mềm có thể chấp nhận cấu hình này và làm mất hiệu lực cấu hình cho example.com.

Gần đây tôi có một công ty lưu trữ web chuyển các hướng dẫn cho một đơn vị kinh doanh mà chúng tôi cần để CNAME đỉnh của tên miền của chúng tôi sang một bản ghi mới. Biết rằng đây sẽ là một cấu hình tự sát khi được cung cấp cho BIND, tôi đã khuyên họ rằng chúng tôi sẽ không thể tuân thủ và đây là lời khuyên chung chung. Công ty lưu trữ web đã đưa ra lập trường rằng nó không bị cấm hoàn toàn bởi các RFC xác định tiêu chuẩn và phần mềm của họ hỗ trợ nó. Nếu chúng tôi không thể CNAME apex, lời khuyên của họ là không có bản ghi apex nào cả và họ sẽ không cung cấp máy chủ web chuyển hướng. ...Gì?

Hầu hết chúng ta đều biết rằng RFC1912 khẳng định điều đó A CNAME record is not allowed to coexist with any other data., nhưng hãy trung thực với chính mình ở đây, RFC chỉ là Thông tin. Lần gần nhất tôi biết để thông báo cấm thực hành là từ RFC1034 :

Nếu một CNAME RR có mặt tại một nút, thì không có dữ liệu nào khác; điều này đảm bảo rằng dữ liệu cho một tên chính tắc và bí danh của nó không thể khác nhau.

Thật không may, tôi đã ở trong ngành đủ lâu để biết rằng "không nên" không giống như "không nên" và đó là sợi dây đủ để hầu hết các nhà thiết kế phần mềm tự gắn mình. Biết rằng bất cứ điều gì thiếu liên kết ngắn gọn với một cú đánh trượt sẽ làm lãng phí thời gian của tôi, cuối cùng tôi đã để công ty thoát khỏi lời trách mắng về việc khuyến nghị các cấu hình có thể phá vỡ phần mềm thường được sử dụng mà không tiết lộ chính xác.

Điều này đưa chúng ta đến hỏi đáp. Lần đầu tiên tôi muốn chúng tôi thực sự có được kỹ thuật về sự điên rồ của các CNAME đỉnh cao, và không khắc phục vấn đề như chúng tôi thường làm khi ai đó đăng bài về chủ đề này. RFC1912 không có giới hạn, như mọi RFC thông tin khác áp dụng ở đây mà tôi không nghĩ tới. Hãy tắt em bé này lại.

CNAMEcác bản ghi ban đầu được tạo để cho phép nhiều tên cung cấp cùng một tài nguyên được đặt bí danh cho một "tên chính tắc" duy nhất cho tài nguyên. Với sự ra đời của lưu trữ ảo dựa trên tên, thay vào đó, nó trở nên phổ biến để sử dụng chúng như một hình thức bí danh địa chỉ IP chung. Thật không may, hầu hết những người đến từ một nền tảng lưu trữ web mong đợi CNAMEcác bản ghi cho thấy sự tương đương trong DNS , điều này chưa bao giờ có ý định. Apex chứa các loại bản ghi rõ ràng không được sử dụng trong việc xác định tài nguyên máy chủ chính tắc ( NS, SOA), không thể được đặt bí danh mà không phá vỡ tiêu chuẩn ở mức cơ bản. (đặc biệt liên quan đến việc cắt giảm vùng )

Thật không may, tiêu chuẩn DNS ban đầu được viết trước khi các cơ quan quản lý tiêu chuẩn nhận ra rằng việc xác minh rõ ràng là cần thiết để xác định hành vi nhất quán ( RFC 2119 ). Cần phải tạo RFC 2181 để làm rõ một số trường hợp góc do từ ngữ mơ hồ, và thông báo cập nhật cho thấy rõ hơn rằng CNAME không thể sử dụng để đạt được răng cưa đỉnh mà không phá vỡ tiêu chuẩn.

6.1. Chính quyền khu vực

Các máy chủ có thẩm quyền cho một vùng được liệt kê trong các bản ghi NS cho nguồn gốc của vùng, cùng với bản ghi Bắt đầu của Cơ quan (SOA) là các bản ghi bắt buộc trong mỗi vùng. Một máy chủ như vậy có thẩm quyền cho tất cả các hồ sơ tài nguyên trong một khu vực không nằm trong khu vực khác. Các bản ghi NS chỉ ra việc cắt vùng là thuộc tính của vùng con được tạo, cũng như bất kỳ bản ghi nào khác về nguồn gốc của vùng con đó hoặc bất kỳ tên miền phụ nào của vùng đó. Máy chủ cho một khu vực không được trả về các câu trả lời có thẩm quyền cho các truy vấn liên quan đến tên trong khu vực khác, bao gồm NS và có lẽ A, các bản ghi tại khu vực bị cắt, trừ khi nó cũng là máy chủ cho khu vực khác.

Điều này thiết lập rằng SOAvà NShồ sơ là bắt buộc, nhưng nó không nói gì Ahoặc các loại khác xuất hiện ở đây. Có vẻ như không cần thiết khi tôi trích dẫn điều này sau đó, nhưng nó sẽ trở nên phù hợp hơn trong một thời điểm.

RFC 1034 có phần mơ hồ về các vấn đề có thể phát sinh khi CNAMEtồn tại bên cạnh các loại hồ sơ khác. RFC 2181 xóa bỏ sự mơ hồ và nêu rõ các loại bản ghi được phép tồn tại bên cạnh chúng:

10.1. Hồ sơ tài nguyên CNAME

Bản ghi DNS CNAME ("tên chính tắc") tồn tại để cung cấp tên chính tắc được liên kết với tên bí danh. Có thể chỉ có một tên hợp quy như vậy cho bất kỳ một bí danh nào. Tên đó thường phải là một tên tồn tại ở nơi khác trong DNS, mặc dù có một số ứng dụng hiếm cho các bí danh với tên chính tắc đi kèm không được xác định trong DNS. Tên bí danh (nhãn của bản ghi CNAME) có thể, nếu DNSSEC đang được sử dụng, có SIG, NXT và RR RR, nhưng có thể không có dữ liệu nào khác. Đó là, đối với bất kỳ nhãn nào trong DNS (bất kỳ tên miền nào), một trong những điều sau đây là đúng:

• tồn tại một bản ghi CNAME, tùy chọn kèm theo SIG, NXT và RR RR,
• tồn tại một hoặc nhiều bản ghi, không có bản ghi CNAME nào,
• Tên tồn tại, nhưng không có RR liên quan thuộc bất kỳ loại nào,
• cái tên hoàn toàn không tồn tại

"tên bí danh" trong ngữ cảnh này đề cập đến phía bên trái của CNAMEbản ghi. Danh sách gạch đầu dòng làm cho nó rõ ràng rõ ràng là một SOA, NSvà Ahồ sơ không thể được nhìn thấy tại một nút nơi một CNAMEcũng xuất hiện. Khi chúng ta kết hợp điều này với phần 6.1, không thể CNAMEtồn tại ở đỉnh vì nó sẽ phải sống cùng với các hồ sơ bắt buộc SOAvà NShồ sơ.

(Điều này dường như để thực hiện công việc, nhưng nếu ai đó có một con đường ngắn hơn để chứng minh xin vui lòng cung cấp cho nó một vết nứt.)

Cập nhật:

Dường như sự nhầm lẫn gần đây hơn đến từ quyết định gần đây của Cloudflare cho phép xác định một bản ghi CNAME bất hợp pháp ở đỉnh của các tên miền mà họ sẽ tổng hợp các bản ghi A. "Tuân thủ RFC" như được mô tả bởi bài viết được liên kết đề cập đến thực tế là các bản ghi được tổng hợp bởi Cloudflare sẽ chơi tốt với DNS. Điều này không thay đổi thực tế rằng đó là một hành vi hoàn toàn tùy chỉnh.

Theo tôi đây là một sự bất đồng đối với cộng đồng DNS lớn hơn: thực tế nó không phải là bản ghi CNAME và nó khiến mọi người hiểu lầm rằng phần mềm khác bị thiếu vì không cho phép. (như câu hỏi của tôi chứng minh)

Internet Systems Consortium gần đây đã đăng một bài viết trên CNAME ở đỉnh của một khu vực , tại sao hạn chế này tồn tại và một số lựa chọn thay thế. Điều này không có khả năng thay đổi bất cứ lúc nào sớm, thật đáng buồn:

Chúng tôi không thể thay đổi cách sử dụng bản ghi CNAME đặc biệt mà không thay đổi tất cả các triển khai máy chủ DNS trên thế giới cùng một lúc. Điều này là do ý nghĩa và giải thích của nó đã được xác định nghiêm ngặt trong giao thức DNS; tất cả các cài đặt máy khách và máy chủ DNS hiện tại tuân thủ thông số kỹ thuật này. Cố gắng 'thư giãn' cách CNAME được sử dụng trong các máy chủ có thẩm quyền mà không thay đổi đồng thời tất cả các trình phân giải DNS hiện đang hoạt động sẽ khiến phân giải tên bị phá vỡ (và các dịch vụ web và email trở nên không có sẵn cho các tổ chức thực hiện các giải pháp máy chủ có thẩm quyền 'thư giãn'.

Nhưng có hy vọng:

Một giải pháp tiềm năng khác hiện đang được thảo luận sẽ thêm một loại bản ghi tài nguyên dns mới mà các trình duyệt sẽ tìm kiếm, có thể tồn tại ở đỉnh. Đây sẽ là tên máy chủ dành riêng cho ứng dụng cho các yêu cầu http (tương tự như cách MX hoạt động).

Ưu điểm: Điều này hoàn toàn phù hợp với thiết kế DNS.
Nhược điểm: Điều này chưa có sẵn và sẽ yêu cầu cập nhật ứng dụng trình duyệt.

Nếu bạn đang chuyển hướng toàn bộ khu vực, bạn nên sử dụng DNAME. Theo RFC 6672 ,

DNAME RR và CNAME RR [RFC1034] gây ra tra cứu (có khả năng) dữ liệu trả về tương ứng với một tên miền khác với tên miền được yêu cầu. Sự khác biệt giữa hai bản ghi tài nguyên là CNAME RR hướng việc tra cứu dữ liệu tại chủ sở hữu của nó sang một tên khác, trong khi đó, DNAME RR hướng tìm kiếm dữ liệu theo hậu duệ của tên chủ sở hữu của nó với các tên tương ứng dưới một nút (đơn) khác cái cây.

Ví dụ: hãy xem qua một khu vực (xem RFC 1034 [RFC1034], Mục 4.3.2, bước 3) cho tên miền "foo.example.com" và bản ghi tài nguyên DNAME được tìm thấy tại "example.com" cho biết rằng tất cả các truy vấn trong "example.com" được chuyển đến "example.net". Quá trình tra cứu sẽ trở lại bước 1 với tên truy vấn mới là "foo.example.net". Nếu tên truy vấn là "www.foo.example.com", tên truy vấn mới sẽ là "www.foo.example.net".