NXDOMAIN qua VPN không có nghĩa là tunnel bị đứt

Thật hấp dẫn khi đọc một lần tra cứu thất bại như bằng chứng rằng tunnel đã sụp, nhất là khi tên đó hoạt động mười phút trước. Câu trả lời nói điều khác. NXDOMAIN là một giao dịch DNS đã hoàn tất, trong đó trình phân giải tuyên bố tên được hỏi không tồn tại; một tunnel hỏng thường tạo ra sự im lặng, hết thời gian chờ hoặc một nỗ lực phân giải nhằm vào máy chủ sai. Phiên bản lập luận không có wireshark là một truy vấn, một bên trả lời và một mã trả lời, và bộ ba đó đáng được ghi lại trước mọi thay đổi cấu hình.

Câu trả lời thực sự chứng minh điều gì

DNS tách những kết quả mà các máy khách thường gộp thành một thất bại duy nhất. Một tên không tồn tại tạo ra câu trả lời phủ định với mã NXDOMAIN, trong khi một tên tồn tại nhưng không có bản ghi thuộc loại được hỏi tạo ra câu trả lời thành công với phần trả lời rỗng. Cả hai đều trông như không có gì hữu ích với một ứng dụng, và chỉ một trong hai nghĩa là tên đó sai.

Khác biệt đó quyết định việc sửa chữa thuộc về đâu. Một bản ghi AAAA thiếu trên máy chủ có bản ghi A không phải là máy chủ thiếu, và việc phát hành lại chứng chỉ hay dựng lại tunnel để đuổi theo nó lãng phí manh mối duy nhất đang có. Sự phân biệt cũng định hình bước tiếp theo: vấn đề đặt tên được sửa trong vùng, còn vấn đề loại bản ghi được sửa bằng cách hỏi đúng bản ghi hoặc chấp nhận rằng họ địa chỉ đơn giản là không có.

Huyền thoại: một tên riêng bị thiếu nghĩa là tunnel đã thất bại

Huyền thoại tồn tại vì hai sự kiện đó thường đến cùng nhau. Máy khách kết nối VPN, hệ điều hành giữ lại một trình phân giải mà nó đã tin tưởng, và tên nội bộ mà nó cần lúc này được hỏi một máy chủ chưa từng nghe về vùng riêng. Máy chủ đó trả lời trung thực và theo hướng phủ định. Tunnel đang chuyên chở gói tin; câu trả lời chỉ nói về một không gian tên mà bên trả lời không phục vụ.

Các thiết lập split-horizon khiến điều này thành thường lệ: cùng một tên vùng tồn tại công khai và nội bộ với nội dung khác nhau, và chỉ trình phân giải nội bộ biết các bản ghi riêng. Vì vậy, nhận được một câu trả lời phủ định trông có thẩm quyền là bằng chứng về trình phân giải nào đã trả lời, không phải bằng chứng về trạng thái của giao diện.

Hai chi tiết cấu hình quyết định kết quả. Tunnel phải đẩy hoặc chọn trình phân giải nội bộ, và máy khách phải áp dụng lựa chọn đó cho tên đang được tra. Một quy tắc theo miền nêu một hậu tố hơi khác bản ghi bạn đã gõ sẽ gửi truy vấn theo đường công khai, và câu trả lời sẽ đúng nhưng vô dụng.

Hỏi đúng trình phân giải với đúng tên

Ghi lại bên trả lời trước khi ghi lại phán quyết. Một lần tra cứu không cho thấy máy chủ nào đã trả lời thì không thể phân biệt vấn đề chính sách với vấn đề không gian tên, và hai thứ đó có cách sửa không liên quan.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Hai dòng đầu cho thấy trình phân giải cục bộ đã quyết định gì và sẽ hỏi ai. Tra cứu +search tái tạo điều một ứng dụng làm khi nối thêm hậu tố tìm kiếm, thứ thường là truy vấn thực sự chứ không phải truy vấn được gõ vào công cụ chẩn đoán. Dòng cuối hỏi trực tiếp máy chủ nội bộ, bỏ qua chính sách của máy khách; nếu việc đó thành công trong khi tra cứu thường thất bại, vùng vẫn ổn và việc định tuyến truy vấn thì không.

Bộ nhớ đệm phủ định giải thích độ trễ sau khi sửa

Các câu trả lời phủ định được lưu đệm theo thiết kế, và RFC 2308 mô tả thời gian sống của bộ nhớ đệm phủ định được suy ra từ bản ghi thẩm quyền của vùng như thế nào. Vì vậy, sửa một bản ghi hay một quy tắc trình phân giải không bảo đảm thay đổi tức thì trên máy khách, và thử lại một lần tra vẫn trả về câu trả lời trong bộ nhớ đệm không chứng minh được gì mới. Chỉ một bên trả lời khác, một tên khác hoặc bộ nhớ đệm đã xóa mới tạo ra bằng chứng mới.

Xóa bộ nhớ đệm cục bộ, rồi lặp lại đúng truy vấn đó với đúng bên trả lời. Trên các hệ thống dùng dịch vụ phân giải cục bộ, đó là một lệnh; trên hệ thống khác, đó là khởi động lại dịch vụ hoặc một tiện ích của nền tảng, và công cụ cụ thể ít quan trọng hơn việc lặp lại một bài kiểm tra y hệt sau đó.

Tách tên khỏi đường đi

Khi tên đã phân giải thành địa chỉ riêng mong đợi, DNS kết thúc với tư cách một chủ đề và đường đi của ứng dụng trở thành câu hỏi tiếp theo. Một máy chủ trả lời tra cứu nhưng từ chối kết nối có vấn đề khác, và tiếp tục chỉnh trình phân giải sau một câu trả lời đúng là cách một sự cố có được ba thay đổi không liên quan. Hãy so sánh địa chỉ đã phân giải với địa chỉ mà dịch vụ thực sự lắng nghe trước khi cho rằng hai thứ khớp nhau.

Giữ lại bản ghi: truy vấn, bên trả lời, mã và địa chỉ đã phân giải. Bản ghi đó cũng là thứ khiến một báo cáo sau này có thể kiểm chứng, và nó là khác biệt giữa một chẩn đoán và một câu chuyện về tunnel có vẻ chậm.