3 Apr
2011
3 Apr
'11
12:56 a.m.
Hello,
As you may be aware, BitFolk offers free authoritative DNS services
to VPS customers. This is provided by means of the BitFolk DNS
servers taking a zone transfer (AXFR) from the customer's name
server.
As part of this service we monitor the customer's name server as a
matter of course. That's because it saves everyone's time to know
where any problems lie.
What we currently monitor:
- Customer's server responds on TCP/53
- Query of server for SOA record of the customer's domain produces
a positive, authoritative response
That's pretty good but it misses one class of misconfiguration:
where a customer's name server is misconfigured to refuse zone
transfer from BitFolk's servers.
That's pretty obvious the first time the zone slaving is set up, but
if it happens afterwards then it relies on customers spotting
anomalies in their log files.
If it isn't fixed, then once the "expire" setting of the SOA record is
reached (generally 1-2 weeks for most domains) our name servers
will no longer respond to queries for the customer's domain. This
may come as a shock to the customer. At this point alerts will start
firing for us and we'll probably have to open a ticket.
I would really rather not have to open a ticket either when I spot
the refused AXFRs in my logs, or when I start getting alerts. I
would rather the customer got alerts as soon as AXFRs start failing.
The problem is I can't think of a way to check that AXFR works
without doing an AXFR. :) Can anyone else?
Alternatively, if BitFolk's Nagios tried an AXFR say once a day for
each of your zones would you consider that excessive?
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"I am the permanent milk monitor of all hobbies!" -- Simon Quinlank
3 Apr
3 Apr
9:10 a.m.
On 3/4/2011 3:56 πμ, Andy Smith wrote:
Hello,
As you may be aware, BitFolk offers free authoritative DNS services
to VPS customers. This is provided by means of the BitFolk DNS
servers taking a zone transfer (AXFR) from the customer's name
server.
As part of this service we monitor the customer's name server as a
matter of course. That's because it saves everyone's time to know
where any problems lie.
What we currently monitor:
- Customer's server responds on TCP/53
- Query of server for SOA record of the customer's domain produces
a positive, authoritative response
That's pretty good but it misses one class of misconfiguration:
where a customer's name server is misconfigured to refuse zone
transfer from BitFolk's servers.
That's pretty obvious the first time the zone slaving is set up, but
if it happens afterwards then it relies on customers spotting
anomalies in their log files.
If it isn't fixed, then once the "expire" setting of the SOA record is
reached (generally 1-2 weeks for most domains) our name servers
will no longer respond to queries for the customer's domain.
Timeout period is
indeed usually 1-2w.
Alternatively, if BitFolk's Nagios tried an AXFR
say once a day for
each of your zones would you consider that excessive?
Do it once per timeout
period. So if zone times out every 7 days, do an
AXFR from nagios once every 7 days. Customers with much lower timeouts
would probably need to be treated specially, maybe via a script.
When doing the SOA you can find out the timeout so even if it changes
you can update your scripts.
Cheers,
Andy
9:20 a.m.
On 03/04/2011 01:56, Andy Smith wrote:
Hello,
As you may be aware, BitFolk offers free authoritative DNS services
to VPS customers. This is provided by means of the BitFolk DNS
servers taking a zone transfer (AXFR) from the customer's name
server.
As part of this service we monitor the customer's name server as a
matter of course. That's because it saves everyone's time to know
where any problems lie.
What we currently monitor:
- Customer's server responds on TCP/53
- Query of server for SOA record of the customer's domain produces
a positive, authoritative response
That's pretty good but it misses one class of misconfiguration:
where a customer's name server is misconfigured to refuse zone
transfer from BitFolk's servers.
<SNIP>
Alternatively, if BitFolk's Nagios tried an AXFR say once a day for
each of your zones would you consider that excessive?
Wouldn't this still have the (albeit much reduced) chance of the dns
servers being denied but nagios allowed?
Can the DNS servers report (maybe via logfile parsing, etc) to nagios
which then reports as normal?
This should also handle varying the TTLs, and possibly other errors too.
--
Dee Earley (dee(a)earlsoft.co.uk)
irc: irc://irc.blitzed.org/
web: http://www.earlsoft.co.uk
phone: +44 (0)780 8369596
2:26 p.m.
On 3 Apr 2011, at 01:56, Andy Smith wrote:
The problem is I can't think of a way to check
that AXFR works
without doing an AXFR. :) Can anyone else?
1. Ask your server (probably just your primary) and the customer's server for the
SOA.
2. If the serial on the customer's server is newer than yours record this as the first
time that serial was seen for this domain in a DB (SQLite probably simplest?).
3. If your server still isn't up-to-date after a suitable timeframe (refresh period of
the SOA, or less if you trust/expect notifies to be working) raise an alert.
[I know you use PowerDNS in places, another idea along similar lines could be to change
the PowerDNS schema to record this extra info and alert via that. The usual concerns about
monitoring becoming too closely tied to the app apply here though.]
David
2:39 p.m.
Nevermind, that doesn't work if the zone doesn't change.
Shame bind is so impenetrable, if there was a simple way of asking it what it's
internal expire counter had you could do this quite easily.
On 3 Apr 2011, at 15:26, David Leadbeater wrote:
On 3 Apr 2011, at 01:56, Andy Smith wrote:
The problem is I can't think of a way to
check that AXFR works
without doing an AXFR. :) Can anyone else?
1. Ask your server (probably just your primary) and the customer's server for the
SOA.
2. If the serial on the customer's server is newer than yours record this as the
first time that serial was seen for this domain in a DB (SQLite probably simplest?).
3. If your server still isn't up-to-date after a suitable timeframe (refresh period
of the SOA, or less if you trust/expect notifies to be working) raise an alert.
[I know you use PowerDNS in places, another idea along similar lines could be to change
the PowerDNS schema to record this extra info and alert via that. The usual concerns about
monitoring becoming too closely tied to the app apply here though.]
David
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
4770
days inactive
4770
days old
4 comments
4 participants
participants (4)
-
Andy Smith -
David Leadbeater -
Dee Earley -
G. Miliotis