Khu vực này có thể được quét sạch sau khi liên tục tăng


10

Bạn đang cố làm gì vậy?

Tôi đang cố gắng kích hoạt tính năng quét DNS trên vùng DNS có khoảng một trăm bản ghi DNS cũ.

Bạn đã cố gắng để làm cho nó xảy ra?

Tôi thiết lập Quét rác DNS theo bài đăng trên Blog TechNet yêu thích của mọi người: Đừng sợ việc nhặt rác DNS. Chỉ cần kiên nhẫn.

Lần đầu tiên tôi vô hiệu hóa việc nhặt rác trên tất cả các bộ điều khiển miền của chúng tôi:

DNSCmd . /ZoneResetScavengeServers contoso.com 192.168.1.1 192.168.1.2


Sau đó tôi đã bật chức năng nhặt rác tự động trên vùng DNS:

Thuộc tính lão hóa / nhặt rác


Sau đó tôi đã kích hoạt tính năng quét DNS trên một trong các bộ điều khiển miền:

Máy chủ DNS toàn cầu


Sau đó tôi đã tìm thấy một vài bản ghi mà tôi dự kiến ​​sẽ xóa bằng Delete this record when it becomes staledấu thời gian từ một vài năm trước và đảm bảo rằng dấu ấn thời gian và thực sự đã được thiết lập:

Thuộc tính bản ghi DNS


Cuối cùng tôi tải lại khu vực và chờ 14 ngày (tổng thời gian Làm mới + Không làm mới).

Kết quả bạn mong đợi là gì?

Tôi dự kiến ​​sẽ thấy một sự kiện 2501 trong máy chủ DNS ghi lại việc xóa một loạt các bản ghi DNS.

Điều gì thực sự đã xảy ra?

Không có chuyện gì xảy ra. Thuộc tính Lão hóa / Quét khu vực cho thấy rằng khu vực này có thể được quét sau ngày 6/12/2014 10:00:00 SA tuần trước. Không có 2501/2502 sự kiện được ghi lại. Tất cả các hồ sơ có dấu thời gian "già" vẫn còn hiện diện.

Ngày mà khu vực có thể được nhặt rác sau khi tăng thêm bảy ngày nữa vào ngày 18/12/2014 10:00:00 AM.

Theo tôi hiểu cho đến ngày đó vẫn còn ít nhất 14 ngày trong quá khứ, thậm chí sẽ không bao giờ đủ điều kiện để nhặt rác chứ đừng nói đến việc thực sự được nhặt rác.

2501 sự kiện duy nhất được ghi lại trong nhật ký sự kiện là những sự kiện mà tôi đã kích hoạt bằng cách nhấp chuột phải và chọn "Scavenge Stale Resource Records". Họ lưu ý rằng việc nhặt rác sẽ cố gắng chạy lại sau 168 giờ sáng nay.

Tôi đã bật chức năng quét DNS trong một vài tháng và kiên nhẫn chờ đợi điều gì đó xảy ra. Tôi đã tải lại vùng nhiều lần (đặt lại dấu thời gian này).

Tôi đang thiếu gì ở đây?


Cứ bảy ngày nên có một sự kiện 2501/2502 vì đó là khoảng thời gian nhặt rác bạn đã đặt. Ít nhất 2502 nói rằng không có hồ sơ nào được quét và nếu mọi thứ đang hoạt động thì 2501 nói rằng một số hồ sơ đã được quét. Vì một số lý do, nhiệm vụ đó dường như không chạy.
Brian

2
Lệnh này: DNSCmd . /ZoneResetScavengeServers contoso.com 192.168.1.1 192.168.1.2không nhất thiết phải vô hiệu hóa việc nhặt rác cho tất cả các DC của bạn. Nó cho phép nhặt rác cho 192.168.1.1 và 192.168.1.2. Là một trong những địa chỉ đang chạy DNS? Khi bạn nói rằng bạn đã kích hoạt tính năng quét trên một trong các bộ điều khiển miền, bạn đã hiển thị ảnh chụp màn hình của cài đặt trong DNS. Nhưng hãy lưu ý rằng cài đặt đó và lệnh này đang đặt 2 thứ khác nhau. Bạn cần chạy lại lệnh này với địa chỉ IP của DC đó. Bạn đã làm điều đó?
briantist

Câu trả lời:


1

Điều này là cũ, nhưng tôi sẽ đưa ra một vài gợi ý.

Theo tôi hiểu cho đến ngày đó vẫn còn ít nhất 14 ngày trong quá khứ, thậm chí sẽ không bao giờ đủ điều kiện để nhặt rác chứ đừng nói đến việc thực sự được nhặt rác.

Tôi không nghĩ vậy. Các thiết lập âm thanh chính xác và các hồ sơ nên được quét. Ba điều cần thiết là nhặt rác được đặt cho vùng, trên máy chủ DNS và trên các bản ghi tài nguyên với dấu thời gian.

Công cụ rõ ràng đầu tiên - kiểm tra tính bảo mật của các hồ sơ tài nguyên. Bộ kiểm soát miền hệ thống và doanh nghiệp thường có toàn quyền kiểm soát. Và không có mục từ chối.

Tôi sẽ kiểm tra phiên bản của dns.exe để đảm bảo nó được cập nhật. Cả năm 2008 R1 và R2 đều có lỗi với cách các bản ghi DNS bị giật và nhặt rác.

Máy chủ Windows 2008 R1: 6.0.6002.23387
https://support.microsoft.com/en-us/kb/2962612

Máy chủ Windows 2008 R2: 6.1.7601.22893
https://support.microsoft.com/en-us/kb/3022780

Tôi giả sử khu vực này được tích hợp AD. Nếu vậy, dnscmd.exe / zoneinfo zoneName báo cáo một loại phân vùng thư mục của AD-Domain (hoặc AD-Forest) 99,999% thời gian. Tôi đã thấy các khu vực nơi phân vùng đã được thay đổi thành một thứ khác, sau đó thay đổi lại và đã xảy ra sự cố trong quá trình đó hoặc không có giá trị nào được mong đợi từ đầu do cách bộ điều khiển miền được cung cấp hoặc không phải tất cả các bộ điều khiển miền báo cáo cùng loại phân vùng.

Kiểm tra thuộc tính fsmoRoleOwner trong ADSIEdit để biết phân vùng DC = DomainDNSZones, DC = domain, DC = com. DomainDNSZones và ForestDNSZones có chủ sở hữu vai trò fsmo thứ sáu / thứ bảy. Nếu có một số thiệt hại trong quá khứ và bộ điều khiển miền trước đó sở hữu phân vùng không còn tồn tại, thuộc tính fsmoRoleOwner sẽ chứa 0ADel: và hướng dẫn của bộ điều khiển miền trước đó. Thông tin thêm về sửa lỗi ở đây:

http://bloss.technet.com/b/the_9z_by_chris_davis/archive/2011/12/20/forestdnszones-or-domaindnszones-fsmo-says-the-role-owner-attribution-could-not-be-read.asp

Một tình huống khác có thể can thiệp vào hoạt động bình thường là các vùng trùng lặp. Ace Fekay có một bài viết tuyệt vời ở đây:

http://bloss.msmvps.com/acefekay/2009/09/02/USE-adsi-edit-to-resolve-conflicting-or-d repeatate-ad-integrated-dns-zones /


0

Tôi với briantist về điều này. Bạn cũng có thể xem trợ giúp tại đây: http://support.microsoft.com/kb/2791165

Trước tiên ... hãy chắc chắn rằng bạn ĐÁNG TIN CẬY khu vực DNS ... sau đó ... về cơ bản bạn muốn đảm bảo rằng các DC bạn đang cho phép nhặt rác bằng DNSCmd là những nơi bạn có DNS đang chạy. Theo dõi bài viết KB đó vào thời điểm này nếu bạn vẫn gặp sự cố vì câu hỏi đã cũ. Điều đó cùng với blog Technet của bạn sẽ giúp bạn đi đúng hướng. Nếu bạn đã giải quyết theo cách này thì sẽ rất hữu ích nếu bạn đăng câu trả lời ở đây!

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.