Kết nối VPN và một tên máy chủ phân giải thành địa chỉ của hôm qua, hoặc không phân giải được gì. Ngắt kết nối và nó lại chạy. Phản xạ đầu tiên là đổ lỗi cho trình phân giải mà đường hầm áp đặt, nhưng nguyên nhân phổ biến hơn là một máy chủ tên đã công bố ngừng nhận cập nhật vùng. Đường đi mới chỉ đơn giản đến một nguồn có thẩm quyền khác với nguồn mà câu trả lời đã lưu trong bộ nhớ đệm của bạn đến từ đó.

Triệu chứng thay đổi theo trình phân giải

Một trình phân giải đệ quy trả về điều mà nguồn có thẩm quyền đã nói, rồi giữ câu trả lời đó trong suốt TTL. Nếu đường hầm áp đặt một trình phân giải khác, hoặc thay đổi đường đi để trình phân giải cũ không còn truy cập được, máy khách hỏi một nguồn có thẩm quyền khác và nhận câu trả lời khác. Tên miền không thay đổi vào lúc đó; cách nhìn của bạn về nó đã thay đổi.

Đó là lý do cùng một tên có thể hoạt động ở một văn phòng và thất bại từ khách sạn, và cũng là lý do việc xóa bộ nhớ đệm cục bộ chỉ đôi khi hữu ích. Xóa bộ nhớ đệm gửi câu hỏi lại đến đúng nguồn có thẩm quyền đó.

Phép thử phân biệt là một truy vấn trực tiếp đến từng máy chủ đã công bố.

Hỏi trực tiếp từng nguồn có thẩm quyền

Hãy bắt đầu từ việc ủy quyền chứ không phải từ một danh sách bạn nhớ. Hỏi máy chủ cha về tập NS, rồi truy vấn từng tên trong tập đó cho bản ghi bạn cần. Hai truy vấn về cùng một tên ở các nguồn có thẩm quyền khác nhau cho bạn biết ngay vùng có nhất quán hay không.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Làm điều tương tự với các bản ghi NS ở đỉnh vùng, vì sau một lần di chuyển, việc ủy quyền từ máy chủ cha và tập NS riêng của vùng có thể khác nhau. Số sê-ri trên SOA là thứ tiếp theo cần so sánh, và một máy chủ thứ cấp tụt lại rất xa là vấn đề truyền tải chứ không phải vấn đề câu trả lời.

Chạy những truy vấn đó từ mạng bị lỗi, không chỉ từ bàn làm việc của bạn.

Tách các góc nhìn dự định khỏi các góc nhìn hỏng

Một số tên miền cố ý trả lời khác nhau theo khu vực hoặc nhóm trình phân giải, và cấu hình chân trời tách rời là bình thường trong mạng doanh nghiệp.

Câu hỏi là liệu sự khác biệt có được ghi chép và ổn định hay không. Một góc nhìn không dự định trông khác đi: một nguồn có thẩm quyền có bản ghi mà các nguồn khác chưa bao giờ nhận được, hoặc thiếu bản ghi mà tất cả cùng chia sẻ. Hướng dẫn của RFC 2182 về lựa chọn và triển khai coi khả năng sẵn sàng có thẩm quyền là trách nhiệm chung, và đó là khung đúng ở đây. Dự phòng chỉ tồn tại nếu mọi máy chủ đã công bố có thể trả lời bằng dữ liệu dự định, không chỉ chấp nhận một kết nối trên cổng 53.

Một máy chủ trả lời SERVFAIL dễ chẩn đoán hơn một máy chủ trả lời đầy tự tin nhưng sai.

Một lần di chuyển phơi bày điều mà bộ nhớ đệm che giấu

Trong lúc chuyển nhà cung cấp, hai vị trí có thẩm quyền thay đổi: việc ủy quyền từ máy chủ cha và các bản ghi NS riêng của vùng. Cả hai đều phải được cập nhật, và cả hai đều được lưu đệm theo TTL của chúng. Nếu một máy chủ cũ vẫn chạy và tiếp tục phục vụ vùng trước đó, những máy khách mà trình phân giải của họ hỏi nó sẽ tiếp tục nhận câu trả lời cũ rất lâu sau khi quá trình chuyển đổi trông như đã hoàn tất.

Đó chính xác là trạng thái mà một bộ nhớ đệm lâu đời che giấu. Máy trạm hoạt động cả tuần đang nói chuyện với một trình phân giải giữ câu trả lời mới từ nguồn có thẩm quyền mới, trong khi cái cũ vẫn tiếp tục phân phát dữ liệu cũ cho mọi người khác.

Đổi trình phân giải trên một máy tính xách tay chỉ sửa máy đó và không gì khác.

Sửa vùng, không phải trình phân giải

Xác định máy chủ nào phải là có thẩm quyền cho vùng, sửa vùng được quản lý hoặc việc ủy quyền để mỗi máy chủ phục vụ dữ liệu dự định, và giữ lại dự phòng mà bạn đã hoạch định. Xóa một máy chủ tên vì một lối ra VPN nhận được câu trả lời lạ làm giảm khả năng sẵn sàng và để nguyên sự không nhất quán.

Sau đó chạy lại các truy vấn trực tiếp từ cả hai mạng và chờ TTL của bản ghi bạn đã sửa hết hạn.

Xác nhận câu trả lời ổn định từ mỗi nguồn có thẩm quyền, và ghi góc nhìn dự định vào tài liệu của vùng để sự khác biệt tiếp theo dễ được phân loại.

Bài viết liên quan