Lỗi phân giải DNS là gì?

Proxy Scrapeless định tuyến các yêu cầu của client thông qua hạ tầng cổng (gateway) đặt ra các ranh giới riêng về đặt tên và kết nối tiếp theo.

Lỗi phân giải DNS xảy ra khi trình phân giải không thể lấy được thông tin hữu ích cần để hoàn thành một truy vấn DNS. Ứng dụng thường dùng cụm từ này rộng hơn cho bất kỳ tra cứu nào không tạo ra địa chỉ có thể sử dụng. Để chẩn đoán chính xác, hãy phân biệt lỗi phân giải với một câu trả lời âm tính hợp lệ nói rằng tên hoặc bản ghi được yêu cầu không tồn tại.

Lỗi DNS có nghĩa chính xác và nghĩa thực tế

Trình phân giải hoàn tất một truy vấn bằng cách lấy được thông tin đặt tên hoặc một câu trả lời âm tính có ý nghĩa. Khi nó không thể lấy được thông tin hữu ích, việc phân giải đã thất bại. Phân loại lỗi phân giải DNS phân biệt rõ điều kiện này với các câu trả lời âm tính. Sự phân biệt đó hữu ích ngay cả khi thông báo cấp cao của ứng dụng gọi cả hai kết quả đều là lỗi tra cứu.

Một ứng dụng cần địa chỉ có thể không tiếp tục được sau một số kết quả khác nhau. Tên máy chủ có thể không tồn tại. Tên có thể tồn tại nhưng thiếu bản ghi địa chỉ được yêu cầu. Trình phân giải có thể gặp lỗi máy chủ, cơ quan thẩm quyền không thể truy cập hoặc vấn đề xác thực. Hãy giữ nguyên kết quả DNS cơ bản thay vì gộp chúng vào “miền không khả dụng.”

Các mã phản hồi DNS và định dạng bản ghi cung cấp từ vựng cho các kết quả này. Đối với một bản ghi sự cố thực tế, hãy giữ nguyên tên được truy vấn, kiểu bản ghi được yêu cầu, mã phản hồi khi có, và trình phân giải đã dùng. Một ảnh chụp màn hình kiểu “không thể truy cập site” thường bỏ qua hầu hết bằng chứng đó.

Sự cố phân giải tên xảy ra trước khi client có thể dùng địa chỉ nhận được cho kết nối dự định. DNS thành công không đảm bảo rằng địa chỉ trả về chấp nhận dịch vụ được yêu cầu. Hãy tách riêng kết quả tra cứu và kết quả kết nối về sau để một câu trả lời DNS hoạt động không che khuất một listener không thể truy cập.

Câu trả lời âm tính, lỗi máy chủ và truy vấn không được trả lời

Một câu trả lời DNS âm tính truyền đạt thông tin về tên hoặc bản ghi được yêu cầu. NXDOMAIN cho biết tên được truy vấn không tồn tại trong câu trả lời DNS đó. Kết quả không có dữ liệu có thể cho biết tên tồn tại nhưng thiếu kiểu bản ghi được yêu cầu. Đây là những câu trả lời có ý nghĩa, ngay cả khi ứng dụng không thể dùng chúng để kết nối.

Phản hồi lỗi máy chủ cho biết máy chủ DNS phản hồi không thể hoàn tất truy vấn thành công. Hết thời gian chờ cho biết client không nhận được phản hồi cần thiết trong thời hạn của nó. Những kết quả này cần bằng chứng về trình phân giải và đường đi đến cơ quan thẩm quyền; chúng không chứng minh rằng tên máy chủ được yêu cầu là không tồn tại.

Tránh diễn giải một mã runtime chung chung như một chẩn đoán DNS đầy đủ. Một số thư viện báo lỗi tra cứu mà không lộ mã phản hồi DNS, và một số giao diện đặt tên đưa các nguồn cấu hình cục bộ vào đường tra cứu. Hãy giữ lại chi tiết runtime ban đầu và thu thập bằng chứng cụ thể về DNS khi có thể.

Đối với tên máy chủ do mình sở hữu, hãy so sánh trạng thái bản ghi có thẩm quyền với truy vấn thực sự bị lỗi. Kiểm tra chính tả, tên miền con, kiểu bản ghi và ủy quyền. Đối với tên máy chủ bên thứ ba, hãy ghi lại kết quả và phạm vi quan sát được mà không giả định rằng bạn có thể sửa vùng của họ. Nhà vận hành đích kiểm soát thông tin đặt tên được công bố của họ.

Truy vấn cùng một tên qua cùng một đường đi trình phân giải

Lựa chọn trình phân giải là một phần của quan sát. Máy trạm, container, trình duyệt và cổng proxy có thể dùng các đường đặt tên khác nhau. Một truy vấn thành công từ một môi trường không chứng minh rằng môi trường khác có thể phân giải cùng tên hoặc nhận cùng câu trả lời.

Xác định chính xác tên mà ứng dụng yêu cầu. Tên máy chủ gateway proxy, tên máy chủ đích và điểm đến chuyển hướng đều có thể cần tra cứu. Nếu lỗi liên quan đến gateway, việc kiểm tra tên website sẽ bỏ qua truy vấn đang bị lỗi. Nếu một chuyển hướng thay đổi máy chủ, trang đầu có thể phân giải thành công trong khi máy chủ tiếp theo thất bại.

Mô hình trình phân giải DNS và máy chủ có thẩm quyền giải thích tại sao vị trí truy vấn lại quan trọng. Một trình phân giải có thể trả lời từ bộ nhớ đệm hoặc theo ủy quyền đã công bố để lấy thông tin. Trong môi trường doanh nghiệp, một trình phân giải riêng còn có thể cung cấp các tên nội bộ đã được phê duyệt mà các trình phân giải công cộng không thể phân giải.

Đừng thay thế một trình phân giải bắt buộc của tổ chức bằng trình phân giải công cộng như một cách sửa lỗi mò mẫm. So sánh có thể hữu ích khi chính sách cho phép, nhưng kết quả khác biệt cần được diễn giải. Đặt tên nội bộ, chính sách mạng và split DNS có thể khiến câu trả lời riêng khác biệt một cách có chủ ý. Hãy giữ nguyên đường đặt tên bắt buộc cho các bản ghi sản xuất được chấp nhận.

Bộ nhớ đệm giải thích một số khác biệt giữa các quan sát

Bộ nhớ đệm DNS làm thay đổi thông tin mà trình phân giải trả về theo thời gian. Một bản ghi được lưu trong bộ nhớ đệm hoặc câu trả lời âm tính có thể vẫn còn liên quan sau khi vùng có thẩm quyền thay đổi. Các quy tắc bộ nhớ đệm DNS âm tính giải thích rằng thông tin vắng mặt cũng có thể được lưu trong bộ nhớ đệm như các câu trả lời dương tính. Điều này làm cho “bản ghi đã được thêm” khác với “mọi client hiện đều thấy bản ghi đó.”

Kiểm tra câu trả lời đã quan sát và ngữ cảnh bộ nhớ đệm của nó trước khi xóa trạng thái cục bộ. Thay đổi bộ nhớ đệm cục bộ không thể sửa một ủy quyền có thẩm quyền hoặc kết quả được lưu trữ của trình phân giải từ xa. Nếu các client không đồng ý, hãy ghi lại trình phân giải và câu trả lời mà mỗi bên đã thấy. Sự bất đồng là bằng chứng hữu ích, không phải là bằng chứng rằng một client bị lỗi.

Đối với một quá trình di chuyển vùng do bạn sở hữu, hãy lập kế hoạch thay đổi bản ghi và ủy quyền với hành vi bộ nhớ đệm dự kiến trong đầu. Xác thực các điểm cuối dịch vụ cũ và mới trong khi thay đổi tên đang được quan sát. Một client truy cập một địa chỉ cũ có thể gặp lỗi chứng chỉ hoặc kết nối ở giai đoạn sau ngay cả khi truy vấn DNS của nó tự thân đã hoàn tất thành công.

Giữ lỗi của trình phân giải tách biệt với các câu trả lời phủ định trong giám sát. Sự gia tăng kết quả không-tìm-thấy-tên có thể cho thấy một nguồn URL sai định dạng hoặc một tên miền phụ không tồn tại. Sự gia tăng lỗi máy chủ có thể chỉ ra đường dẫn phân giải. Loại phản hồi quyết định bằng chứng nào cần được kiểm tra tiếp theo.

DNS phía proxy thêm một ranh giới đặt tên khác

Một quy trình làm việc với proxy có thể phân giải tên tại nhiều vị trí. Client thường cần phân giải cổng vào proxy của nó trước khi kết nối. Việc phân giải đích có thể xảy ra tại proxy tùy theo giao thức và cấu hình client. Xác định nơi tra cứu diễn ra thay vì giả định toàn bộ DNS là cục bộ.

Đối với một phiên HTTP CONNECT nêu tên máy chủ đích, đường đi tiếp theo của cổng vào là quan trọng. Nếu cổng vào không thể phân giải hoặc kết nối tới mục tiêu, client có thể nhận lỗi đường hầm hoặc phản hồi proxy thay vì lỗi từ trình phân giải cục bộ của nó. Ghi lại phản hồi proxy và authority của yêu cầu để nhà vận hành cổng vào có thể điều tra.

Client SOCKS cũng có thể khác nhau trong cách xử lý tên đích. Sử dụng hành vi được tài liệu hóa của chế độ proxy mà client đã chọn. Việc chỉ có một proxy SOCKS không đủ để xác định liệu client cục bộ hay cổng vào phân giải một hostname cụ thể.

Hiện tại Cấu hình điểm cuối proxy Scrapeless cung cấp các giá trị cổng vào cần thiết cho ranh giới phía client. Sao chép những giá trị đó từ kênh đã được ủy quyền. Một lỗi gõ trong hostname của cổng vào tạo ra một sự cố khác với lỗi phân giải miền đích, dù cả hai đều có thể làm gián đoạn việc thu thập trước khi nội dung sẵn sàng.

Chẩn đoán DNS so với các giai đoạn mạng phía sau

Một kết quả DNS nên được giữ như một giai đoạn riêng biệt trong bản ghi yêu cầu. Điều này ngăn lỗi kết nối ở hạ lưu bị gắn nhãn sai là lỗi phân giải tên.

Một câu trả lời địa chỉ chứng minh rằng trình phân giải đã trả về một địa chỉ trong các điều kiện đã quan sát. Nó không chứng minh rằng địa chỉ thuộc về một ứng dụng hiện đang khỏe mạnh hoặc chứng chỉ đích khớp với tên được yêu cầu. Từ chối kết nối, lỗi TLS và phản hồi HTTP đều cần bằng chứng riêng của chúng.

Đối với các bộ thu thập, hãy giữ nguyên URL nguồn trong khi đánh dấu tra cứu hoặc đường đi tiếp theo là chưa được phân giải. Không biến một truy vấn không thành công thành một trang trống hợp lệ hoặc một mục đã bị gỡ bỏ. Việc thu thập đã không xác định trạng thái nội dung của tài nguyên. Giữ các URL sai định dạng trong một danh mục kiểm tra tính hợp lệ đầu vào riêng khi chính nguồn cấp đã tạo hostname sai.

Tạo một bản ghi sự cố trình phân giải hữu ích

Một bản ghi sự cố trình phân giải nên nêu tên truy vấn lỗi và điểm quan sát. Bao gồm kiểu bản ghi được yêu cầu, trình phân giải hiệu dụng, loại phản hồi, thời gian trôi qua và liệu ứng dụng đang kết nối trực tiếp hay thông qua một cổng vào. Tránh thu thập lịch sử duyệt web không liên quan hoặc tham số truy vấn riêng tư.

Khi leo thang một vấn đề vùng do bạn sở hữu, hãy thêm bản ghi có thẩm quyền dự kiến và thay đổi triển khai lẽ ra đã làm cho nó khả dụng. Khi leo thang một vấn đề cổng vào, hãy cung cấp tham chiếu kênh đã được khử nhạy cảm và authority đích. Những chi tiết này hướng nhà vận hành tới tra cứu đúng mà không để lộ mật khẩu kênh.

Mô hình định tuyến proxy đám mây cung cấp ngữ cảnh liên quan để xác định cổng vào và các ranh giới kết nối tiếp theo. Mạng proxy Scrapeless hữu ích cho việc định tuyến được quản lý, nhưng định tuyến không sửa một vùng đích được ủy quyền sai. Xem lại các gói Scrapeless hiện tại chỉ cho các yêu cầu về lưu lượng và tuyến mà bạn đã thiết lập.

Giải quyết câu hỏi về đặt tên trước câu hỏi về nội dung

Một lỗi phân giải DNS được coi là đã được giải quyết khi đường dẫn trình phân giải yêu cầu trả về thông tin đặt tên hữu dụng và đáng tin cậy cho truy vấn dự định. Một câu trả lời phủ định hợp lệ có thể thay vào đó xác lập rằng tên tài nguyên được truy vấn không tồn tại; hãy giữ rõ nghĩa đó.

Chỉ chuyển sang kiểm tra socket, TLS và HTTP sau khi giai đoạn đặt tên đã được hiểu. Ghi lại từng giai đoạn sẽ giữ được sự khác biệt giữa một hostname thiếu, một đường dẫn trình phân giải bị lỗi và một ứng dụng không khả dụng phía sau một địa chỉ đã được phân giải thành công.