Delegation bit-rot detection?

[Frank Bulk]

For the domains that we're primary and authoritative we check the listing of
each customer's WHOIS record to confirm they're using the right DNS servers
and then query our upstream's DNS server (which is slaving it) to make sure
they're responding authoritatively.  We also query a public DNS server to
make sure the NS records that it returns for the domain are the right DNS
servers.

 

This has caught countless customers who let their domain registrations
expire or whose third-party website developer moved DNS records to their
preferred website host.  I can't tell you how many times SMB/SME customers
think that their DNS records need to reside with the company that hosts or
manages their website.  

 

If a customer lets their domain expire and does not respond in a few days to
our outreach we just remove the domain.  No reason to give our customers
different information than the rest of the world (yes, our recursive and
authoritative somewhat overlap).

 

Frank

 

From: bind-users-bounces+frnkblk=iname.com at lists.isc.org
[mailto:bind-users-bounces+frnkblk=iname.com at lists.isc.org] On Behalf Of
Fr34k
Sent: Thursday, June 14, 2012 8:54 AM
To: Phil Mayers; bind-users at lists.isc.org
Subject: Re: Delegation bit-rot detection?

 

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/5053d6b0/attachment.html>