Isso é velho, mas vou dar algumas sugestões.
As I understand it until that date stays at least 14 days in the past nothing will ever even be eligible for scavenging let alone actually be scavenged.
Eu não penso assim. A configuração parece correta e os registros devem ser eliminados. Três coisas necessárias são a limpeza definida para a zona, em um servidor DNS e em registros de recursos com um registro de data e hora.
Coisas óbvias primeiro - verifique a segurança dos registros de recursos. Os controladores de domínio do sistema e corporativo geralmente têm controle total. E não negar entradas.
Eu verificaria a versão do dns.exe para garantir que ela esteja atualizada. Tanto o R1 quanto o R2 de 2008 tiveram erros com a forma como os registros DNS são eliminados e eliminados.
Windows Server 2008 R1: 6.0.6002.23387
link
Windows Server 2008 R2: 6.1.7601.22893
link
Estou assumindo que a zona é integrada ao AD. Em caso afirmativo, dnscmd.exe / zoneinfo zoneName informa um tipo de partição de diretório do AD-Domain (ou AD-Forest) 99,999% do tempo. Eu vi zonas onde a partição foi alterada para outra coisa, em seguida, mudou de volta e algo deu errado durante esse processo, ou não foi nenhum dos valores esperados desde o início devido a como o controlador de domínio foi provisionado ou nem todos os controladores de domínio relatou o mesmo tipo de partição.
Verifique o atributo fsmoRoleOwner no ADSIEdit para a partição DC = DomainDNSZones, DC = domain, DC = com. DomainDNSZones e ForestDNSZones têm o sexto / sétimo proprietários de função fsmo. Se já houve algum dano no passado e um controlador de domínio anterior que possuía a partição não existe mais, o atributo fsmoRoleOwner conteria 0ADel: e o GUID do controlador de domínio anterior. Mais informações sobre como corrigir isso aqui:
Outra situação que pode interferir na operação normal é a duplicação de zonas. Ace Fekay tem um excelente artigo aqui: