g, so I'm all in favour
> of that.
>
> The definition of "too old" differs on a per-domain basis. There are
> two values in the SOA record of a DNS domain; refresh and expire.
> The refresh value tells secondary servers how often to check in
> with the primary.
>
> The expire value tells secondary servers how long they should
> consider themselves valid for without successful contact with the
> primary. If there is no contact with the primary for the expire
> period then the secondary server stops serving the domain and
> returns SERVFAIL for every query.
>
> So, based on the above, a DNS domain should never be "older" than
> refresh. If it is older then that means that at least one refresh
> attempt failed. If the age approaches expire then the domain is in
> danger of not being served.
>
> At the moment I have decided to send a warning alert on 150% of
> refresh and a critical alert on 50% of expire.
>
> RIPE recommends 84600 (one day) for refresh and 3600000 (1000 hours;
> almost 6 weeks) for expire:
>
> http://www.ripe.net/ripe/docs/ripe-203
>
> RFC1912 (1996) recommends one day for refresh and 2-4 weeks for
> expire:
>
> http://www.faqs.org/rfcs/rfc1912.html
>
> So let's say you go with RIPE's recommendations. You'd receive
> a warning alert after your secondary DNS setup was broken for 36 hours,
> and you'd receive a critical alert if it was still broken after 500
> hours (almost 3 weeks). 500 hours after that, your domain stops
> being served on the secondary servers.
>
> That seems reasonable.
>
> Finally getting around to the point of this email: what do you think
> I should do about problematic SOA values that customers have chosen?
>
> For example, there are some domains currently on BitFolk's servers
> where the refresh and expire are both set to 300 seconds (5
> minutes). Ignoring what happens with alerts for a moment, that means
> that every 5 minutes the secondary servers check the primary, and if
> that fails even once, the domain will return SERVFAIL for all
> queries until contact is made again.
>
> I can't understand what the use is of such a fragile setting; it
> looks erroneous to me. This isn't just DNS purism saying, "ooh, I
> don't like your non-standard values!" It will actually cause
> breakage very easily. But perhaps it is not for me to reason why.
>
> Those domains have been like that for a long time and I assume no
> one has noticed. It must have caused some problems any time the
> primary nameserver was unreachable by the secondary servers. But
> arguably that is not my problem.
>
> When combined with this new alerting though, what happens is that
> there isn't a refresh for 5 minutes then 2.5 minutes into that a
> critical alert fires since we're half way to expire (5 minutes). All
> being well there should be a recovery ~2.5 mins later. In reality
> these times will be variable because BitFolk's Nagios doesn't check
> DNS every few minutes, more like an hour plus.
>
> That is the most extreme example of this problem, but there are a few
> other domains in there where refresh and expire have been set to the
> same value. It will lead to a cycle of alert and then recovery,
> forever.
>
> So, what do you think I should do?
>
> I'm not willing to give up on the alerts because I think most people
> would like to know when their DNS setup is broken (or in danger of
> being broken), and it saves me having to personally interact to tell
> people this. Intentional DNS breakage is not my problem, but
> answering/opening support tickets is.
>
> Alerting can be disabled on a per-domain basis. Currently only by
> asking support, but eventually you'll be able to flip that on the
> Panel=C2=B9.
>
> So how about have Panel warn on the web page about what are
> considered unwise SOA values, and just allow the alerts to be
> disabled if for some reason this sort of fragile DNS setup is
> intentional?
>
> Cheers,
> Andy
>
> =C2=B9 https://panel.bitfolk.com/dns/#toc-secondary-dns
>
> --
> http://bitfolk.com/ -- No-nonsense VPS hosting
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAk8lZeEACgkQIJm2TL8VSQtTRwCfe9AbxMoKFbgdv/8xA8A8dfaH
> 7RYAn1zljbTaxOVjcWXItydio80cYDOY
> =3DAS62
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
>
>
--=20
Keith Williams
I can picture in my mind a world without war, a world without hate. And I
can picture us attacking that world, because they'd never expect it.
- Jack Handey
I'm sick of following my dreams. I'm just going to ask them where they're
going and hook up with them later.
- Mitch Hedberg
=E0=B8=97=E0=B8=B3=E0=B8=94=E0=B8=B5=E0=B9=84=E0=B8=94=E0=B9=89=E0=B8=94=E0=
=B8=B5 =E0=B8=97=E0=B8=B3=E0=B8=8A=E0=B8=B1=E0=B9=88=E0=B8=A7=E0=B9=84=E0=
=B8=94=E0=B8=8A=E0=B8=B1=E0=B9=88=E0=B8=A7
--14dae9399b0dd8bad004b7addbb3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>Andy,</div><div>=C2=A0</div><div>There are, of course, times when you =
need a very short rfresh etc - when testing or changing records. And I supp=
ose it is possible, for any number of reasons, to forget to change back.</d=
iv>
<div>=C2=A0</div><div>I think your suggestion is a good one but would it be=
possible to write the code so that if refresh or expire=C2=A0time is below=
a certain amount, or the difference between them is less than a certain fi=
gure/proportion then the alerts are switched off for that domain and a warn=
ing given on the panel page. It's then up to the customer to keep an ey=
e on it.<br>
<br></div><div class=3D"gmail_quote">On 29 January 2012 15:29, Andy Smith <=
span dir=3D"ltr"><<a href=3D"
mailto:andy@bitfolk.com">andy@???</=
a>></span> wrote:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid" class=3D"gmail_quote">
Hello,<br>
<br>
Long email about DNS timers and alerting based on them. Unless you<br>
have domains on BitFolk's secondary DNS platform you probably won't=
<br>
care about this, and even then you still probably don't care unless<br>
you've been receiving alerts about them. Turn back now!<br>
<br>
Still here? OK.<br>
<br>
I've recently implemented DNS secondary domain zone age alerts. They<br=
>
send alerts when the zone on BitFolk's nameservers is too old. This<br>
saves me having to read logs and open a support ticket to advise<br>
customers that the zone transfers are failing, so I'm all in
