Độ trễ DNS thấp là chìa khóa để duyệt internet nhanh. Để giảm thiểu nó, điều quan trọng là phải lựa chọn cẩn thận các máy chủ DNS và . Nhưng bước đầu tiên là loại bỏ những truy vấn vô dụng.
Đây là lý do tại sao DNS ban đầu được thiết kế như một giao thức có khả năng lưu trữ cao. Quản trị viên vùng đặt thời gian tồn tại (TTL) cho từng mục nhập và trình phân giải sử dụng thông tin này khi lưu trữ các mục nhập trong bộ nhớ để tránh lưu lượng truy cập không cần thiết.
Bộ nhớ đệm có hiệu quả không? Cách đây vài năm, nghiên cứu nhỏ của tôi cho thấy nó không hoàn hảo. Chúng ta hãy nhìn vào tình hình hiện tại.
Để thu thập thông tin tôi đã vá để lưu giá trị TTL cho phản hồi. Nó được định nghĩa là TTL tối thiểu của các bản ghi cho mỗi yêu cầu đến. Điều này cung cấp cái nhìn tổng quan tốt về phân phối TTL của lưu lượng truy cập thực và cũng tính đến mức độ phổ biến của các yêu cầu riêng lẻ. Phiên bản vá lỗi của máy chủ đã hoạt động được vài giờ.
Tập dữ liệu kết quả bao gồm 1 bản ghi (tên, qtype, TTL, dấu thời gian). Đây là phân phối TTL tổng thể (trục X là TTL tính bằng giây):
Ngoài một sự thay đổi nhỏ ở mức 86 (chủ yếu đối với các bản ghi SOA), khá rõ ràng là các TTL nằm ở phạm vi thấp. Chúng ta hãy xem xét kỹ hơn:
Được rồi, TTL lớn hơn 1 giờ không có ý nghĩa thống kê. Sau đó hãy tập trung vào phạm vi 0−3600:
Hầu hết các TTL là từ 0 đến 15 phút:
Phần lớn là từ 0 đến 5 phút:
Không được tốt lắm.
Phân phối tích lũy làm cho vấn đề trở nên rõ ràng hơn:
Một nửa số phản hồi DNS có TTL từ 1 phút trở xuống và 5/XNUMX có TTL từ XNUMX phút trở xuống.
Nhưng chờ đã, nó thực sự còn tệ hơn. Suy cho cùng, đây là TTL từ các máy chủ có thẩm quyền. Tuy nhiên, các trình phân giải máy khách (ví dụ: bộ định tuyến, bộ đệm cục bộ) nhận được TTL từ các trình phân giải ngược dòng và nó giảm dần sau mỗi giây.
Vì vậy, khách hàng thực sự có thể sử dụng mỗi mục nhập với giá trung bình là một nửa TTL ban đầu trước khi gửi yêu cầu mới.
Có lẽ những TTL rất thấp này chỉ áp dụng cho các yêu cầu bất thường chứ không áp dụng cho các trang web và API phổ biến? Chúng ta hãy xem:
Trục X là TTL, trục Y là mức độ phổ biến của truy vấn.
Thật không may, các truy vấn phổ biến nhất cũng là những truy vấn khó lưu vào bộ nhớ đệm nhất.
Hãy phóng to:
Bản án: nó thực sự tồi tệ. Trước đây nó đã tệ rồi, bây giờ nó còn tệ hơn nữa. Bộ nhớ đệm DNS đã trở nên hầu như vô dụng. Khi có ít người sử dụng trình phân giải DNS của ISP hơn (vì những lý do chính đáng), độ trễ sẽ tăng lên đáng chú ý hơn.
Bộ nhớ đệm DNS chỉ trở nên hữu ích đối với nội dung không có ai truy cập.
Cũng xin lưu ý rằng phần mềm có thể giải thích TTL thấp.
Tại sao vậy?
Tại sao bản ghi DNS được đặt ở mức TTL thấp như vậy?
- Bộ cân bằng tải cũ được giữ nguyên cài đặt mặc định.
- Có nhiều quan niệm sai lầm rằng cân bằng tải DNS phụ thuộc vào TTL (điều này không đúng - kể từ thời Netscape Navigator, khách hàng đã chọn một địa chỉ IP ngẫu nhiên từ một tập hợp RR và thử một địa chỉ khác một cách minh bạch nếu họ không thể kết nối)
- Quản trị viên muốn áp dụng các thay đổi ngay lập tức nên việc lập kế hoạch sẽ dễ dàng hơn.
- Quản trị viên của máy chủ DNS hoặc bộ cân bằng tải coi nhiệm vụ của mình là triển khai hiệu quả cấu hình mà người dùng yêu cầu và không tăng tốc các trang web và dịch vụ.
- TTL thấp giúp bạn yên tâm.
- Ban đầu mọi người đặt TTL thấp để thử nghiệm và sau đó quên thay đổi chúng.
Tôi không đưa "chuyển đổi dự phòng" vào danh sách vì nó ngày càng trở nên ít liên quan hơn. Nếu bạn cần chuyển hướng người dùng đến một mạng khác chỉ để hiển thị một trang lỗi khi mọi thứ khác hoàn toàn bị hỏng thì độ trễ hơn 1 phút có thể được chấp nhận.
Ngoài ra, TTL kéo dài một phút có nghĩa là nếu các máy chủ DNS có thẩm quyền bị chặn trong hơn 1 phút thì không ai khác có thể truy cập các dịch vụ phụ thuộc. Và sự dư thừa sẽ không giúp ích gì nếu nguyên nhân là do lỗi cấu hình hoặc bị hack. Mặt khác, với TTL hợp lý, nhiều client sẽ tiếp tục sử dụng cấu hình trước đó và không bao giờ nhận thấy điều gì.
Các dịch vụ CDN và bộ cân bằng tải phần lớn là nguyên nhân gây ra TTL thấp, đặc biệt là khi chúng kết hợp CNAME với TTL thấp và các bản ghi có TTL thấp (nhưng độc lập) như nhau:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Bất cứ khi nào CNAME hoặc bất kỳ bản ghi A nào hết hạn, yêu cầu mới phải được gửi. Cả hai đều có TTL 30 giây, nhưng nó không giống nhau. TTL trung bình thực tế sẽ là 15 giây.
Nhưng chờ đã! Nó thậm chí còn tệ hơn. Một số trình phân giải hoạt động rất tệ trong tình huống này với hai TTL thấp liên quan:
$ khoan raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 TRONG CNAME github.map.fastly.net. github.map.fastly.net. 1 TRONG MỘT 151.101.16.133
Trình phân giải Cấp 3 có thể chạy trên BIND. Nếu bạn tiếp tục gửi yêu cầu này, TTL bằng 1 sẽ luôn được trả về. raw.githubusercontent.com không bao giờ được lưu trữ.
Đây là một ví dụ khác về tình huống như vậy với một tên miền rất phổ biến:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Ít nhất ba bản ghi CNAME. Ờ. Một người có TTL khá tốt, nhưng nó hoàn toàn vô dụng. Các CNAME khác có TTL ban đầu là 60 giây, nhưng đối với tên miền akamai.net TTL tối đa là 20 giây và không có cái nào trong số chúng cùng pha.
Còn những miền liên tục thăm dò ý kiến thiết bị Apple thì sao?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Vấn đề tương tự như Firefox và TTL sẽ bị kẹt ở hầu hết 1 giây khi sử dụng trình phân giải Cấp 3.
Dropbox?
$ khoan client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ khoan client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 TRONG 162.125.64.3
Tại buổi ghi âm safebrowsing.googleapis.com Giá trị TTL là 60 giây, giống như tên miền Facebook. Và một lần nữa, theo quan điểm của khách hàng, những giá trị này giảm đi một nửa.
Làm cách nào để thiết lập TTL tối thiểu?
Sử dụng tên, loại yêu cầu, TTL và dấu thời gian được lưu trữ ban đầu, tôi đã viết một tập lệnh mô phỏng 1,5 triệu yêu cầu chuyển qua trình phân giải bộ đệm để ước tính số lượng yêu cầu không cần thiết được gửi do mục nhập bộ đệm đã hết hạn.
47,4% yêu cầu được thực hiện sau khi bản ghi hiện có hết hạn. Đây là mức cao một cách vô lý.
Điều gì sẽ tác động đến bộ nhớ đệm nếu đặt TTL tối thiểu?
Trục X là giá trị TTL tối thiểu. Các bản ghi có TTL nguồn trên giá trị này sẽ không bị ảnh hưởng.
Trục Y là tỷ lệ phần trăm yêu cầu từ máy khách đã có mục nhập được lưu trong bộ nhớ đệm nhưng mục này đã hết hạn và đang thực hiện yêu cầu mới.
Tỷ lệ yêu cầu “bổ sung” giảm từ 47% xuống 36% chỉ bằng cách đặt TTL tối thiểu thành 5 phút. Bằng cách đặt TTL tối thiểu thành 15 phút, số lượng yêu cầu này giảm xuống còn 29%. TTL tối thiểu là 1 giờ sẽ giảm chúng xuống còn 17%. Sự khác biệt đáng kể!
Còn việc không thay đổi bất cứ điều gì ở phía máy chủ mà thay vào đó đặt TTL tối thiểu trong bộ đệm DNS của máy khách (bộ định tuyến, bộ phân giải cục bộ) thì sao?
Số lượng yêu cầu được yêu cầu giảm từ 47% xuống 34% với TTL tối thiểu là 5 phút, xuống 25% với tối thiểu 15 phút và xuống 13% với tối thiểu 1 giờ. Có lẽ 40 phút là tối ưu.
Tác động của sự thay đổi nhỏ này là rất lớn.
Hậu quả là gì?
Tất nhiên, dịch vụ có thể được chuyển sang nhà cung cấp đám mây mới, máy chủ mới, mạng mới, yêu cầu khách hàng sử dụng bản ghi DNS mới nhất. Và một TTL khá nhỏ giúp thực hiện quá trình chuyển đổi như vậy một cách suôn sẻ và không thể nhận thấy. Nhưng với việc chuyển đổi sang cơ sở hạ tầng mới, không ai mong đợi khách hàng sẽ di chuyển sang bản ghi DNS mới trong vòng 1 phút, 5 phút hoặc 15 phút. Việc đặt TTL tối thiểu thành 40 phút thay vì 5 phút sẽ không ngăn người dùng truy cập dịch vụ.
Tuy nhiên, điều này sẽ làm giảm đáng kể độ trễ và cải thiện quyền riêng tư cũng như độ tin cậy bằng cách tránh các yêu cầu không cần thiết.
Tất nhiên, RFC nói rằng TTL phải được tuân thủ nghiêm ngặt. Nhưng thực tế là hệ thống DNS đã trở nên quá kém hiệu quả.
Nếu bạn đang làm việc với các máy chủ DNS có thẩm quyền, vui lòng kiểm tra TTL của bạn. Bạn có thực sự cần những giá trị thấp đến nực cười như vậy không?
Tất nhiên, có những lý do chính đáng để đặt TTL nhỏ cho bản ghi DNS. Nhưng đối với 75% lưu lượng DNS hầu như không thay đổi thì không.
Và nếu vì lý do nào đó mà bạn thực sự cần sử dụng TTL thấp cho DNS, đồng thời hãy đảm bảo rằng trang web của bạn không bật bộ nhớ đệm. Vì những lý do tương tự.
Nếu bạn có bộ đệm DNS cục bộ đang chạy, chẳng hạn như cho phép bạn đặt TTL tối thiểu, hãy sử dụng chức năng này. Điều này ổn. Sẽ không có chuyện gì xấu xảy ra đâu. Đặt TTL tối thiểu thành khoảng 40 phút (2400 giây) và 1 giờ. Một phạm vi khá hợp lý.
Nguồn: www.habr.com
