Giả sử máy chủ tên được cấu hình của bạn không có bất kỳ kết quả được lưu trong bộ nhớ cache nào, thì có bao nhiêu máy chủ tên phải truy vấn máy chủ tên của bạn để giải quyết maps.google.com? Bạn sẽ sử dụng lệnh nào để tìm tất cả các máy chủ tên này? Liệt kê một từ mỗi cấp độ và giải thích tại sao mức độ này là cần thiết.
Chà, hãy chọn cái này ra.
"Giả sử máy chủ tên được cấu hình của bạn không có bất kỳ kết quả được lưu trong bộ nhớ cache nào" - trước hết, nếu nó không có dữ liệu được lưu trong bộ nhớ cache, thì nó không thể giải quyết bất cứ điều gì. Để xử lý bộ đệm của bộ giải quyết, bạn cần có các bản ghi NS và địa chỉ (A, AAAA) cho vùng .(gốc AKA). Đó là các máy chủ tên gốc, được tìm thấy trong root-servers.net.khu vực. Không có gì kỳ diệu về khu vực đó hoặc các máy chủ DNS đó. Tuy nhiên, dữ liệu này thường được cung cấp "ngoài băng" cho trình phân giải DNS, chính xác để lấy bộ đệm của bộ phân giải. Máy chủ tên chỉ có thẩm quyền không cần dữ liệu này, nhưng giải quyết máy chủ tên thì có.
Ngoài ra, "giải quyết" để làm gì? Bất kỳ RRtype ở tên đó? Một ARR? Hay cái gì khác? Lớp nào ( CH/ Chaosnet, IN/ Internet, ...)? Quá trình chính xác sẽ khác nhau, nhưng ý tưởng chung vẫn giống nhau.
Nếu chúng ta có thể giả định rằng chúng ta biết cách tìm các máy chủ tên gốc nhưng không có gì hơn, và bằng cách "giải quyết", chúng ta có nghĩa là có được nội dung của bất kỳ IN ARR nào được liên kết với tên đó, nó sẽ thực tế hơn rất nhiều.
Để phân giải tên DNS, về cơ bản, bạn chia tên thành nhãn và sau đó thực hiện theo cách từ phải sang trái. Đừng quên .cuối cùng; bạn thực sự sẽ được giải quyết maps.google.com.chứ không phải maps.google.com. Điều đó khiến chúng tôi cần phải giải quyết (chúng tôi biết điều này, nhưng việc triển khai trình phân giải DNS có thể sẽ không):
.com.google.com.maps.google.com.
Bắt đầu với việc tìm ra nơi để yêu cầu nội dung .. Điều đó thật dễ dàng; chúng tôi đã có thông tin đó: tên máy chủ tên gốc và địa chỉ IP . Vì vậy, chúng tôi có một máy chủ tên gốc. Giả sử chúng tôi quyết định sử dụng 198.41.0.4 ( a.root-servers.net, cũng 2001: 503: ba3e :: 2: 30) để tiếp tục phân giải tên. Trong thực tế, một trong những điều đầu tiên được trình giải quyết thực hiện có thể là sử dụng dữ liệu máy chủ gốc được cung cấp để yêu cầu một trong các máy chủ vùng gốc cung cấp danh sách chính xác các máy chủ tên cho vùng gốc, do đó đảm bảo rằng nếu có bất kỳ Tên và địa chỉ IP là hợp lệ và có thể truy cập, nó sẽ có một bộ dữ liệu đầy đủ và đầy đủ cho vùng gốc khi bắt đầu phân giải.
Bắn ra một truy vấn DNS cho maps.google.com. IN A198.41.0.4. Nó sẽ cho bạn biết trong câu trả lời "không, sẽ không làm điều đó, nhưng đây là người có thể biết"; đó là một lời giới thiệu. Nó chứa NScác bản ghi cho vùng gần nhất mà máy chủ đang nghi vấn biết, cùng với bất kỳ bản ghi keo nào mà máy chủ tình cờ có sẵn. Nếu không có dữ liệu keo nào, trước tiên bạn phải giải quyết máy chủ có tên trong bản ghi NS bạn đã chọn, do đó, tạo ra một độ phân giải tên riêng để lấy địa chỉ IP; nếu dữ liệu keo có sẵn, bạn sẽ có địa chỉ IP của máy chủ tên ít nhất là "gần" hơn với câu trả lời. Trong trường hợp này, đó sẽ là tập hợp các máy chủ cho com.vùng và dữ liệu keo cũng được cung cấp.
Lặp lại quá trình, hỏi một trong những com.máy chủ tên cùng một câu hỏi. Họ cũng không biết, nhưng sẽ giới thiệu bạn đến các máy chủ tên có thẩm quyền của Google. Tại thời điểm này trong trường hợp chung, nó sẽ bị đánh hoặc bỏ lỡ liệu dữ liệu keo có được cung cấp hay không; chẳng có gì ngăn cản một comtên miền chỉ có máy chủ tên nl, ví dụ, trong trường hợp đó, dữ liệu keo không có khả năng có sẵn từ các máy chủ gTLD. Dữ liệu keo được cung cấp cũng có thể không đầy đủ hoặc nếu bạn thực sự không may mắn thì thậm chí có thể không chính xác! Bạn phải luôn sẵn sàng để sinh ra độ phân giải tên riêng mà tôi đã đề cập ở trên.
Về cơ bản, bạn tiếp tục đi cho đến khi bạn nhận được câu trả lời với bộ aacờ (câu trả lời có thẩm quyền). Câu trả lời đó sẽ cho bạn biết những gì bạn đang yêu cầu hoặc RR mà bạn yêu cầu không tồn tại (hoặc có NXDOMAINhoặc NOERRORkhông có bản ghi dữ liệu phản hồi). Tiếp tục tìm kiếm các câu trả lời như SERVFAIL(và lùi lại một bước và thử máy chủ khác nếu bạn nhận được; nếu tất cả các máy chủ được đặt tên quay lại SERVFAIL, không thực hiện quy trình giải quyết tên và SERVFAILtự trả lại cho khách hàng).
Cách khác để yêu cầu toàn bộ RRname từ mỗi máy chủ (mà có thể được coi là xấu thực hành) là sử dụng danh sách chia-up của nhãn mà chúng ta xác định trước đó, hãy hỏi các máy chủ tên được đưa ra bởi máy chủ hơn nữa về phía gốc cho IN NSvà IN A/ IN AAAARR cho nhãn đó và sử dụng các nhãn đó để tiếp tục quá trình phân giải tên. Điều đó chỉ khác một chút trong thực tế và quy trình tương tự vẫn được áp dụng.
Bạn có thể mô phỏng toàn bộ quá trình này bằng cách sử dụng +tracetùy chọn cho digtiện ích, là một phần của BIND hoặc set debugtrong nslookup.
Nó cũng đáng ghi nhớ rằng một số RRtypes (đáng chú ý NS, MXvà một vài người khác; cũng vậy, A6được khá tốt được sử dụng trong một thời gian nhưng đã bị phản đối) có thể và làm tài liệu tham khảo RR khác. Trong trường hợp đó, bạn có thể cần phải sinh ra một quy trình giải quyết tên khác để trả lời đầy đủ và hữu ích cho khách hàng của mình.
dig +trace, nhưng tôi không chắc ý nghĩa của các cấp là gì. Đây có thể là một câu hỏi cho Server Fault.