Các hồ sơ SRV được công bố chỉ ra bí danh CNAME vi phạm RFC 2782?

Trong quá trình thực hiện một số trách nhiệm công việc, tôi cần củng cố các bản ghi SRV và tôi đang cố gắng điều chỉnh một tuyên bố Wikipedia với những gì tôi thấy trong các bản khai DNS.

Theo mục nhập hồ sơ SRV của Wikipedia ,

mục tiêu trong các bản ghi SRV phải trỏ đến tên máy chủ lưu với bản ghi địa chỉ (bản ghi A hoặc AAAA). Chỉ tới tên máy chủ có bản ghi CNAME không phải là cấu hình hợp lệ.

nhưng tôi thấy các bản ghi trong đó digtrả về một bản ghi SRV trỏ đến một tên là bí danh trong bản ghi CNAME.

Đó là, một cái gì đó như thế này:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

Có vẻ như bản ghi SRV được cấu hình chính xác theo cách mà mục nhập Wikipedia nói không được phép. Tôi đang hiểu lầm điều gì? Không phải nó cho thấy rằng bản ghi SRV chỉ ra tại alias.domain.com, nơi có bản ghi CNAME chứ không phải bản ghi địa chỉ?

domain-name-system cname-record srv-record

— Scott
nguồn

trong công ty của tôi, chúng tôi sử dụng các bản ghi SRV rất nhiều và hầu hết trong số họ đang sử dụng CNAME và nó hoạt động tốt, vì vậy, trái với quy tắc hay không, nó hoạt động tốt :)

— olivierg

Câu trả lời:

Bài viết Wikipedia bạn đang trích dẫn báo cáo những gì RFC 2782 có liên quan cho các bản ghi SRV nêu:

Mục tiêu

Tên miền của máy chủ đích. PHẢI có một hoặc nhiều bản ghi địa chỉ cho tên này, tên KHÔNG PHẢI là bí danh (theo nghĩa của RFC 1034 hoặc RFC 2181).

Những gì bạn đang thấy là một sự vi phạm rõ ràng các quy tắc; tuy nhiên, nó có thể hoạt động (và nó thường như vậy), nếu bất kỳ ứng dụng khách nào đang tìm kiếm bản ghi SRV đó đủ thông minh để xử lý đúng bản ghi CNAME, ngay cả khi chỉ nên mong đợi bản ghi A trong phản hồi.

Nhưng nó cũng có thể không hoạt động: nó không được hỗ trợ và hoàn toàn phụ thuộc vào ứng dụng khách; do đó, nên tránh, vì nó không tuân theo các quy tắc phù hợp và có thể dẫn đến kết quả sai lầm và / hoặc không thể đoán trước.

Điều này tương tự với việc trỏ một bản ghi MX vào CNAME, được định nghĩa là chỉ sai ở không chỉ một , mà cả hai RFC, và nó cũng khá phổ biến (và dường như không có máy chủ thư nào có vấn đề với nó).

— Massimo
nguồn

Hãy nhớ rằng "đủ thông minh" là tương đối. Một số nhà thiết kế phần mềm luôn quan tâm rằng việc đưa ra các triển khai braindead chỉ khuyến khích nhiều triển khai tương tự. RFC 2781 chỉ được cập nhật bởi một RFC duy nhất và ngôn ngữ về những gì mong đợi là rất chắc chắn, vì vậy tôi sẽ không mong đợi nhiều sự thương xót ở đây.

— Andrew B

Hầu hết các ứng dụng khách chỉ dựa vào thư viện hệ thống để thực hiện các truy vấn DNS và hầu hết các thư viện (đặc biệt là các ngôn ngữ cấp cao hơn) sẽ cố gắng hết sức để giải quyết mọi truy vấn bạn ném vào chúng, và sẽ vui vẻ và âm thầm theo dõi CNAME đến bản ghi đích của nó và Địa chỉ IP.

— Massimo

Ứng dụng không cần nhiều sự thông minh, đơn giản là nó sẽ yêu cầu HĐH kết nối với "alias.domain.com" trên cổng 4443 và để lại tất cả các chi tiết cho nó.

— Massimo

Ứng dụng khách và thư viện hệ thống sẽ không có cơ hội theo bí danh nếu người truy cập ngược dòng từ chối dữ liệu có thẩm quyền và từ chối tiếp tục. (đó là sự thông minh tương đối mà tôi đã đề cập) Xử lý NShồ sơ và cấm răng cưa của BIND là ví dụ kinh điển về điều này. Bất kể, chúng tôi đồng ý rằng đó là trò chơi của bất kỳ ai với kết quả không thể đoán trước.

— Andrew B

Một số máy chủ thư bắt đầu chủ động bỏ qua MX đến CNAME, ví dụ: GMX medienconsulting.at/ Khăn

— Marcel Waldvogel

Đó là một ví dụ về hành vi bị hạn chế, vâng. Bản thân hạn chế xuất phát từ RFC 2781 trong định nghĩa của "mục tiêu":

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

Thật không may, phần mềm máy chủ DNS cho phép cấu hình bị cấm là không có gì mới, thật không may. Nó có thể và có thể xảy ra, giống như với các loại bản ghi khác nơi các mục tiêu bí danh bị cấm như NSvà MX. (đã đề cập ở trên)

Chỉ vì nó có thể được tìm thấy trong tự nhiên không có nghĩa là nó "ổn" và điều gì xảy ra khi một tiêu chuẩn bị bỏ qua thay đổi tùy theo từng sản phẩm. Tôi chưa thử nghiệm tương tác với SRVcác bản ghi, nhưng một quyết định thiết kế rất nổi tiếng của ISC BIND liên quan đến NScác bản ghi chỉ vào bí danh là bỏ hoàn toàn bản ghi nếu được tìm thấy trong quá trình đệ quy. Nếu tất cả các NSbản ghi bị loại bỏ theo cách này, kết quả của tất cả các truy vấn sẽ SERVFAILdành cho tên miền phụ được đề cập.

Tóm lại, bám sát tiêu chuẩn. Đó là điều an toàn duy nhất để làm.

— Andrew B
nguồn