Delegation bit-rot detection?

[Fr34k]

We are exploring similar audits and opportunities for cleanup.

For domains we delegate PTRs, we track NS hostnames (e.g. IN NS  ns1.bogus.customer.tld) that have gone NXDOMAIN.

If ns1.bogus.customer.tld remains NXDOMAIN for 30+ days, we remove the delegation.
The idea behind 30+ days is to allow for a grace period.  Why?  If the domain expired and caught the owner by surprise, then 30 days allows time for the domain owner to renew before we make any changes (so that we do not waste time removing the delegation to only have to reinstate it).

Perhaps a similar approach be worthwhile for auditing the secondary services.  That is, parse BIND's config file (source of truth) for all secondary configs, run dedicated auditing tests (e.g. AXFR), record the outcomes, and act upon the defunct configurations per Policy.

All that said, I am also interested in what others are doing.  I am sure there are better methods out there.

Thanks.




>________________________________
> From: Phil Mayers <p.mayers at imperial.ac.uk>
>To: "bind-users at lists.isc.org" <bind-users at lists.isc.org> 
>Sent: Thursday, June 14, 2012 9:19 AM
>Subject: Delegation bit-rot detection?
> 
>All,
>
>Over the years, we have offered DNS secondary services to various organisations. Some of those organisations are (ahem) fairly small, and lots of the delegations and zone transfers have suffered bit-rot - there are zones delegated to us that I have no records on, and certainly can't AXFR from the masters (in some cases, the masters answer REFUSED as well).
>
>I'm wondering if anyone knows of a script that will process our logs looking for "refused" queries, and then post-process these by tracing the delegations and telling me what the nearest enclosing zone is, the NS records that led inbound queries to us, and (if any of the other NS records are responding) the SOA.
>
>I could write something, but there are a lot of corner cases, and I'm feeling lazy!
>
>OTOH if anyone has any suggestions (other than "ignore the refused", which is what we're currently doing) for dealing with these kinds of things...
>
>Cheers,
>Phil
>_______________________________________________
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
>bind-users mailing list
>bind-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120614/11717911/attachment.html>