No. The fix is to correct the nameservers. They are not correctly
following the DNS protocol and everything else is a fall out from
that.
Well, all the prodding from people here prompted me to investigate
further exactly what's going on. The problem isn't what I thought it
was. It appears
On 07/13/2011 02:13 AM, Mark Andrews wrote:
No. The fix is to correct the nameservers. They are not correctly
following the DNS protocol and everything else is a fall out from
that.
You're right that everything else is fallout from that.
But that doesn't do me much good, does it? It's my
We have some nameservers :-) that are used by quite a few thousands of
people. Every now and then someone comes to us and complains that the
DNS is responding slowly. Sometimes they are right, and we find the
problem and fix it. But most of the time everything runs fine, and the
DNS is not, in
Nagios is a very move tool for synthetic transaction monitoring. You put in
whatever hosts and host names to resolve and it does it.
-Ben Croswell
On Jul 13, 2011 11:01 AM, Karl Auer ka...@biplane.com.au wrote:
We have some nameservers :-) that are used by quite a few thousands of
people.
People who operate big authoritative name servers (particularly with
large numbers of small zones, e.g., for domain hosting and parking),
and have had trouble with slow startup, may find this information
useful:
Hi Karl,
Have you considered using dig?
-Romskie
On Wed, Jul 13, 2011 at 10:43 PM, Karl Auer ka...@biplane.com.au wrote:
We have some nameservers :-) that are used by quite a few thousands of
people. Every now and then someone comes to us and complains that the
DNS is responding slowly.
More info to my question:
dig and Nagios have been suggested as possible solutions.
dig (and I suspect Nagios, which someone else mentioned) can only test
resolution times from one point in the network, or maybe several, and
using a very small number of tests.
Our current system watches ALL
You can use dig to get a sample of the response time and rndc stats to
get query and nameserver statistics.
On Wed, Jul 13, 2011 at 11:15 PM, Romskie L rslara...@gmail.com wrote:
Hi Karl,
Have you considered using dig?
-Romskie
On Wed, Jul 13, 2011 at 10:43 PM, Karl Auer
On 07/13/2011 03:43 PM, Karl Auer wrote:
So I was wondering if there is a better solution out there?
People I know speak highly of DSC:
http://dns.measurement-factory.com/tools/dsc/index.html
___
Please visit
Sorry for contributing another non-answer, just wanted to comment that I have
done something very similar once upon a time...
The case was a DNS authority service anycast node with:
2 Internet Facing Routers -- 2 Load Balancing Switches -- Big Stack of Servers
We had seen degraded performance
On 7/13/2011 2:35 AM, Jonathan Kamens wrote:
On 07/13/2011 02:13 AM, Mark Andrews wrote:
Well, all the prodding from people here prompted me to investigate
further exactly what's going on. The problem isn't what I thought it
was. It appears to be a bug in glibc, and I've filed a bug report and
On 7/13/2011 1:06 PM, Kevin Darcy wrote:
On 7/13/2011 2:35 AM, Jonathan Kamens wrote:
On 07/13/2011 02:13 AM, Mark Andrews wrote:
Well, all the prodding from people here prompted me to investigate
further exactly what's going on. The problem isn't what I thought it
was. It appears to be a bug
Hello!
You should try collectd (http://collectd.org/) and it's bind plugin
(http://collectd.org/wiki/index.php/Plugin:BIND) You can put the
collected data to csv or RRD on the local server or send it over the
network. With RRDtool you can make fancy graphs. With this cgi
I agree that the order of the A/ responses shouldn't matter to the
result. The whole getaddrinfo() call should fail regardless of whether the
failure is seen first or the valid response is seen first. Why? Because
getaddrinfo() should, if it isn't already, be using the RFC 3484 algorithm
On Thu, 14 Jul 2011 01:27:48 +1000, Karl Auer ka...@biplane.com.au
wrote:
More info to my question:
dig and Nagios have been suggested as possible solutions.
dig (and I suspect Nagios, which someone else mentioned) can only test
resolution times from one point in the network, or maybe
On Fri, Jul 08, 2011 at 10:26:16AM -0700, Chris Buxton wrote:
On Jul 8, 2011, at 9:11 AM, Joseph S D Yao wrote:
I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
Forwarding is a response to a recursive query. For an
On 7/13/2011 2:39 PM, Jonathan Kamens wrote:
I agree that the order of the A/ responses shouldn't matter to the
result. The whole getaddrinfo() call should fail regardless of whether
the failure is seen first or the valid response is seen first. Why?
Because getaddrinfo() should, if it
17 matches
Mail list logo
