BIND qua VPN: chuyển tiếp có điều kiện hay vùng stub?

Ba cách phân giải một vùng riêng qua VPN và khi nào mỗi cách phù hợp: forward, stub hay secondary, cùng phép kiểm tra địa chỉ nguồn quyết định.

Resolver văn phòng của bạn trả lời mọi thứ trừ một không gian tên doanh nghiệp, và máy chủ DNS doanh nghiệp biết không gian đó nằm sau một VPN. BIND có thể giao vùng duy nhất đó cho upstream theo ba cách khác nhau, và chúng hỏng theo cách khác nhau. Chuyển tiếp có điều kiện là cam kết nhỏ nhất, vùng stub giữ dữ liệu ủy quyền, và secondary giữ một bản sao đầy đủ. Hãy chọn theo điều upstream cho phép và điều bạn muốn resolver lưu giữ, chứ không theo đoạn mã bạn tìm thấy trước.

Ba cách bố trí cho một không gian tên

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Chuyển tiếp có điều kiện: cam kết nhỏ nhất

Giả sử resolver văn phòng ở 192.168.10.53 và máy chủ doanh nghiệp ở 10.40.0.53, truy cập được qua một đường hầm đã được phê duyệt. Khai báo gồm ba dòng, và dòng đáng chú ý là forward only, vì nó thay đổi hành vi khi lỗi chứ không phải đường đi.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Với forward only, upstream không tới được sẽ trả SERVFAIL cho vùng này thay vì quay về phân giải lặp. Đó thường là điều bạn muốn cho một không gian tên riêng, vì việc quay về sẽ gửi tên riêng tới một resolver công cộng và mang về một câu trả lời vô ích từ internet. Tài liệu tham chiếu BIND mô tả cả hai chính sách, và khác biệt quan trọng hơn đoạn mã gợi ý. Hãy gộp vùng vào cấu hình hiện có thay vì thay thế một vùng đã tồn tại cho cùng tên.

Stub hay secondary: khi ủy quyền quan trọng

Vùng stub hỏi máy chủ doanh nghiệp các bản ghi NS của vùng rồi sau đó hỏi trực tiếp các máy chủ có thẩm quyền. Chọn nó khi vùng upstream lớn hoặc bị chia nhỏ và bạn muốn resolver đi theo ủy quyền thay vì ghim mọi thứ vào một địa chỉ. Cái giá là phụ thuộc vào việc dữ liệu NS luôn mới và mọi máy chủ tên được liệt kê đều tới được từ địa chỉ nguồn của resolver.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary trả lời từ dữ liệu cục bộ và sống sót qua sự cố upstream, và đó là lý do chấp nhận phụ thuộc vào việc truyền vùng. Điều đó cũng có nghĩa resolver của bạn giờ giữ một bản sao của vùng mà nó không sở hữu, nên đường dẫn tệp, ACL truyền vùng trên máy chủ sơ cấp và các bộ đếm làm mới đều trở thành một phần bề mặt vận hành của bạn.

Phép kiểm tra quyết định giữa chúng

BIND tự tạo truy vấn đi ra của nó, nên câu hỏi không phải là máy tính xách tay có tới được 10.40.0.53 hay không, mà là máy chủ của resolver có tới được từ địa chỉ nguồn mà máy chủ doanh nghiệp sẽ thấy hay không. Hãy hỏi nhân trước, rồi hỏi máy chủ, theo thứ tự đó.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Cho phép UDP và TCP trên đường đi: một câu trả lời bị cắt buộc phải dùng TCP, và chính sách chỉ cho phép UDP tạo ra những lỗi chập chờn trông như mất gói. Phía doanh nghiệp cần cả quy tắc chấp nhận cho nguồn của resolver và tuyến quay lại nguồn đó; nguồn đó có thể là địa chỉ được định tuyến của resolver hoặc một địa chỉ được dịch tường minh, và hiếm khi là địa chỉ từ một nhóm máy khách. Nếu truy vấn NS thất bại, vùng stub không thể hoạt động, bất kể vùng forward hành xử thế nào.

Hãy kiểm chứng câu trả lời, không phải đường hầm

Truy vấn qua resolver văn phòng một cái tên bạn chưa từng hỏi, và xem phần authority của câu trả lời để biết nó đến từ vùng doanh nghiệp hay không. Một câu trả lời trong bộ nhớ đệm không chứng minh gì về đường đi hiện tại, và một truy vấn trực tiếp thành công tới upstream không chứng minh resolver của bạn đã chọn vùng đó. Lặp lại truy vấn đó qua TCP để xác nhận đường đi chịu được việc bị cắt.

Giữ máy khách hướng tới resolver văn phòng, và giữ bật xác thực DNSSEC. Một trình duyệt được cấu hình với resolver mã hoá độc lập sẽ bỏ qua toàn bộ cách bố trí này, và việc tắt xác thực để một câu trả lời bất thường trông có vẻ đúng đang đổi một lỗi nhìn thấy được lấy một lỗi không nhìn thấy được.

Hãy ghi lại bạn chọn loại nào trong ba loại và vì sao. Người tiếp theo nhìn thấy vùng hỏng sẽ cần câu đó hơn là tệp cấu hình.

Bài viết liên quan