<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Tahoma","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'>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.  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'>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).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'>Frank<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> bind-users-bounces+frnkblk=iname.com@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname.com@lists.isc.org] <b>On Behalf Of </b>Fr34k<br><b>Sent:</b> Thursday, June 14, 2012 8:54 AM<br><b>To:</b> Phil Mayers; bind-users@lists.isc.org<br><b>Subject:</b> Re: Delegation bit-rot detection?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='background:white'><span style='color:black'>We are exploring similar audits and opportunities for cleanup.<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'>For domains we delegate PTRs, we track NS hostnames (e.g. IN NS  ns1.bogus.customer.tld) that have gone NXDOMAIN.<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'>If ns1.bogus.customer.tld remains NXDOMAIN for 30+ days, we remove the delegation.<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'>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).<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'>All that said, I am also interested in what others are doing.  I am sure there are better methods out there.<o:p></o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal style='background:white'><span style='color:black'>Thanks.<o:p></o:p></span></p></div><div><blockquote style='border:none;border-left:solid #1010FF 1.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:3.75pt;margin-bottom:5.0pt'><p class=MsoNormal style='background:white'><span style='color:black'><o:p> </o:p></span></p><div><div><div><div class=MsoNormal align=center style='text-align:center;background:white'><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'><hr size=1 width="100%" align=center></span></div><p class=MsoNormal style='background:white'><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'>From:</span></b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black'> Phil Mayers <<a href="mailto:p.mayers@imperial.ac.uk">p.mayers@imperial.ac.uk</a>><br><b>To:</b> "<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>" <<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>> <br><b>Sent:</b> Thursday, June 14, 2012 9:19 AM<br><b>Subject:</b> Delegation bit-rot detection?</span><span style='color:black'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-bottom:12.0pt;background:white'><span style='color:black'><br>All,<br><br>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).<br><br>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.<br><br>I could write something, but there are a lot of corner cases, and I'm feeling lazy!<br><br>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...<br><br>Cheers,<br>Phil<br>_______________________________________________<br>Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br><br>bind-users mailing list<br><a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br><a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br><br><o:p></o:p></span></p></div></div></blockquote></div></div></div></body></html>