Re: monitoring BIND
Maybe start with https://kb.isc.org/docs/monitoring-recommendations-for-bind-9 On Thu, Aug 3, 2023 at 9:07 AM wrote: > > > Hello comunity > > please what is the most recommended tool for BIND monitoring and > especially display response time and latency thank you in advance. > > Regards Sami > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- - Andrew "lathama" Latham - -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
> On 3 Aug 2023, at 17:07, sami.ra...@sofrecom.com wrote: > > Hello comunity > please what is the most recommended tool for BIND monitoring and especially > display response time and latency thank you in advance. For latency, your friend is Dnstap. The implementation on Bind is superb. When Dnstap reports a RESOLVER_RESPONSE event it includes *both* the query timestamp and the received response timestamp. It doesn´t work on CLIENT_REPONSE right now, although it may with a small caveat (I am going to lobby a bit: issue 3695). Other DNS servers are not so complete so you should keep track of those timestamps yourself. Borja. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: monitoring BIND
Hello Andrew Thank you for your feedback I am testing some tools including netdata from the list suggested by the isc except that I want to know your feedback about the tools you use especially to monitor latency. Regards De : Andrew Latham Envoyé : jeudi 3 août 2023 16:14 À : RAHAL Sami SOFRECOM Cc : bind-users@lists.isc.org Objet : Re: monitoring BIND Maybe start with https://kb.isc.org/docs/monitoring-recommendations-for-bind-9 On Thu, Aug 3, 2023 at 9:07 AM mailto:sami.ra...@sofrecom.com>> wrote: Hello comunity please what is the most recommended tool for BIND monitoring and especially display response time and latency thank you in advance. Regards Sami -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- - Andrew "lathama" Latham - -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: monitoring BIND
Hello Borja Thank you very much for this feedback, yes I confirm that monitoring the latency time is not always obvious, please about this solution you are currently using, there is a tutorial to try it? Thanks in advance. Regards Sami -Message d'origine- De : Borja Marcos Envoyé : vendredi 4 août 2023 07:34 À : RAHAL Sami SOFRECOM Cc : bind-users@lists.isc.org Objet : Re: monitoring BIND > On 3 Aug 2023, at 17:07, sami.ra...@sofrecom.com wrote: > > Hello comunity > please what is the most recommended tool for BIND monitoring and especially > display response time and latency thank you in advance. For latency, your friend is Dnstap. The implementation on Bind is superb. When Dnstap reports a RESOLVER_RESPONSE event it includes *both* the query timestamp and the received response timestamp. It doesn´t work on CLIENT_REPONSE right now, although it may with a small caveat (I am going to lobby a bit: issue 3695). Other DNS servers are not so complete so you should keep track of those timestamps yourself. Borja. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
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" 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. 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 fact, responding slowly when that someone comes to > complain. It turns out to be their PC, or a local network issue, or > whatever. > > So we have a homegrown system in place that watches the traffic to and > from the nameservers, matches queries to answers, ignores everything > else, and notes how long it was between the question going past and the > answer going past in the opposite direction. It writes summarised > information second by second into a database so we can see exactly when > problems with response times happen, how long they happen for, and how > bad they are when they happen. > > Our system has two faults (well, two that we are actually concerned > about): It only watches UDP, and it can't deal with fragmented packets. > > So I was wondering if there is a better solution out there? > > Regards, K. > > -- > ~~~ > Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
Hi Karl, Have you considered using dig? -Romskie On Wed, Jul 13, 2011 at 10:43 PM, Karl Auer 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. 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 fact, responding slowly when that someone comes to > complain. It turns out to be their PC, or a local network issue, or > whatever. > > So we have a homegrown system in place that watches the traffic to and > from the nameservers, matches queries to answers, ignores everything > else, and notes how long it was between the question going past and the > answer going past in the opposite direction. It writes summarised > information second by second into a database so we can see exactly when > problems with response times happen, how long they happen for, and how > bad they are when they happen. > > Our system has two faults (well, two that we are actually concerned > about): It only watches UDP, and it can't deal with fragmented packets. > > So I was wondering if there is a better solution out there? > > Regards, K. > > -- > ~~~ > Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
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 queries and responses to and from the nameservers and summarises ALL the response times, regardless of where the queries came from. For every second of the day we can say what the average, minimum, maximum, etc response times were. We're looking for something that can do that, or something similar... Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
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 wrote: > Hi Karl, > > Have you considered using dig? > > -Romskie > > On Wed, Jul 13, 2011 at 10:43 PM, Karl Auer 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. 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 fact, responding slowly when that someone comes to >> complain. It turns out to be their PC, or a local network issue, or >> whatever. >> >> So we have a homegrown system in place that watches the traffic to and >> from the nameservers, matches queries to answers, ignores everything >> else, and notes how long it was between the question going past and the >> answer going past in the opposite direction. It writes summarised >> information second by second into a database so we can see exactly when >> problems with response times happen, how long they happen for, and how >> bad they are when they happen. >> >> Our system has two faults (well, two that we are actually concerned >> about): It only watches UDP, and it can't deal with fragmented packets. >> >> So I was wondering if there is a better solution out there? >> >> Regards, K. >> >> -- >> ~~~ >> Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) >> http://www.biplane.com.au/kauer/ +61-428-957160 (mob) >> >> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 >> Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
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 https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
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 reported by RIPE NCC's DNSMON but weren't sure if the problem was Internet routing, or inside our nodes, and if inside our nodes was it the server, or the load balancer, etc. We set up traffic capture with tcpdump at strategic points within the node, ie: between the router and load balancer, between the load balancer and the servers, on each server. With a good sample of the traffic, say an hour or so, we could then pull the DNSMON raw data for that same time period, and match the queries it sent to us (the DNSMON raw data contains the query id) against what we saw inside our node and verify that we saw it, answered it, and that the answer made it back out into the Internet. We could also see what path the query and answer took through the node and where any delays might be. This very quickly led us to the load balancers as the cause of the delays and we were able to fix them. We never felt the need to run this on an ongoing basis, once our servers looked green in DNSMON again we were happy that all was well in our world. We used it for diagnosis, rather than detection as it sounds like you want to do. dave On 2011-07-13, at 11:27 AM, Karl Auer 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 several, and > using a very small number of tests. > > Our current system watches ALL queries and responses to and from the > nameservers and summarises ALL the response times, regardless of where > the queries came from. For every second of the day we can say what the > average, minimum, maximum, etc response times were. > > We're looking for something that can do that, or something similar... > > Regards, K. > > -- > ~~~ > Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
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 (http://haroon.sis.utoronto.ca/rrd/scripts/) you could easily visualize the data. Regards, János 2011-07-13 16:43 keltezéssel, Karl Auer írta: 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 fact, responding slowly when that someone comes to complain. It turns out to be their PC, or a local network issue, or whatever. So we have a homegrown system in place that watches the traffic to and from the nameservers, matches queries to answers, ignores everything else, and notes how long it was between the question going past and the answer going past in the opposite direction. It writes summarised information second by second into a database so we can see exactly when problems with response times happen, how long they happen for, and how bad they are when they happen. Our system has two faults (well, two that we are actually concerned about): It only watches UDP, and it can't deal with fragmented packets. So I was wondering if there is a better solution out there? Regards, K. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
On Thu, 14 Jul 2011 01:27:48 +1000, Karl Auer 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 several, and > using a very small number of tests. > > Our current system watches ALL queries and responses to and from the > nameservers and summarises ALL the response times, regardless of where > the queries came from. For every second of the day we can say what the > average, minimum, maximum, etc response times were. > > We're looking for something that can do that, or something similar... > > Regards, K. PasTmon can do that from the server side. It listens for network traffic like tcpdump and shovels all of the packet timings into a Postgres database with a nice front-end for graphs and analysis. I can't remember if the DNS plugin has filtering for different query types ( e.g. A, PTR, etc ) but it can probably be written without too much pain. See http://pastmon.sourceforge.net/ I've used it to solve web app performance problems, it should have no trouble dealing with DNS. -- Kerry ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: monitoring BIND
Karl Auer wrote: More info to my question: dig and Nagios have been suggested as possible solutions. You can use any plugin targetting the plugin api to make that happen (http://docs.icinga.org/latest/en/pluginapi.html). While Icinga/Nagios will be doing regular active checks for single bind running hosts, you can also * use passive checks to commit reported states (including freshness checks) * use clustered checks targetting conditional states (2 out of 3 down -> critical notification, look at check_multi or similar) * make sure to provide perfdata from the plugins, using things like pnp4nagios to create nice looking rrds out of that. alerting, notifications, escalations and even event handlers (restart bind if dead) should also come to mind. 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. that's true, but you can use satellites in the outside world. running nrpe server or a mod_gearman worker client, this will help a lot to get an external view. and if combined into clustered checks, the overall (alerting) stage can be differently being set. Our current system watches ALL queries and responses to and from the nameservers and summarises ALL the response times, regardless of where the queries came from. For every second of the day we can say what the average, minimum, maximum, etc response times were. H, that sounds like logfile parsing and creating reports. That'll be something for using send_nsca to pass to Icinga/Nagios from the client. Maybe check_logfiles is sufficient? If you happen to have that logged differently - like someone might expect that you are using a pcap based tool like nmsg or dsc - placing hooks over there, sending alerts to Icinga/Nagios would also be possible. Kind regards, Michael -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedr...@univie.ac.at phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax:+43 1 4277 14338 web:http://www.univie.ac.at/zid http://www.aco.net Icinga Core& IDOUtils Developer http://www.icinga.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Monitoring BIND
On 02/15/2013 12:30 AM, Arie Lendra. Putra wrote: Hi, Let me introduce myself, My name is Arie L. Putra, I’m a data network engineer at a EVDO operator. We are using BIND 9.3.6 ( a bit old yes), for our caching-only name server, we are not maintaining authoritatives. We are not monitoring our DNS Server using: 1. Cacti (for traffic, cpu, mem, etc) 2. Munin for Stats Do you have any recommendation for monitoring bind response time from a customer test node (a windows box) On linux we could set up a dig script that provide response time in millisecond->ftp’ed to our server then graph it with RRDtool. Any recommendation for windows env.? Sure, use dig. ISC provides Windows packages. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users