Nhận dạng cấp dưới
Các bản ghi NS cấp Apex được sử dụng bởi một máy chủ chính để xác định cấp dưới của nó. Khi dữ liệu trên một máy chủ tên có thẩm quyền thay đổi, nó sẽ quảng cáo thông DNS NOTIFYtin này qua tin nhắn ( RFC 1996 ) cho tất cả các đồng nghiệp của nó trong danh sách đó. Những máy chủ đó sẽ lần lượt gọi lại với một yêu cầu cho SOAbản ghi (chứa số sê-ri) và đưa ra quyết định về việc có nên kéo xuống một bản sao gần đây hơn của vùng đó hay không.
- Có thể gửi các tin nhắn này đến các máy chủ không được liệt kê trong
NSphần này, nhưng điều này đòi hỏi các chỉ thị cấu hình cụ thể của máy chủ (chẳng hạn như also-notifychỉ thị của ISC BIND ). Các bản ghi NS apex bao gồm danh sách các máy chủ cơ bản để thông báo theo cấu hình mặc định.
- Điều đáng chú ý là các máy chủ thứ cấp cũng sẽ gửi tin nhắn THÔNG BÁO cho nhau dựa trên những
NShồ sơ này , thường dẫn đến việc từ chối đăng nhập. Điều này có thể bị vô hiệu hóa bằng cách hướng dẫn các máy chủ chỉ gửi thông báo cho các vùng mà họ là chủ nhân cho (BIND notify master;:) hoặc bỏ qua NSthông báo dựa trên hoàn toàn có lợi cho thông báo được xác định rõ ràng trong cấu hình. (BIND notify explicit;:)
Định nghĩa có thẩm quyền
Câu hỏi trên có một sai lầm:
Chúng không được sử dụng bởi bộ đệm máy chủ DNS để xác định máy chủ có thẩm quyền cho tên miền. Điều này được xử lý bằng keo máy chủ tên, được xác định ở cấp đăng ký. Nhà đăng ký không bao giờ sử dụng thông tin này để tạo hồ sơ keo.
Đây là một kết luận dễ dàng để đi đến, nhưng không chính xác. Các NShồ sơ và dữ liệu hồ sơ keo (như được xác định trong tài khoản đăng ký của bạn) không có thẩm quyền. Lý do là họ không thể được coi là "có thẩm quyền" hơn dữ liệu cư trú trên các máy chủ mà cơ quan có thẩm quyền đang được ủy quyền. Điều này được nhấn mạnh bởi thực tế là các giới thiệu không có aacờ (Câu trả lời có thẩm quyền) được đặt.
Để minh họa:
$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8f::53
b.iana-servers.net. 172800 IN A 199.43.133.53
b.iana-servers.net. 172800 IN AAAA 2001:500:8d::53
Lưu ý thiếu aatrong các cờ cho câu trả lời ở trên. Bản thân người giới thiệu không có thẩm quyền. Mặt khác, dữ liệu trên máy chủ được đề cập là có thẩm quyền.
$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
Điều đó nói rằng, mối quan hệ này có thể trở nên rất khó hiểu vì không thể tìm hiểu về các phiên bản có thẩm quyền của các NShồ sơ này mà không có hồ sơ không có thẩm quyền NSđược xác định ở phía phụ huynh của giới thiệu. Điều gì xảy ra nếu họ không đồng ý?
- Câu trả lời ngắn gọn là "hành vi không nhất quán".
- Câu trả lời dài là máy chủ tên ban đầu sẽ còn sơ khai tất cả mọi thứ ra khỏi giới thiệu (và keo) trên một bộ nhớ cache trống rỗng, nhưng những người
NS, Avà AAAAhồ sơ có thể cuối cùng sẽ được thay thế khi họ được làm mới. Việc làm mới xảy ra khi các TTL trên các hồ sơ tạm thời đó hết hạn hoặc khi ai đó yêu cầu rõ ràng câu trả lời cho các hồ sơ đó.
Avà AAAAcác bản ghi cho dữ liệu ngoài vùng (tức là commáy chủ tên xác định keo cho dữ liệu ngoài comvùng, như thế example.net) chắc chắn sẽ được làm mới, vì đó là một khái niệm dễ hiểu rằng máy chủ tên không nên được coi là nguồn có thẩm quyền của thông tin đó . (RFC 2181)- Khi các giá trị của các
NSbản ghi khác nhau giữa các phụ huynh và con của giới thiệu (chẳng hạn như các máy chủ tên được nhập vào bảng điều khiển đăng ký khác với các NSbản ghi sống trên cùng các máy chủ đó), các hành vi có kinh nghiệm sẽ không nhất quán, bao gồm và bao gồm cả trẻ em NShồ sơ bị bỏ qua hoàn toàn. Điều này là do hành vi không được xác định rõ bởi các tiêu chuẩn và việc triển khai khác nhau giữa các lần triển khai máy chủ đệ quy khác nhau. Nói cách khác, hành vi nhất quán trên internet chỉ có thể được dự kiến nếu các định nghĩa máy chủ tên miền cho một miền nhất quán giữa phía cha và con của một giới thiệu .
Điểm dài và ngắn của nó là các máy chủ DNS đệ quy trên internet sẽ bị trả lại giữa các điểm đến nếu các bản ghi được xác định ở phía phụ huynh của giới thiệu không đồng ý với các phiên bản có thẩm quyền của các bản ghi đó. Ban đầu, dữ liệu có trong thư giới thiệu sẽ được ưu tiên, chỉ được thay thế bằng các định nghĩa có thẩm quyền. Vì bộ nhớ cache liên tục được xây dựng lại từ đầu trên internet, nên internet không thể giải quyết trên một phiên bản thực tế duy nhất với cấu hình này. Nếu các bản ghi có thẩm quyền đang làm điều gì đó bất hợp pháp theo các tiêu chuẩn, chẳng hạn như NScác bản ghi trỏ vào các bí danh được xác định bởi mộtCNAME, điều này thậm chí còn khó khăn hơn để khắc phục sự cố; tên miền sẽ xen kẽ giữa làm việc và bị hỏng đối với phần mềm từ chối vi phạm. (tức là ISC BIND / được đặt tên)
RFC 2181 §5.4.1 cung cấp bảng xếp hạng về độ tin cậy của dữ liệu này và làm cho nó rõ ràng rằng dữ liệu bộ đệm được liên kết với các giới thiệu và keo dán có thể được trả về như một câu trả lời cho yêu cầu rõ ràng cho các bản ghi mà chúng tham chiếu.
5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
<snip>
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.