Cách sửa DNS lookup chậm mà không phỏng đoán
Tách thời gian DNS khỏi kết nối, TLS và server. Thu thập mẫu nhỏ có thể lặp lại, khoanh vùng ảnh hưởng và chọn cách sửa đúng.
Tác giảYiyao
Xác nhận DNS là giai đoạn chậm
Một trang chậm có thể bị trì hoãn bởi phân giải tên, thiết lập kết nối, TLS, xử lý server hoặc truyền nội dung. Sửa lookup DNS chậm bắt đầu bằng việc tách các giai đoạn đó. Đổi resolver sẽ không sửa được ứng dụng mất vài giây để tạo phản hồi.
Chọn một hostname công khai và một hostname đối chiếu đã biết là hoạt động bình thường. Giữ thiết bị, network, trạng thái VPN và phương pháp kiểm tra cố định. Ghi lại thời điểm vấn đề xảy ra thay vì dựa vào một ấn tượng duy nhất từ tab trình duyệt đang bận.
Thu thập một mẫu thời gian nhỏ
curl --output NUL --silent --show-error --max-time 20 --write-out "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} firstbyte=%{time_starttransfer} total=%{time_total}\n" https://example.com/
Lệnh này dành cho Windows Command Prompt; dùng curl.exe nếu shell có alias curl khác. Trên macOS hoặc Linux, dùng /dev/null thay cho NUL. Trong file batch Windows, dấu phần trăm cần được escape theo quy tắc của shell. Các giá trị báo cáo tính bằng giây và thường là các mốc cộng dồn từ lúc bắt đầu, không phải năm khoảng thời gian độc lập.
Với request HTTPS trực tiếp, hãy so sánh lookup tên với các mốc kết nối và TLS trước khi đổ lỗi cho DNS. Proxy, redirect, cache, tái sử dụng kết nối và retry đều ảnh hưởng cách diễn giải. Ghi lại các điều kiện đó. Đừng biến output của một lệnh thành bảng xếp hạng tốc độ nhà cung cấp chung.
So sánh các quan sát lặp lại
| Lần chạy minh họa | Mốc DNS | Tổng thời gian | Diễn giải cần kiểm tra |
|---|---|---|---|
| Yêu cầu đầu tiên | 0.42 s | 0.90 s | Phân giải tên có thể đóng góp đáng kể |
| Lặp lại ngay | 0.02 s | 0.48 s | Cache hoặc đường đi đã làm nóng có thể giải thích cải thiện |
| Triệu chứng khác | 0.01 s | 4.20 s | Phần lớn độ trễ nằm ở nơi khác trong lần chạy này |
Đây là các giá trị ví dụ được tạo ra, không phải phép đo của Arcvenza. Request thứ hai nhanh hơn có thể liên quan đến nhiều thành phần đã warm. Giữ nhiều mẫu và kiểm tra kết quả không nhất quán. Mục tiêu là xác định một mẫu có thể lặp lại và vẫn tồn tại qua biến thiên bình thường.
Thu hẹp phạm vi bị ảnh hưởng
Nếu chỉ một thiết bị chậm, hãy so sánh cấu hình resolver, trạng thái VPN và hành vi ứng dụng của nó với một thiết bị hoạt động bình thường trên cùng network được phê duyệt. Nếu nhiều thiết bị chậm với nhiều tên, hãy điều tra resolver dùng chung hoặc đường mạng cùng người vận hành.
Nếu chỉ một domain chậm qua các quan sát độc lập, hãy kiểm tra delegation, phản hồi authoritative và chuỗi alias của nó. Chuỗi quá dài hoặc máy chủ authoritative không thể truy cập đáng để điều tra, nhưng chỉ việc có CNAME không chứng minh có lỗi.
Kiểm tra một lựa chọn thay thế mà không thay network
nslookup -type=A example.com
nslookup -type=A example.com 1.1.1.1
Khi được phép, hãy so sánh cùng một câu hỏi qua resolver thông thường và một resolver được chọn rõ ràng. Lệnh thứ hai chỉ thay đổi đích của truy vấn đó. Đừng gửi tên chỉ dùng nội bộ ra ngoài hệ thống DNS của tổ chức.
Dùng Arcvenza NSLookup như một vantage point công khai riêng biệt. Thời lượng hiển thị đo thao tác phía server từ test node được nêu. Nó không phải độ trễ trình duyệt của bạn và không nên được dùng thay cho bảng thời gian cục bộ.
Chọn và xác minh cách sửa có mục tiêu
Kết quả cũ cục bộ có thể biện minh cho reset cache cục bộ. Resolver đệ quy lỗi cần cách sửa hoặc thay đổi resolver được operator phê duyệt. Vấn đề authoritative theo domain thuộc về chủ sở hữu DNS. Sau một thay đổi, kiểm tra lại bằng thiết bị, tên và ứng dụng ban đầu.
Đừng tắt validation bảo mật, làm yếu firewall toàn cục hoặc xoay vòng nhiều resolver chỉ để đuổi theo một kết quả nhanh. Giữ cấu hình ban đầu và đường rollback. Một cách sửa hữu ích khi nó cải thiện việc hoàn thành tác vụ có thể lặp lại mà không phá tên private hoặc policy bắt buộc.
Câu hỏi thường gặp và bước tiếp theo
TTL DNS thấp hơn có luôn làm website nhanh hơn không? Không. TTL kiểm soát thời gian sống của cache; thời gian cache ngắn hơn có thể làm tăng tần suất phải thực hiện công việc phân giải.
Nên gửi gì cho bộ phận hỗ trợ? Hãy chia sẻ hostname công khai, phạm vi bị ảnh hưởng, loại truy vấn, resolver, thời điểm, trạng thái lỗi và kết quả trước/sau đã ẩn thông tin nhạy cảm. Dùng hướng dẫn xử lý DNS server khi truy vấn timeout thay vì chỉ chạy chậm.
Tài liệu kỹ thuật
Microsoft: nslookup · RFC 7766: DNS over TCP · curl command manual
Microsoft: nslookup · RFC 7766: DNS over TCP · sổ tay lệnh curl