Trên thực tế, nó phức tạp hơn thế - thay vì một "sổ đăng ký trung tâm (đó) giữ một bảng ánh xạ các miền (www.mysite.com) tới các máy chủ DNS", có một số lớp phân cấp
Có một trung tâm đăng ký (Root Servers) chỉ chứa một nhóm nhỏ các mục: các (tên máy chủ) ghi NS cho tất cả các tên miền cấp cao - .com, .net, .org, .uk, .us, .au, và vân vân.
Những máy chủ đó chỉ chứa các bản ghi NS cho cấp độ tiếp theo. Để chọn một ví dụ, các máy chủ tên cho .ukmiền chỉ có mục cho .co.uk, .ac.ukvà các khu vực thứ hai cấp khác được sử dụng ở Anh.
Những máy chủ đó chỉ chứa các bản ghi NS cho cấp độ tiếp theo - để tiếp tục ví dụ, chúng cho bạn biết nơi tìm bản ghi NS cho google.co.uk. Trên các máy chủ đó cuối cùng bạn sẽ tìm thấy ánh xạ giữa tên máy chủ www.google.co.ukvà địa chỉ IP.
Như một nếp nhăn thêm, mỗi lớp cũng sẽ phục vụ các bản ghi 'keo'. Mỗi bản ghi NS ánh xạ một tên miền sang tên máy chủ - ví dụ: bản ghi NS cho .ukdanh sách nsa.nic.uklà một trong các máy chủ. Để đạt đến cấp độ tiếp theo, chúng ta cần tìm hiểu các bản ghi NS nic.uk, và chúng cũng bao gồm nsa.nic.ukcả. Vì vậy, bây giờ chúng ta cần biết IP của nsa.nic.uk, nhưng để tìm ra rằng chúng ta cần tạo một truy vấn nsa.nic.uk, nhưng chúng ta không thể thực hiện truy vấn đó cho đến khi chúng ta biết IP cho nsa.nic.uk...
Để giải quyết tình trạng khó khăn này, các máy chủ để .ukthêm bản ghi A nsa.nic.ukvào ADDITIONAL SECTIONphản hồi (phản hồi bên dưới được cắt bớt cho ngắn gọn):
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
Nếu không có các bản ghi keo bổ sung này, chúng tôi sẽ không bao giờ có thể tìm thấy máy chủ tên nic.uk.và vì vậy chúng tôi sẽ không bao giờ có thể tìm kiếm bất kỳ tên miền nào được lưu trữ ở đó.
Để lấy lại câu hỏi của bạn ...
a) Ưu điểm là gì? Tại sao không ánh xạ trực tiếp đến một địa chỉ IP?
Đối với một điều, nó cho phép chỉnh sửa cho từng khu vực riêng lẻ được phân phối. Nếu bạn muốn cập nhật mục nhập www.mydomain.co.uk, bạn chỉ cần chỉnh sửa thông tin trên mydomain.co.ukmáy chủ tên của bạn . Không cần thông báo cho các .co.ukmáy chủ trung tâm , hoặc các .ukmáy chủ hoặc máy chủ tên gốc. Nếu chỉ có một sổ đăng ký trung tâm duy nhất ánh xạ tất cả các cấp theo cách phân cấp phải được thông báo về mỗi thay đổi của một mục nhập DNS trong suốt chuỗi, thì nó sẽ bị ngập hoàn toàn với lưu lượng.
Trước năm 1982, đây thực sự là cách giải quyết tên đã xảy ra. Một đăng ký trung tâm đã được thông báo về tất cả các bản cập nhật và họ đã phân phối một tệp hosts.txtcó tên tên máy chủ và địa chỉ IP của mọi máy trên internet. Một phiên bản mới của tệp này đã được xuất bản vài tuần một lần và mọi máy trên internet sẽ phải tải xuống một bản sao mới. Ngay trước năm 1982, điều này đã bắt đầu trở nên có vấn đề và do đó DNS đã được phát minh để cung cấp một hệ thống phân tán hơn.
Đối với một điều khác, đây sẽ là một điểm thất bại duy nhất - nếu đăng ký trung tâm duy nhất bị hỏng, toàn bộ internet sẽ ngoại tuyến. Có một hệ thống phân tán có nghĩa là các lỗi chỉ ảnh hưởng đến các phần nhỏ của internet, chứ không phải toàn bộ.
(Để cung cấp thêm dự phòng, thực tế có 13 cụm máy chủ riêng biệt phục vụ vùng gốc. Mọi thay đổi đối với bản ghi tên miền cấp cao nhất phải được đẩy lên tất cả 13; hãy tưởng tượng phải phối hợp cập nhật tất cả 13 máy chủ cho mỗi thay đổi đến bất kỳ tên máy chủ nào ở bất cứ đâu trên thế giới ...)
b) Nếu bản ghi duy nhất cần thay đổi khi tôi định cấu hình máy chủ DNS để trỏ đến một địa chỉ IP khác được đặt tại máy chủ DNS, tại sao quy trình không phải là ngay lập tức?
Bởi vì DNS sử dụng rất nhiều bộ nhớ đệm để tăng tốc độ và giảm tải cho NS. Nếu không có bộ nhớ đệm, mỗi lần bạn truy cập google.co.ukmáy tính của bạn sẽ phải ra mạng để tìm kiếm các máy chủ .uk, sau đó .co.uk, sau đó .google.co.uk, sau đó www.google.co.uk. Những câu trả lời đó thực sự không thay đổi nhiều, vì vậy việc tìm kiếm chúng mỗi lần là một sự lãng phí thời gian và lưu lượng truy cập mạng. Thay vào đó, khi NS trả lại các bản ghi cho máy tính của bạn, nó sẽ bao gồm một giá trị TTL, thông báo cho máy tính của bạn để lưu kết quả trong một vài giây.
Ví dụ: các bản ghi NS .ukcó chỉ số TTL là 172800 giây - 2 ngày. Google thậm chí còn bảo thủ hơn - các bản ghi NS google.co.ukcó thời gian hoạt động là 4 ngày. Các dịch vụ dựa trên khả năng cập nhật nhanh chóng có thể chọn mức độ thấp hơn nhiều - ví dụ: telegraph.co.ukcó chỉ số TTL chỉ 600 giây trong hồ sơ NS của họ.
Nếu bạn muốn các bản cập nhật cho khu vực của bạn gần như ngay lập tức, bạn có thể chọn hạ thấp TTL của mình xuống bao nhiêu tùy thích. Cài đặt của bạn càng thấp, lưu lượng truy cập máy chủ của bạn sẽ càng tăng, vì khách hàng làm mới hồ sơ của họ thường xuyên hơn. Mỗi khi khách hàng phải liên hệ với máy chủ của bạn để thực hiện truy vấn, điều này sẽ gây ra một số độ trễ vì nó chậm hơn so với tìm kiếm câu trả lời trên bộ đệm cục bộ của họ, vì vậy bạn cũng muốn xem xét sự đánh đổi giữa các bản cập nhật nhanh và dịch vụ nhanh.
c) Nếu lý do duy nhất cho sự chậm trễ là bộ đệm DNS, có thể bỏ qua chúng, vì vậy tôi có thể thấy những gì đang xảy ra trong thời gian thực?
Có, điều này thật dễ dàng nếu bạn đang kiểm tra thủ công bằng dighoặc các công cụ tương tự - chỉ cần cho nó biết máy chủ nào cần liên hệ.
Đây là một ví dụ về phản hồi được lưu trữ:
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
Phần cờ ở đây không chứa aacờ, vì vậy chúng ta có thể thấy rằng kết quả này đến từ bộ đệm thay vì trực tiếp từ một nguồn có thẩm quyền. Trên thực tế, chúng ta có thể thấy rằng nó đến từ 97.107.133.4, một trong những trình phân giải DNS cục bộ của Linode. Thực tế là câu trả lời đã được đưa ra khỏi bộ đệm rất gần với tôi có nghĩa là tôi phải mất 0msec để nhận được câu trả lời; nhưng như chúng ta sẽ thấy trong giây lát, cái giá tôi phải trả cho tốc độ đó là câu trả lời đã gần 5 phút.
Để vượt qua trình phân giải của Linode và đi thẳng vào nguồn, chỉ cần chọn một trong số các NS đó và yêu cầu đào liên hệ trực tiếp với nó:
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
Bạn có thể thấy rằng lần này, các kết quả được cung cấp trực tiếp từ nguồn - lưu ý aacờ, cho biết kết quả đến từ một nguồn có thẩm quyền. Trong ví dụ trước của tôi, kết quả đến từ bộ đệm cục bộ của tôi, vì vậy chúng thiếu aacờ. Tôi có thể thấy rằng nguồn có thẩm quyền cho miền này đặt TTL là 600 giây. Các kết quả tôi nhận được trước đó từ bộ đệm cục bộ có chỉ số TTL chỉ là 319 giây, cho tôi biết rằng họ đã ngồi trong bộ đệm trong (600-319) giây - gần 5 phút - trước khi tôi nhìn thấy chúng.
Mặc dù TTL ở đây chỉ là 600 giây, một số ISP sẽ cố gắng giảm lưu lượng truy cập của họ hơn nữa bằng cách buộc các trình phân giải DNS của họ lưu trữ kết quả lâu hơn - trong một số trường hợp, trong 24 giờ trở lên. Đó là cách truyền thống (theo cách chúng ta không biết nếu điều này thực sự cần thiết nhưng phải an toàn) để cho rằng mọi thay đổi DNS bạn thực hiện sẽ không hiển thị ở mọi nơi trên Internet trong 24-48 giờ.