DNS hoạt động như thế nào?

Scrapeless Proxies định tuyến lưu lượng ứng dụng qua hạ tầng proxy với các thiết lập kết nối ảnh hưởng đến đường đi mạng.

DNS, Hệ thống Tên Miền (Domain Name System), phân giải tên thành các bản ghi mà ứng dụng dùng để định vị dịch vụ và diễn giải cấu hình tên miền. Đối với truy cập web thông thường, một ứng dụng thường yêu cầu các địa chỉ gắn với một hostname. DNS cung cấp thông tin đó; sau đó ứng dụng thiết lập một kết nối riêng để yêu cầu nội dung web.

Sự tách biệt này giải thích một lỗi chẩn đoán phổ biến. Một hostname có thể được phân giải đúng trong khi website vẫn không truy cập được, vì lỗi xảy ra trong quá trình định tuyến, thiết lập kết nối, TLS, hoặc xử lý HTTP. Ngược lại, máy chủ web có thể vẫn hoạt động bình thường trong khi phía client không thể nhận được một câu trả lời DNS sử dụng được.

Những thành phần nào tham gia vào một truy vấn DNS?

Một truy vấn DNS thường liên quan đến một trình phân giải phía client, một trình phân giải đệ quy và các máy chủ có thẩm quyền chịu trách nhiệm cho không gian tên tương ứng. Mô hình đặt tên và phân giải DNS phân tán quyền quản lý thay vì yêu cầu một máy chủ trung tâm phải biết mọi bản ghi.

Thành phần phía client yêu cầu một trình phân giải đệ quy đã được cấu hình cung cấp câu trả lời. Trình phân giải đó có thể đã có sẵn thông tin sử dụng được trong bộ nhớ đệm của nó. Nếu không có, nó sẽ theo cấu trúc ủy quyền của DNS để tìm dữ liệu có thẩm quyền. Máy chủ có thẩm quyền công bố các bản ghi cho một zone; trình phân giải đệ quy thực hiện công việc tra cứu thay cho client.

Đây là các vai trò chứ không phải quy tắc rằng mọi cài đặt đều phải dùng các máy hoàn toàn tách biệt cho từng vai trò. Một tổ chức có thể chạy nhiều dịch vụ DNS, và một trình phân giải có thể chuyển tiếp yêu cầu tới một trình phân giải khác. Khi chẩn đoán một kết quả, hãy xác định thành phần nào thực sự đã trả lời và liệu câu trả lời đến từ dữ liệu có thẩm quyền hay từ bộ nhớ đệm.

Một truy vấn không có sẵn trong bộ nhớ đệm tìm câu trả lời như thế nào?

Một truy vấn chưa được lưu đệm sẽ theo các giới thiệu (referral) qua không gian tên cho đến khi trình phân giải đến được các máy chủ có thể trả lời cho tên được yêu cầu. Một truy vấn địa chỉ được đơn giản hóa bắt đầu với thông tin về root, đi qua tên miền cấp cao tương ứng, và đến các máy chủ có thẩm quyền cho tên miền đó.

1. Ứng dụng yêu cầu một bản ghi gắn với một hostname.
2. Trình phân giải đệ quy kiểm tra thông tin cục bộ và bộ nhớ đệm hiện có.
3. Nếu cần thiết, trình phân giải sẽ hỏi các máy chủ trong hệ phân cấp ủy quyền xem nên tiếp tục ở đâu.
4. Dịch vụ có thẩm quyền trả về bản ghi được yêu cầu, một bí danh, hoặc một phản hồi âm hoặc lỗi phù hợp.
5. Trình phân giải trả kết quả cho client và lưu đệm thông tin đủ điều kiện trong thời gian sống tương ứng.

Chuỗi bước này là một đường đi về mặt khái niệm, không phải khẳng định rằng mọi truy vấn đều liên hệ với mọi tầng. Các giới thiệu được lưu đệm có thể rút ngắn đường đi. Một bí danh có thể đòi hỏi phân giải bổ sung, và một cấu hình cục bộ có thể cung cấp câu trả lời mà không cần đi qua DNS công khai. Những khác biệt đó là hệ quả bình thường của thiết kế phân tán.

DNS phân giải hostname, không phải toàn bộ đường dẫn trang web. Đường dẫn sau hostname thuộc về yêu cầu HTTP tiếp theo. Thay đổi một đường dẫn trên cùng một host không tự thân đòi hỏi một truy vấn DNS có thẩm quyền mới cho đường dẫn đó.

Các bản ghi DNS phổ biến có ý nghĩa gì?

Các loại bản ghi DNS mô tả những kiểu dữ liệu khác nhau, nên loại được yêu cầu là một phần của câu hỏi. Một truy vấn địa chỉ và một truy vấn định tuyến thư có thể hỏi cùng một tên miền trong khi yêu cầu các bản ghi khác nhau.

Một câu trả lời có thể chứa nhiều địa chỉ. Ứng dụng quyết định cách sử dụng các địa chỉ sẵn có theo hành vi kết nối của chúng. DNS không bảo đảm rằng mọi địa chỉ đều đại diện cho cùng một máy chủ vật lý, và tập địa chỉ trả về có thể thay đổi theo cấu hình dịch vụ hoặc ngữ cảnh của trình phân giải.

Tại sao các thay đổi DNS mất thời gian mới xuất hiện?

Các thay đổi DNS có thể xuất hiện vào các thời điểm khác nhau vì các trình phân giải giữ lại các bản ghi được lưu đệm trong một khoảng thời gian cho phép. Thời gian sống của một bản ghi, hay TTL, cho bộ nhớ đệm biết thông tin có thể được tái sử dụng trong bao lâu theo hành vi lưu đệm thông thường. Cập nhật dữ liệu có thẩm quyền không trực tiếp xóa mọi bản sao đã được lưu đệm.

Giảm TTL sau khi công bố một thay đổi không rút ngắn hồi tố một bản sao đã được lưu đệm với thời gian sống cũ. Đối với một đợt chuyển đổi có kế hoạch, quản trị viên cần tính đến các giá trị cũ trước khi trông đợi một quá trình chuyển nhanh hơn. Các ứng dụng client và hệ điều hành cục bộ cũng có thể giữ lại thông tin trong hành vi phân giải riêng của chúng.

Các câu trả lời âm cũng có thể được lưu đệm. The Quy tắc lưu đệm âm DNS giải thích cách thông tin về sự vắng mặt có thể tồn tại lâu. Vì vậy, việc tạo một bản ghi trước đây bị thiếu không đảm bảo rằng mọi client ngay lập tức ngừng thấy kết quả âm trước đó.

Mô tả chính xác các quan sát trong quá trình thay đổi. Ghi lại resolver nào đã trả lời, loại bản ghi nào được truy vấn và giá trị nào được trả về. Nói rằng DNS vẫn đang truyền tải có thể che giấu một bản ghi uy quyền sai, một resolver không mong đợi hoặc một ứng dụng đang tái sử dụng một kết nối hiện có.

DNSSEC và DNS được mã hóa bảo vệ điều gì

DNSSEC xác thực dữ liệu DNS thông qua chữ ký, trong khi các phương thức truyền DNS được mã hóa bảo vệ đường truyền giao tiếp tới resolver. Những cơ chế này xử lý các mối đe dọa khác nhau. Một câu trả lời đã ký không tự động biến truy vấn thành riêng tư, và một truy vấn được mã hóa không tự động là bằng chứng rằng dữ liệu DNS bên dưới đã được ký.

Mô hình bảo mật DNSSEC bổ sung xác thực nguồn gốc và bảo vệ tính toàn vẹn cho dữ liệu DNS. Nó không mã hóa nội dung bản ghi. Việc xác thực cũng phụ thuộc vào chuỗi tin cậy và hành vi xác thực của resolver.

DNS over HTTPS truyền tải các thông điệp DNS qua HTTPS. Điều đó thay đổi cách client giao tiếp với resolver đã chọn. Resolver vẫn nhận truy vấn và kết nối web cuối cùng của ứng dụng vẫn là một tương tác riêng biệt với các thuộc tính bảo mật riêng của nó.

Đối với một nhà vận hành ứng dụng, câu hỏi thực tế là resolver nào được tin cậy và đường đi nào mang truy vấn. Hãy kiểm tra môi trường vận hành, cài đặt trình duyệt và bất kỳ hành vi proxy nào. Tránh suy diễn đường đi DNS chỉ từ việc URL đích bắt đầu bằng HTTPS.

DNS được phân giải ở đâu khi dùng Proxy?

Hành vi DNS của proxy phụ thuộc vào client, giao thức proxy và cấu hình yêu cầu. Một số cách bố trí phân giải đích cục bộ; số khác chuyển tiếp hostname tới proxy để phân giải từ xa. Bản thân cổng proxy vẫn có thể cần một tra cứu cục bộ trước khi client có thể truy cập tới đó.

Đối với một đường hầm proxy HTTP, client có thể yêu cầu proxy kết nối tới host và cổng đích. Với SOCKS, client có thể chuyển các dạng địa chỉ đích khác nhau tùy theo cấu hình. Do đó, khẳng định rằng mọi lưu lượng proxy đều dùng DNS từ xa sẽ là quá rộng.

Cấu hình xác thực và endpoint Scrapeless hiện tại xác định thiết lập kết nối tới gateway. Hãy phân biệt hostname của gateway với hostname đích khi kiểm tra một lỗi. Lỗi cục bộ khi phân giải gateway xảy ra trước khi proxy có thể làm bất cứ điều gì với đích.

Giải pháp Proxy Scrapeless cung cấp tuyến trung gian cho các ứng dụng tự kiểm soát logic yêu cầu của mình. Phần thảo luận về kiến trúc cloud proxy liên quan giúp tách kết nối hướng client khỏi kết nối hướng đích. Đánh giá hành vi của sản phẩm đã chọn và giá cùng nhau khi lập kế hoạch kiểm tra theo khu vực.

Cách chẩn đoán có phương pháp một sự cố DNS

Một chẩn đoán DNS hữu ích bắt đầu từ chính xác hostname, loại bản ghi, resolver và phản hồi quan sát được. Kiểm tra xem lỗi là tên thiếu, loại bản ghi thiếu, phản hồi lỗi từ phía server hay không thể liên hệ với resolver. Những kết quả này chỉ tới các nguyên nhân khác nhau.

So sánh ngữ cảnh của ứng dụng với ngữ cảnh chẩn đoán. Một công cụ terminal có thể dùng đường đi resolver khác với một trình duyệt đã bật DNS được mã hóa. Một tiến trình bên trong container có thể có cấu hình resolver khác với hệ điều hành host. Một câu trả lời có vẻ mâu thuẫn có thể được giải thích bởi những khác biệt môi trường đó.

Nếu phân giải thành công, hãy chuyển sang giai đoạn tiếp theo thay vì tiếp tục chỉnh DNS. Kiểm tra xem địa chỉ trả về có truy cập được không, danh tính TLS mong đợi có được trình bày không và phản hồi HTTP có thuộc về ứng dụng dự định hay không. Thay hostname bằng địa chỉ IP không phải là một cách sửa chung, vì danh tính HTTPS và virtual hosting phụ thuộc vào hostname.

Giữ các quan sát tách biệt với kết luận. Khác biệt địa chỉ không tự động chỉ ra tấn công hay lỗi. Một dịch vụ có thể cố ý trả về các địa chỉ khác nhau dựa trên ngữ cảnh resolver hoặc triển khai. Xác nhận cấu hình uy quyền và hành vi dịch vụ dự định trước khi thay đổi nó.

Cách DNS ảnh hưởng tới việc thu thập dữ liệu theo khu vực

DNS có thể ảnh hưởng đến việc endpoint dịch vụ nào nhận được yêu cầu, nhưng một mình DNS không quyết định toàn bộ trải nghiệm khu vực. Đích đến cũng có thể sử dụng địa chỉ nguồn của kết nối, cookie, cài đặt tài khoản hoặc ưu tiên ngôn ngữ.

Đối với một so sánh giả định về các trang sản phẩm công khai, hãy gắn thị trường dự định và ngữ cảnh thu thập với từng quan sát. Nếu một lần chạy dùng resolver cục bộ và lần khác dùng phân giải phía proxy, hãy ghi lại sự khác biệt đó khi điều tra nội dung thay đổi. Đừng cho rằng nó giải thích sự thay đổi mà không kiểm tra trang trả về.

Kết luận

DNS định vị các bản ghi thông qua ủy quyền phân cấp và lưu đệm. Hãy chẩn đoán nó như một giai đoạn riêng trong đường đi yêu cầu: xác định resolver, kiểm tra câu trả lời, rồi tách biệt kiểm tra kết nối và hành vi ứng dụng. Khi có proxy tham gia, hãy xác định mỗi hostname được phân giải ở đâu trước khi diễn giải kết quả.