TL; DR: có các tên miền phụ trung gian cần tồn tại, ít nhất là khi được truy vấn, theo định nghĩa của DNS; họ có thể không tồn tại trong khu vực mặc dù.
Một sự nhầm lẫn có thể để loại bỏ đầu tiên; Định nghĩa "Không đầu cuối trống"
Bạn có thể nhầm lẫn hai điều, vì những câu trả lời khác dường như cũng phải làm. Cụ thể, điều gì xảy ra khi truy vấn tên so với cách bạn định cấu hình máy chủ tên và nội dung của vùng tệp.
DNS được phân cấp. Đối với bất kỳ nút lá nào tồn tại, tất cả các thành phần dẫn đến nó PHẢI tồn tại, theo nghĩa là nếu chúng được truy vấn, máy chủ tên có thẩm quyền có trách nhiệm sẽ trả lời chúng mà không gặp lỗi.
Như đã giải thích trong RFC 8020 (chỉ lặp lại quy tắc luôn luôn là quy tắc, nhưng chỉ một số nhà cung cấp DNS cần nhắc nhở), nếu có bất kỳ truy vấn nào, máy chủ tên có thẩm quyền trả lời NXDOMAIN (nghĩa là: bản ghi tài nguyên này không tồn tại), thì nó có nghĩa là bất kỳ nhãn "bên dưới" tài nguyên này cũng không tồn tại.
Trong ví dụ của bạn, nếu một truy vấn cho intermediate.example.comlợi nhuận NXDOMAIN, sau đó bất kỳ máy chủ tên đệ quy thích hợp sẽ ngay lập tức trả lời NXDOMAINcho leaf.intermediate.example.comvì kỷ lục này không thể tồn tại nếu tất cả các nhãn trong đó không tồn tại như hồ sơ.
Điều này đã được nêu trong quá khứ trong RFC 4592 về các ký tự đại diện (không liên quan ở đây):
Không gian tên miền là một cấu trúc cây. Các nút trong cây
sở hữu ít nhất một RRSet và / hoặc có con cháu sở hữu chung
ít nhất một RRSet. Một nút có thể tồn tại mà không có RRSets chỉ khi nó có
con cháu làm; nút này là một thiết bị đầu cuối trống.
Một nút không có con cháu là một nút lá. Các nút lá rỗng không tồn tại.
Một ví dụ thực tế với tên miền .US
Chúng ta hãy lấy một ví dụ hoạt động từ một TLD với rất nhiều nhãn trong lịch sử, đó là .US. Chọn bất kỳ ví dụ trực tuyến, hãy để chúng tôi sử dụng www.teh.k12.ca.us.
Tất nhiên nếu bạn truy vấn tên này, hoặc thậm chí teh.k12.ca.usbạn có thể lấy lại Ahồ sơ. Không có kết luận nào ở đây cho mục đích của chúng tôi (thậm chí còn có một CNAME ở giữa nó, nhưng chúng tôi không quan tâm đến điều đó):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
Hãy để chúng tôi truy vấn ngay bây giờ k12.ca.us(Tôi không truy vấn máy chủ tên có thẩm quyền của nó, nhưng thực tế điều đó không thay đổi kết quả):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
Chúng ta học được gì từ câu trả lời này?
Đầu tiên, đó là một thành công vì tình trạng là NOERROR. Nếu đó là bất cứ điều gì khác và cụ thể NXDOMAINsau đó teh.k12.ca.us, cũng không www.teh.k12.ca.usthể tồn tại.
Thứ hai, phần ANSWER trống. Không có Ahồ sơ cho k12.ca.us. Đây không phải là một lỗi, loại ( A) này không tồn tại cho bản ghi này, nhưng có thể các loại bản ghi khác tồn tại cho bản ghi này hoặc bản ghi này là một ENT, còn gọi là "Empty Non Terminal": nó trống, nhưng nó không phải là một chiếc lá, có những thứ "bên dưới" nó (xem định nghĩa trong RFC 7719 ), như chúng ta đã biết (nhưng thông thường độ phân giải là từ trên xuống, vì vậy chúng ta sẽ đạt được bước này trước khi đi xuống một cấp dưới và không phải ngược lại như chúng ta đang làm ở đây để trình diễn mục đích).
Đây là lý do tại sao trên thực tế, như một phím tắt, chúng tôi nói mã trạng thái là NODATA: đây không phải là mã trạng thái thực, nó chỉ có nghĩa là NOERROR+ phần ANSWER trống, có nghĩa là không có dữ liệu cho loại bản ghi cụ thể này nhưng có thể có cho người khác.
Bạn có thể lặp lại cùng một thử nghiệm cho cùng một kết quả nếu bạn truy vấn với nhãn "lên" tiếp theo, đó là tên ca.us.
Kết quả của truy vấn so với nội dung của vùng dữ liệu
Bây giờ từ đâu có thể nhầm lẫn? Tôi tin rằng nó có thể xuất phát từ một số ý tưởng sai lầm rằng bất kỳ dấu chấm nào trong tên DNS có nghĩa là có một phái đoàn. Điều này là sai. Nói cách khác, vùng dữ liệu của bạn example.comcó thể như thế và nó hoàn toàn hợp lệ và đang hoạt động:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
Với một tệp vùng như vậy, truy vấn máy chủ tên này, bạn sẽ nhận được chính xác hành vi được quan sát ở trên: một truy vấn intermediate.example.comsẽ trả về NOERRORvới một câu trả lời trống. Bạn không cần phải tạo nó cụ thể trong vùng tệp (nếu bạn không cần nó vì lý do khác), máy chủ tên có thẩm quyền sẽ đảm nhiệm việc tổng hợp các câu trả lời "trung gian", bởi vì nó thấy nó cần thiết bị đầu cuối trống này (và bất kỳ những cái khác "ở giữa" nếu có các nhãn khác) vì nó nhìn thấy tên lá leaf.intermediate.example.com.
Lưu ý rằng đây là trường hợp phổ biến trên thực tế ở một số khu vực, nhưng bạn có thể không thấy nó vì nó nhắm mục tiêu nhiều hồ sơ "cơ sở hạ tầng" mà mọi người không tiếp xúc với:
- trong các khu vực đảo ngược như
in-addr.arphoặc ip6.arpa, và cụ thể là khu vực cuối cùng. Bạn sẽ có các bản ghi như thế 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.và rõ ràng không có một phái đoàn nào ở mỗi dấu chấm, cũng không có các bản ghi tài nguyên được đính kèm tại mỗi nhãn
- trong
SRVcác bản ghi, như _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., một tên miền có thể có nhiều _proto._tcp.example.comvà _proto._udp.example.com SRVcác bản ghi vì theo thiết kế, chúng phải có dạng này, nhưng đồng thời _tcp.example.comvà _udp.example.comsẽ vẫn là các phần không trống vì không bao giờ được sử dụng làm bản ghi
- trong thực tế, bạn có nhiều trường hợp xây dựng tên cụ thể khác dựa trên "nhãn gạch dưới" cho các giao thức khác nhau như DKIM. DKIM bắt buộc bạn phải có các bản ghi DNS như thế
whatever._domainkey.example.com, nhưng rõ ràng _domainkey.example.combản thân nó sẽ không bao giờ được sử dụng, vì vậy nó sẽ vẫn là một thiết bị đầu cuối trống. Điều này giống với TLSAcác bản ghi trong Dane (ví dụ _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==:) hoặc URIbản ghi (ví dụ _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public":)
Hành vi máy chủ tên và tạo trả lời trung gian
Tại sao máy chủ tên tự động tổng hợp các câu trả lời trung gian như vậy? Thuật toán phân giải lõi cho DNS, như chi tiết trong RFC 1034, phần 4.3.2 là lý do cho điều đó, chúng ta hãy lấy nó và tóm tắt trong trường hợp của chúng tôi khi truy vấn máy chủ tên có thẩm quyền ở trên cho tên intermediate.example.comnày (đây là QNAMEgiao thức bên dưới):
- Tìm kiếm các khu vực có sẵn cho khu vực là tổ tiên gần nhất với QNAME. Nếu một khu vực như vậy được tìm thấy, đi đến bước 3, nếu không thì bước 4.
Máy chủ tên tìm thấy khu vực example.comlà tổ tiên gần nhất của QNAME, vì vậy chúng tôi có thể chuyển sang bước 3.
Bây giờ chúng ta có cái này:
- Bắt đầu đối sánh xuống, nhãn theo nhãn, trong khu vực. [..]
a. Nếu toàn bộ QNAME được khớp, chúng tôi đã tìm thấy nút. [..]
b. Nếu một trận đấu sẽ đưa chúng tôi ra khỏi dữ liệu có thẩm quyền, chúng tôi có một giới thiệu. Điều này xảy ra khi chúng ta gặp một nút có NS RRs đánh dấu các vết cắt dọc theo đáy của một khu vực. [..]
c. Nếu tại một nhãn nào đó, một kết quả trùng khớp là không thể (nghĩa là nhãn tương ứng không tồn tại), hãy xem liệu nhãn "*" có tồn tại không. [..]
Chúng tôi có thể loại bỏ các trường hợp b và c, vì vùng dữ liệu của chúng tôi không có ủy quyền (do đó sẽ không bao giờ có sự giới thiệu cho các máy chủ tên khác, không có trường hợp b), cũng không có ký tự đại diện (vì vậy không có trường hợp c).
Chúng ta chỉ phải giải quyết ở đây với trường hợp a.
Chúng tôi bắt đầu khớp xuống, nhãn theo nhãn, trong khu vực. Vì vậy, ngay cả khi chúng tôi có một sub.sub.sub.sub.sub.sub.sub.sub.example.comcái tên dài , đến một lúc nào đó, chúng tôi đến trường hợp a: chúng tôi không tìm thấy một lời giới thiệu, cũng không phải một ký tự đại diện, nhưng chúng tôi đã kết thúc ở tên cuối cùng mà chúng tôi muốn có kết quả.
Sau đó, chúng tôi áp dụng phần còn lại của nội dung của trường hợp a:
Nếu dữ liệu tại nút là một CNAME
Không phải trường hợp của chúng tôi, chúng tôi bỏ qua điều đó.
Mặt khác, sao chép tất cả các RR khớp với QTYPE vào phần câu trả lời và chuyển sang bước 6.
Dù QTYPE chúng ta chọn ( A, AAAA, NS, vv) chúng tôi không có RR cho intermediate.example.comlà nó không xuất hiện trong zonefile. Vì vậy, bản sao ở đây là trống rỗng. Bây giờ chúng ta kết thúc ở bước 6:
Chỉ sử dụng dữ liệu cục bộ, cố gắng thêm các RR khác có thể hữu ích cho phần bổ sung của truy vấn. Lối thoát hiểm.
Không liên quan đến chúng tôi ở đây, do đó chúng tôi kết thúc với thành công.
Điều này giải thích chính xác hành vi được quan sát: các truy vấn như vậy sẽ trả về NOERRORnhưng cũng không có dữ liệu.
Bây giờ, bạn có thể tự hỏi: "nhưng sau đó nếu tôi sử dụng bất kỳ tên nào, như another.example.comsau đó bằng thuật toán trên, tôi sẽ nhận được cùng một câu trả lời (không có lỗi)", nhưng thay vào đó, các quan sát sẽ báo cáo NXDOMAINtrong trường hợp đó.
Tại sao?
Bởi vì toàn bộ thuật toán như đã giải thích, bắt đầu với điều này:
Thuật toán sau đây giả định rằng RR được tổ chức theo một số cấu trúc cây, một cho mỗi vùng và một cho bộ đệm
Điều này có nghĩa là vùng dữ liệu trên được chuyển thành cây này:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
Vì vậy, khi theo thuật toán, từ đầu, bạn thực sự có thể tìm thấy một đường dẫn: com > example > intermediate(vì đường dẫn com > example > intermediate > leaftồn tại) Nhưng vì another.example.com, sau khi com > examplebạn không tìm thấy anothernhãn trong cây, như là nút con của example. Do đó, chúng tôi rơi vào một phần của sự lựa chọn c từ phía trên:
Nếu nhãn "*" không tồn tại, hãy kiểm tra xem tên chúng tôi đang tìm có phải là QNAME ban đầu trong truy vấn hoặc tên mà chúng tôi đã theo dõi do CNAME không. Nếu tên là bản gốc, đặt lỗi tên có thẩm quyền trong phản hồi và thoát. Nếu không thì chỉ cần thoát.
Nhãn *không tồn tại và chúng tôi đã không tuân theo a CNAME, do đó chúng tôi đang trong trường hợp : set an authoritative name error in the response and exit, aka NXDOMAIN.
Lưu ý rằng tất cả những điều trên đã tạo ra sự nhầm lẫn trong quá khứ. Điều này được thu thập trong một số RFC. Ví dụ, hãy xem địa điểm bất ngờ này (niềm vui của thông số kỹ thuật DNS là không thể xuyên thủng) xác định các ký tự đại diện: RFC 4592 "Vai trò của ký tự đại diện trong hệ thống tên miền" và đáng chú ý là phần 2.2 "Quy tắc tồn tại", cũng được trích dẫn một phần vào đầu Câu trả lời của tôi nhưng ở đây nó đầy đủ hơn:
Các thiết bị đầu cuối trống [RFC2136, phần 7.16] là các tên miền không có bản ghi tài nguyên nhưng có các tên miền phụ. Trong phần 2.2.1,
"_tcp.host1.example." là một ví dụ về một tên không đầu cuối trống.
Văn bản không đầu cuối trống được giới thiệu bởi văn bản này trong phần 3.1 của RFC 1034:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
Dấu ngoặc đơn "có thể trống" chỉ định rằng các
thiết bị đầu cuối trống được công nhận rõ ràng và không
tồn tại " thiết bị đầu cuối trống ".
Việc đọc đoạn văn trên có thể dẫn đến một
giải thích rằng tất cả các miền có thể tồn tại - lên đến
giới hạn đề xuất là 255 octet cho một tên miền [RFC1035]. Ví dụ:
www.example. có thể có A RR, và theo như thực tế
có liên quan, là một lá của cây miền. Nhưng định nghĩa có thể được
hiểu là sub.www.example. cũng tồn tại, mặc dù không có dữ liệu. Bằng cách mở rộng, tất cả các tên miền có thể tồn tại, từ gốc trở xuống.
Vì RFC 1034 cũng định nghĩa "lỗi tên có thẩm quyền chỉ ra rằng tên đó không tồn tại" trong phần 4.3.1, do đó, đây rõ ràng không phải là mục đích của định nghĩa ban đầu, chứng minh sự cần thiết của một định nghĩa cập nhật trong phần tiếp theo.
Và sau đó định nghĩa trong phần tiếp theo là đoạn tôi đã trích dẫn ở đầu.
Lưu ý rằng RFC 8020 (trên NXDOMAINthực sự có nghĩa là NXDOMAIN, có nghĩa là nếu bạn trả lời NXDOMAINcho intermediate.example.com, sau đó leaf.intermediate.example.comkhông thể tồn tại) được giao nhiệm vụ một phần là do các nhà cung cấp DNS khác nhau đã không làm theo cách giải thích này và tàn phá tạo ra, hoặc họ chỉ là lỗi, xem ví dụ này đã sửa lỗi vào năm 2013 trong một mã máy chủ tên có thẩm quyền mã nguồn mở: https://github.com/PowerDNS/pdns/issues/127
Mọi người cần thiết sau đó để đưa ra các biện pháp truy cập cụ thể chỉ dành cho họ: đó không phải là bộ nhớ đệm tích cực NXDOMAINbởi vì đối với những nhà cung cấp đó nếu bạn nhận được NXDOMAINtại một nút nào đó, điều đó vẫn có thể có nghĩa là bạn nhận được một cái gì đó khác ngoài NXDOMAINnút khác bên dưới nó.
Và điều này đã khiến cho việc thu nhỏ QNAME (RFC 7816) không thể có được (xem https://indico.dns-oarc.net/event/21/contribution/298/attachments/267/487/qname-min.pdf để biết thêm chi tiết) , trong khi nó đã muốn tăng sự riêng tư. Sự tồn tại của các thiết bị đầu cuối trống trong trường hợp DNSSEC cũng tạo ra các vấn đề trong quá khứ, xung quanh việc xử lý sự không tồn tại (xem https://indico.dns-oarc.net/event/25/contribution/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf nếu quan tâm, nhưng bạn thực sự cần hiểu rõ về DNSSEC trước đó).
Hai thông báo sau đây đưa ra một ví dụ về các vấn đề mà một nhà cung cấp phải có thể thực thi đúng quy tắc này đối với các thiết bị không đầu cuối trống, nó đưa ra một số quan điểm về các vấn đề và tại sao chúng ta lại ở đó: