Hai site, một vùng DNS riêng: ai sở hữu các bản ghi?

Bạn thêm một máy chủ ở site xanh, nó phân giải cho người dùng xanh, và văn phòng vàng vẫn nhận NXDOMAIN. Đây không phải lỗi VPN và cũng không phải trình phân giải hỏng; đây là khoảng trống quyền sở hữu trong vùng riêng. Hai danh sách bản ghi được sửa độc lập không trở thành một vùng chỉ vì các site có thể chạm tới nhau. Giải pháp là một kế hoạch xuất bản, không phải thêm một quy tắc tường lửa.

Triệu chứng gọi tên chủ sở hữu còn thiếu

Mỗi site có lẽ có một ghi đè cục bộ, một mục Pi-hole hoặc một dòng dnsmasq mà ai đó thêm khi cần một cái tên. Bản ghi xanh chỉ tồn tại trên trình phân giải xanh, nên một máy khách ở site vàng hỏi trình phân giải của chính nó và nhận một "không có tên đó" trung thực. Một câu trả lời cũ trông khác: máy chủ đã chuyển đi, một site cập nhật bản sao của mình, và site kia vẫn trả về địa chỉ cũ.

Không mẫu nào được sửa lâu dài bằng cách xóa bộ nhớ đệm. Bộ nhớ đệm của trình phân giải chuyển tiếp là bản sao của một câu trả lời từng nhận, không phải thẩm quyền công bố tên mới, nên một bộ nhớ đệm chạy hôm nay không nói gì về máy chủ ngày mai. Tài liệu BIND mô tả riêng các vai trò sơ cấp, thứ cấp, đệ quy và chuyển tiếp chính vì lý do này.

Vậy câu hỏi thiết kế hẹp và có thể trả lời: ai được tạo bản ghi, và bản ghi đó đến được mọi trình phân giải phải trả lời cho nó bằng cách nào?

Phương án A: một vùng có thẩm quyền với các máy chủ thứ cấp

Chạy một sơ cấp cho internal.example.com và để các thứ cấp được hỗ trợ lấy vùng tại mỗi site. Trình phân giải đệ quy của mỗi site hỏi thứ cấp cục bộ của nó, nên câu trả lời đến từ một nguồn có thẩm quyền chứ không phải bộ nhớ đệm, và một thay đổi làm một lần được chuyển đi thay vì gõ lại.

Cách bố trí đó cần những quyết định rõ ràng, dễ trì hoãn và đắt nếu bỏ qua. Ai được sửa vùng? Những máy chủ nào được phép chuyển nó, và qua những địa chỉ nào? Khách hàng nên thấy gì khi đường hầm giữa các site đang ngừng? Một thứ cấp tiếp tục trả lời từ bản sao cuối cùng của nó, thường là hành vi mong muốn, nhưng đó phải là lựa chọn được tuyên bố chứ không phải bất ngờ khi có sự cố.

Giới hạn chuyển vùng cho các thứ cấp đã biết theo địa chỉ và dùng chữ ký giao dịch ở nơi bản triển khai hỗ trợ. Một lần chuyển mở là bản sao không gian tên nội bộ của bạn cho bất kỳ ai chạm tới cổng.

Cái giá là phối hợp: một đường sửa, một lần duyệt thay đổi, và hiểu biết chung về ai trực khi một bản ghi sai.

Phương án B: một tên miền con cho mỗi site

Ủy quyền green.internal.example.com cho site xanh và yellow.internal.example.com cho site vàng. Mỗi site trở thành có thẩm quyền cho tên của chính nó, và vùng cha chỉ mang các bản ghi ủy quyền. Tranh chấp về một tệp biến mất, và một nhóm cục bộ có thể thêm máy chủ mà không chờ thay đổi trung tâm.

Ủy quyền phải tồn tại trong vùng cha, với các bản ghi NS trỏ tới máy chủ có thẩm quyền của site. Chuyển tiếp có điều kiện cho tên miền con là phương án thay thế hợp lệ khi ủy quyền đầy đủ không thực tế, nhưng đó là cài đặt trình phân giải chứ không phải sự thật được công bố, nên mọi trình phân giải cần cùng một quy tắc.

Cái giá di chuyển thay vì biến mất: vùng cha vẫn cần một chủ sở hữu, và tạo một site mới giờ là thay đổi ở hai nơi thay vì một.

Hãy để mọi trình phân giải theo lựa chọn

Cung cấp cho khách hàng trình phân giải đã được phê duyệt và miền tìm kiếm thông qua cấu hình được hỗ trợ, và bảo đảm rằng trình phân giải có tuyến VPN được phép tới bất kỳ máy chủ DNS từ xa nào nó phải truy vấn. Ứng dụng cũng cần tuyến tới các địa chỉ riêng mà những câu trả lời đó trả về, vì một tên đúng mà không có đường đi vẫn là kết nối bị đứt.

Nếu Pi-hole cung cấp phân giải cục bộ, hãy ghi lại nó sở hữu những bản ghi nào và chuyển tiếp những truy vấn nào. Hai danh sách Pi-hole được sửa độc lập vẫn không sao chép. Trong Pi-hole v6, các dòng dnsmasq tùy chỉnh được đặt qua tùy chọn phía máy chủ như TOML, CLI hoặc biến môi trường và không được công bố qua API; nạp các tệp từ /etc/dnsmasq.d/ là một tùy chọn riêng bị tắt theo mặc định.

Sau đó kiểm tra từ cả hai phía với một cái tên đáng lẽ phải thấy ở mọi nơi:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

Câu trả lời SOA cho bạn biết trình phân giải vàng tự coi mình có thẩm quyền, đang hỏi một thứ cấp, hay chỉ chuyển tiếp. Đó là những thiết kế khác nhau với kiểu hỏng khác nhau, và câu trả lời thường chỉ ra cái bạn thực sự đã triển khai.

Kết thúc bằng ba trường hợp chấp nhận: một cái tên từ mỗi site, một bản ghi được thay đổi trong vòng một giờ, và liên kết giữa các site không khả dụng. Một thiết kế chỉ qua trường hợp đầu có kế hoạch xuất bản trên giấy và một ghi đè cục bộ trong môi trường thật.