BIND nô lệ không đồng bộ hóa với chủ cho đến khi nó được khởi động lại

Tôi có hai máy chủ DNS chạy BIND9, một chủ và một nô lệ. Khi tệp vùng được cập nhật trên bản gốc, tôi muốn máy chủ nô lệ ngay lập tức bắt đầu phục vụ (các) bản ghi đã thay đổi, nhưng BIND đang cung cấp cho tôi một số guff.

Chuyển vùng DNS đã hoạt động chính xác giữa chủ và nô lệ. Tôi có thể đăng nhập vào máy chủ nô lệ và chạy dig @dnsmaster myzone. AXFRvà nó in ra toàn bộ nội dung của khu vực. Để thực hiện công việc đó, DNS master được cấu hình với notify yesvà also-notify { dnsslave }. Tương tự như vậy, nô lệ được cấu hình với allow-transfer { dnsmaster }.

Khi dnsmaster được cập nhật, tôi chạy rndc reloadvà nó cho tôi biết rằng các thông báo đang được gửi. Điều này được xác nhận trên nô lệ bằng cách kiểm tra các vùng dữ liệu trong /var/named/slavedata/. Chúng chứa dữ liệu gần đây nhất, khớp với những gì chủ nhân biết.

Bây giờ đến phần kỳ lạ.

Máy chủ nô lệ sẽ tiếp tục cung cấp các bản ghi DNS cũ, cũ, hoàn toàn bỏ qua thực tế là dữ liệu mới có sẵn trên đĩa sau khi được chủ thông báo. Tôi đang sử dụng digđể kiểm tra kết quả với lệnh này : dig @slaveserver record.zone.tld.

Tôi nghĩ rằng BIND có thể giữ bộ đệm trong bộ nhớ trong các vùng có thẩm quyền của nó, vì vậy tôi đã đặt max-cache-sizevà max-cache-ttlvề 0, nhưng điều đó không có hiệu lực.

Tôi đã thử các cách khác để xóa bộ nhớ cache bị cáo buộc này, bằng cách chạy các lệnh như rndc flushvà rndc reloadtrên máy chủ nô lệ, nhưng nó vẫn trả về các bản ghi cũ.

Cuối cùng, tôi nhận thấy rằng MINTTLtrên vùng được đặt thành 86400 (24 giờ), vì vậy tôi tạm thời thay đổi MINTTLthành 15 giây và khởi động lại máy chủ nô lệ. Không có hiệu lực - nô lệ sẽ chỉ cung cấp kết quả DNS được cập nhật sau khi dịch vụ được khởi động lại.

Những gì đang xảy ra ở đây? Hành vi dự kiến ​​của BIND9 khi nhận được thông báo rằng một khu vực được cập nhật là gì? Có phải nó luôn tôn trọng TTLvà MINTTL? Tôi cho rằng nó sẽ luôn sử dụng dữ liệu gần đây nhất có sẵn.

Cuối cùng, tôi đang xem xét việc thiết lập một crontab để khởi động lại nô lệ BIND trên cơ sở hàng giờ, chỉ để tránh phục vụ dữ liệu cũ. Có gì tốt hơn không?

Từ mô tả của bạn, tôi không thể nói cho bạn biết chính xác vấn đề là gì nhưng tôi có thể giúp bạn loại trừ một số điều.

Cài đặt kích thước bộ đệm và cài đặt ttl bộ đệm dành cho dữ liệu truy vấn đệ quy được lưu trong bộ nhớ cache và (như bạn đã nghi ngờ) không áp dụng cho dữ liệu có thẩm quyền. Tương tự như vậy rndc tuôn ra là không thể áp dụng ở đây.

Đề xuất phương pháp khắc phục sự cố:

1. Xác nhận rằng các tin nhắn thông báo đang được gửi bởi chủ như mong đợi. Kiểm tra nhật ký và / hoặc đánh hơi lưu lượng giữa chủ và nô lệ.
2. Xác minh từ nhật ký rằng tin nhắn thông báo đang được nô lệ nhận.
3. Nếu bạn không thể thấy nô lệ nhận được thông báo, hãy khắc phục sự cố như một vấn đề thông báo, tức là kiểm tra kỹ các tùy chọn thông báo của bạn trong tên. Tôi khuyên bạn nên sử dụng "thông báo rõ ràng;" với "cũng-notify {Slave-server;};"
4. Nếu nô lệ được nhìn thấy các thông báo, vấn đề của bạn là tìm hiểu xem tại sao khu tập tin không được cập nhật như bạn mong đợi. Điều gì sẽ xảy ra là sau khi nhận được thông báo, nô lệ sẽ tạo một truy vấn SOA, so sánh với SOA hiện tại của nó và thực hiện một AXFR (hoặc IXFR nếu bạn đã kích hoạt nó) để có được bản sao vùng cập nhật (giả sử SOA trên bản gốc cao hơn.) Bạn sẽ có thể quan sát tất cả những điều này xảy ra với một trình thám thính và bạn cũng sẽ thấy bằng chứng về nó trong nhật ký trên cả hai máy chủ.
5. Nếu các hoạt động không diễn ra như bạn mong đợi, hãy bắt đầu bằng cách so sánh thủ công các số sê-ri SOA trên hai máy chủ (dig @server $ zonename SOA) để đảm bảo rằng bạn đã không vô tình cung cấp cho nô lệ một số sê-ri cao hơn mong đợi trong quá khứ bây giờ cao hơn số sê-ri của chủ.

Nếu điều đó không hiệu quả, hãy xem xét đăng thêm thông tin, bao gồm các phần có tên từ cả chủ và nô lệ và nhật ký từ cả hai máy chủ của những gì đang xảy ra sau khi bạn tải một vùng được chỉnh sửa mới trên bản gốc.

Tôi đã đối mặt với tình huống tương tự. Nghiên cứu của tôi đã dẫn tôi đến nhận thức sau đây. Nếu bạn đang sử dụng chế độ xem, thì máy đào @ local sẽ chỉ phục vụ những gì trong chế độ xem localhost. Chế độ xem localhost chỉ được làm mới trong khi khởi động lại tên. Nhưng tệp vùng mới nhất (được chuyển từ bản gốc) vẫn có sẵn trên Slave và sẽ được phục vụ cho tất cả các truy vấn đến từ các nguồn bên ngoài hoặc các khung nhìn bên ngoài. Vì vậy, bạn cần sắp xếp sao cho chế độ xem localhost của bạn được làm mới.

Xin đừng quên tăng id nối tiếp từ các tệp vùng khi bạn thực hiện thay đổi trong Máy chủ chính trước khi tải lại tên, nếu không các tệp vùng sẽ không được sao chép sang Máy chủ Slave.