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.may...@imperial.ac.uk>
>To: "bind-users@lists.isc.org" <bind-users@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@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to