Bao nhiêu phần trăm máy chủ tên tôn vinh TTL những ngày này?

Vài năm trước tôi đã phải thực hiện một số thay đổi DNS trong vài tuần khi tôi chuyển các thiết bị từ trung tâm dữ liệu này sang trung tâm dữ liệu khác. Vào thời điểm tôi làm điều này, khoảng 95% máy chủ tên trên thế giới dường như tôn trọng giá trị TTL, và khoảng 5% bỏ qua chúng tôi và tạo nên cái riêng của họ. Nói cách khác, 95% lưu lượng truy cập đã di chuyển trong vòng 15 phút mà chúng tôi đã xác định. 3% khác đã thực hiện trong một giờ đầu tiên, 1% trong ngày đầu tiên và một vài stragglers mất tới ba ngày.

(Vâng, OK, tôi đang nhầm lẫn tỷ lệ lưu lượng truy cập với tỷ lệ phần trăm của máy chủ tên. Vui lòng chèn thao tác cầm tay.)

Tuy nhiên, đó là vào khoảng năm 2001 và chúng tôi đã sử dụng khủng long để truyền các gói thông qua các ống. Tôi đoán là các máy chủ tên ngày nay hoạt động tốt hơn, và sẽ có ít vấn đề hơn với các stragglers. Có ai có cảm giác bao nhiêu phần trăm lưu lượng sẽ chuyển đổi trong TTL được xác định những ngày này không? Vẫn còn nhiều máy chủ tên mà bỏ qua TTL?

Chúng tôi đã di chuyển gần đây và có tất cả các loại vấn đề với DNS.

Khi chúng tôi thực hiện giao dịch, hầu hết khách hàng bắt đầu truy cập IP mới ngay lập tức. Nhưng một số vẫn còn đánh các IP cũ trong nhiều tuần. Chúng tôi đã để lại một máy chủ trong khoảng một tháng. Cuối cùng, chúng tôi đã duyệt qua nhật ký IIS trên máy cũ và gọi cho khách hàng bảo họ xóa DNS trên máy chủ DNS của công ty hoặc ISP. Điều đó đã khiến người cuối cùng của họ chuyển đến.

Đó là một số ít người giữ các IP cũ. Trong số 20k khách hàng, có thể 50 người có vấn đề sau ngày đầu tiên.

(Rất) giá trị TTL dài của các tuần là vào tháng 5 năm 2011 được vinh danh bởi hầu hết các máy chủ tên phân giải DNS tối đa 2 tuần.

Trong thử nghiệm sử dụng just-dnslookup.com, có 50 điểm đo hoạt động phân tán toàn cầu, với một bản ghi A được đặt thành 99.999.999 = 165 tuần (chính xác: 165 tuần 2 ngày 9 giờ 46 phút 39 giây) và một mặc định TTL trong 2 tuần (= SOA + NS TTL).

Tra cứu đầu tiên trả về:

• TTL 1 tuần, cho 3 trên 50 điểm đo
• chỉ số TTL là 165 tuần, cho 47 trên 50 điểm đo

Liên tục trả về tra cứu (được chuyển đổi thành giá trị TTL gốc):

• TTL 1 tuần, cho 3 trên 50 điểm đo
• một TTL trong 2 tuần, cho 46 trên 50 điểm đo
• chỉ số TTL là 165 tuần, cho 1 trên 50 điểm đo

Thử nghiệm thứ hai (sử dụng một tên miền khác) trong đó kết quả TTL mặc định được đặt thành 4 tuần (= SOA + NS TTL) bên dưới.

Tra cứu đầu tiên trả về:

• TTL 1 tuần, cho 3 trên 50 điểm đo
• một TTL trong 2 tuần, cho 1 trên 50 điểm đo
• chỉ số TTL là 165 tuần, cho 46 trên 50 điểm đo

Liên tục trả về tra cứu (được chuyển đổi thành toàn bộ chiều dài):

• TTL 1 tuần, cho 3 trên 50 điểm đo
• một TTL trong 2 tuần, cho 47 trên 50 điểm đo
• chỉ số TTL là 165 tuần, cho 0 trên 50 điểm đo

Từ các dịch vụ giải quyết công khai được biết đến nhiều nhất / được kết nối tốt nhất:

• DNS công cộng của Google [8.8.8.8 và 8.8.4.4] giảm xuống còn 1 ngày.
• UltraDNS [rdns (1 | 2) .ultradns.net] vinh dự đủ 165 tuần.
• Sprintlink [ns (1 | 2 | 3) .sprintlink.net] vinh dự đủ 165 tuần.

Gần đây tôi đã chuyển DNS cho một vài tên miền lưu trữ trang web cá nhân và các trang web dự án của tôi từ GoDaddy sang DNS trong nhà (vâng, nghĩa đen là nhà của tôi ). Nhìn chung, mọi trang web mà tôi có quyền truy cập từ xa đều tôn trọng TTL và thực hiện chuyển đổi tốt. Điều tương tự cũng được báo cáo bởi mọi người bạn tôi có thể yêu cầu kiểm tra, cả qua điện thoại cố định và di động. Vấn đề duy nhất, trớ trêu thay, là các máy chủ DNS bộ nhớ đệm chính tại $ University nơi tôi làm việc, dường như hoàn toàn coi thường TTL đối với các truy vấn được lưu trong bộ nhớ cache (và thậm chí bỏ qua giá trị TTL mà chúng đang gán cho kết quả được lưu trong bộ nhớ cache).

Có vẻ như, về tổng thể, TTL nên được tôn trọng. 56% máy chủ có thẩm quyền cho các tên miền .com và .net đang chạy BIND, rõ ràng là hoạt động tốt với các tiêu chuẩn. Cablevision / Optimum (ít nhất là ở NJ) dường như đang sử dụng Nominum CNS, cũng tôn trọng các TTL.

Đây không phải là một câu trả lời cho câu hỏi của bạn cụ thể; nhưng đúng hơn, những điều bổ sung để xem xét điều đó trong thử nghiệm của bạn:

Churs DNS Recursors và bộ nhớ đệm Daemons

Nó không chỉ là đệ quy DNS cạnh mà ghi lại bộ đệm. Đôi khi mọi người chuỗi đệ quy và điều này thêm thời gian. Việc này có nên được thực hiện hay không có thể là một cuộc thảo luận dài dựa trên những gì mọi người đang cố gắng giải quyết. Tôi đã thấy 3 cấp độ đệ quy trong một trung tâm dữ liệu. Trộn các đệ quy có thể có kết quả hỗn hợp, vì các phân rã TTL không phải lúc nào cũng được bảo toàn. Một số bản ghi hệ điều hành bộ đệm. Một số hệ thống cũng sử dụng những thứ như nscd, dnsmasqvà các phương pháp khác để giảm thiểu tác động của các vấn đề recursor địa phương và để giảm tải trên recursors của họ. Các đặc điểm tại HĐH khác nhau dựa trên phiên bản phát hành, trình nền bộ đệm, phiên bản trình nền bộ đệm, v.v ...

[Chỉnh sửa] Để nhắc lại, đây không phải là hành vi bình thường của trình nền hoặc bộ đệm ẩn. Tôi sẽ không xấu hổ về những lỗi, nhưng một trong số chúng được coi là không rõ ràng, mặc dù nó được đóng gói với nhiều bản phân phối linux.

Ứng dụng DNS Cache

Một số trình duyệt cũng lưu trữ hồ sơ. Java và các ứng dụng khác cũng lưu DNS. Đôi khi bạn có thể giới hạn tối đa ttl trong các ứng dụng.

Kết quả cuối cùng có thể được xiên

Các mục trên có thể dễ dàng biến một 15 phút TTL thành 60+ phút hoặc thậm chí lâu hơn.

Đây là lý do tại sao tôi thường đề xuất rằng các ứng dụng hoặc trang web nên xem xét việc có nhiều nút hoạt động trong thiết kế khả năng chịu lỗi của chúng, để khách hàng có thể xác định nhanh hơn khi một điểm truy cập vào trang web của bạn bị lỗi và tự động xử lý sự cố theo cách trang nhã và có thể dự đoán được , khi khả thi. Anycast là một phương pháp mà một số công ty sử dụng để chuyển đổi dự phòng có phần minh bạch và không phụ thuộc quá nhiều vào thay đổi DNS. Ngoài ra còn có một số phương pháp cân bằng tải thông minh có thể được thực hiện trong javascript bằng nhiều bản ghi DNS.

Câu hỏi cũ, nhưng câu trả lời mới (2017, 6 năm sau):

1. Có vẻ như gần như tất cả các máy chủ DNS trên toàn thế giới cập nhật trong 5 phút
2. Google và OpenDNS cho phép bạn xóa thủ công bản ghi DNS, tăng tốc cập nhật lan truyền

Trước các thử nghiệm bên dưới, trước đây tôi đã thay đổi TTL từ 14400 (giây = 4 giờ) thành 300 (giây = 5 phút) nhưng tôi đã làm điều đó 2 giờ trước các thử nghiệm và vì TTL trước đó là 4 giờ nên tôi không chắc chắn sự thay đổi của mình sẽ nhận ra nếu các máy chủ DNS không có TTL tối thiểu của riêng họ.

Thí nghiệm của tôi:

Thí nghiệm 1:

Tôi đã thay đổi bản dịch tên-IP (Bản ghi) trong máy chủ có thẩm quyền sau đó kiểm tra:

• https://www.whatsmydns.net
• https://dnschecker.org

Sau 5 phút (300 giây), khoảng một nửa số máy chủ toàn cầu được kiểm tra bởi các trang web đó đã bị udpated.

Sau 7 phút, tất cả đã được cập nhật ngoại trừ 1.

Thí nghiệm 2:

Google và OpenDNS cho phép bạn xóa thủ công bộ đệm DNS của họ cho một tên miền cụ thể. Liên kết:

• Xóa mục nhập bộ đệm DNS của Google cho tên miền của bạn: https://developers.google.com/speed/public-dns/cache
• Xóa mục nhập bộ đệm DNS của OpenDNS cho tên miền của bạn: https://cachecheck.opendns.com/

Tôi đã cập nhật một bản ghi A khác và sau đó xóa ngay bộ đệm DNS của Google. Họ có một hình ảnh xác thực khiến tôi "nhấp vào tất cả các ô vuông có dấu hiệu" 3 lần, vì vậy phải mất 1-2 phút trước khi tôi có thể hoàn thành việc xả nước.

Sau 4 phút, chỉ có 1 máy chủ DNS được kiểm tra bởi các trang web đó có địa chỉ IP cũ. Tất cả những người khác đã được cập nhật.

Vì vậy, xóa bộ nhớ cache DNS của Google và buộc nó truy vấn lại máy chủ có thẩm quyền, dường như đã tăng tốc độ lan truyền DNS toàn cầu, có lẽ bằng cách kích hoạt cập nhật bộ đệm trên các máy chủ của thế giới.

Tuy nhiên, ngay cả khi không có Google tuôn ra, nó vẫn xuất hiện sự lan truyền trong vài phút chứ không phải vài giờ hoặc vài ngày.