Re: big improvement in BIND9 auth-server startup time
Evan, may find this information useful: very useful and quite impressive. -JP ___ 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
master slave different site different resolution
Dear lists, I have an issue to resolve about 2 dns server Master/Slave. The Master is positioned in a site with public ip 1.1.1.1 and all the public dns resolutions point to 1.1.1.1 the Slave is positioned in a site whit public ip 2.2.2.2 and obviously all the public dns resolutions point to 1.1.1.1 the problem born when my Master site go down, because the Slave should change the dns public resolution whit 2.2.2.2 is it possible use bind for this? or someone has any advice for me? thanks a lot ___ 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: BIND 9.6.1-P3 Vulnerabilities
On 07/06/11 16:21, Borgia, Joe A CTR USAF AFMC AFRL/RIOS wrote: BIND 9.6.1-P3 seems to be a somewhat old release of BIND, and yet, I can find no vulnerabilities listed on the ISC Security Advisories pages. Am I missing something? Yes. :-( https://www.isc.org/software/bind/security/matrix CVE-2010-3614 - Key algorithm rollover bug in BIND 9 CVE-2010-3613 - cache incorrectly allows an ncache entry and an RRSIG for the same type https://www.isc.org/software/bind/advisories/cve-2010-3614 https://www.isc.org/software/bind/advisories/cve-2010-3613 If you did a website search for 9.6.1-P3, you wouldn't have found these two because the Versions affected: lists a range. We're trying to list all versions explicitly in newer advisories to make things a bit clearer - but if a problem affects all BIND9 versions, that makes it a bit challenging! We're also pondering on how to make the matrix more readable/useful without losing the detail that we think people want/need - possibly by splitting it into several (e.g. 9.8 versions, 9.7 versions and so on). Hope this helps anyway. ___ 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: master slave different site different resolution
2011/7/14 Gabriele Gabriele d_gabri...@hotmail.it: Dear lists, I have an issue to resolve about 2 dns server Master/Slave. The Master is positioned in a site with public ip 1.1.1.1 and all the public dns resolutions point to 1.1.1.1 the Slave is positioned in a site whit public ip 2.2.2.2 and obviously all the public dns resolutions point to 1.1.1.1 the problem born when my Master site go down, because the Slave should change the dns public resolution whit 2.2.2.2 is it possible use bind for this? Sorry my bad understanding for your statement. But since you have two servers, two public IPs, why not just publish these two as authority or cache only servers? Regards. ___ 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: master slave different site different resolution
Ok, may be I was not so clear to explain.. for example I have in my Master work site the our webmail webmail.mydomain.com that when Master work site in UP the resolution is 1.1.1.1 but if the master go down in My slave work site, my slave dns resolv webmail.mydomain.com with 1.1.1.1 but that site is down. So it should resolv it with my backup/slave resolution 2.2.2.2 ok? Date: Thu, 14 Jul 2011 17:42:56 +0800 Subject: Re: master slave different site different resolution From: short...@gmail.com To: d_gabri...@hotmail.it CC: bind-users@lists.isc.org 2011/7/14 Gabriele Gabriele d_gabri...@hotmail.it: Dear lists, I have an issue to resolve about 2 dns server Master/Slave. The Master is positioned in a site with public ip 1.1.1.1 and all the public dns resolutions point to 1.1.1.1 the Slave is positioned in a site whit public ip 2.2.2.2 and obviously all the public dns resolutions point to 1.1.1.1 the problem born when my Master site go down, because the Slave should change the dns public resolution whit 2.2.2.2 is it possible use bind for this? Sorry my bad understanding for your statement. But since you have two servers, two public IPs, why not just publish these two as authority or cache only servers? Regards. ___ 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: master slave different site different resolution
On 2011-07-14 11:53, Gabriele Gabriele wrote: Ok, may be I was not so clear to explain.. for example I have in my Master work site the our webmail webmail.mydomain.com that when Master work site in UP the resolution is 1.1.1.1 but if the master go down in My slave work site, my slave dns resolv webmail.mydomain.com with 1.1.1.1 but that site is down. So it should resolv it with my backup/slave resolution 2.2.2.2 So, you have both DNS and HTTP servers on both 1.1.1.1 and 2.2.2.2? And you want HTTP traffic to go to 1.1.1.1, except where it fails, than it should switch to 2.2.2.2? First, you do realize that you need to thing of some way to synchronize those web servers. Second, if those are synchronized, why don't just put both IP addresses and have some weak load balancing? If you really want IP to change when server fails, this is bad: a) takes time to propagate - after failure you still have to wait TTL seconds before everyone uses new server. b) puts more burden on your DNS servers and on clients, as you have to put short TTLs on those names c) you have to develop a way to test for primary's site failure. And take care of false-positives. d) you can't have normal master-slave setup, which leads to zone maintenance problems. Regards, Torinthiel Date: Thu, 14 Jul 2011 17:42:56 +0800 Subject: Re: master slave different site different resolution From: short...@gmail.com To: d_gabri...@hotmail.it CC: bind-users@lists.isc.org 2011/7/14 Gabriele Gabriele d_gabri...@hotmail.it: Dear lists, I have an issue to resolve about 2 dns server Master/Slave. The Master is positioned in a site with public ip 1.1.1.1 and all the public dns resolutions point to 1.1.1.1 the Slave is positioned in a site whit public ip 2.2.2.2 and obviously all the public dns resolutions point to 1.1.1.1 the problem born when my Master site go down, because the Slave should change the dns public resolution whit 2.2.2.2 is it possible use bind for this? Sorry my bad understanding for your statement. But since you have two servers, two public IPs, why not just publish these two as authority or cache only servers? Regards. ___ 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
RFC 6303 and automatic empty zones
Now that RFC 6303 http://www.rfc-editor.org/rfc/rfc6303.txt has been published, and includes the fourteen RFC 1918 reverse zones (section 4.1), can we expect future versions of BIND to have them as automatic empty zones - i.e. the #ifdef notyet in bin/named/server.c to disappear? -- Chris Thompson Email: c...@cam.ac.uk ___ 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: RFC 6303 and automatic empty zones
Now that RFC 6303 http://www.rfc-editor.org/rfc/rfc6303.txt has been published, and includes the fourteen RFC 1918 reverse zones (section 4.1), can we expect future versions of BIND to have them as automatic empty zones - i.e. the #ifdef notyet in bin/named/server.c to disappear? Yes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: RFC 6303 and automatic empty zones
Expecting the future - Planning your life around it is something sales folks like to do and most of the rest of us call vaporware - it's always going to be available the 2nd quarter of next year. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Evan Hunt Sent: Thursday, July 14, 2011 11:16 AM To: Chris Thompson Cc: bind-users@lists.isc.org Subject: Re: RFC 6303 and automatic empty zones Now that RFC 6303 http://www.rfc-editor.org/rfc/rfc6303.txt has been published, and includes the fourteen RFC 1918 reverse zones (section 4.1), can we expect future versions of BIND to have them as automatic empty zones - i.e. the #ifdef notyet in bin/named/server.c to disappear? Yes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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 Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ 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
bind9.xsl vs. /bind9.xsl
BIND recognises just two URLs on the statistics channel, / and /bind9.xsl. The XML it delivers in response to the first starts ?xml version=1.0 encoding=UTF-8? ?xml-stylesheet type=text/xsl href=/bind9.xsl? ^^ so that a web browser will fetch the second to render the result. I wonder whether it would be better for the href to be a relative URL instead: ?xml version=1.0 encoding=UTF-8? ?xml-stylesheet type=text/xsl href=bind9.xsl? ^ Why should it matter? I have the following situation: a virtual machine running an Apache web server and a BIND hidden master for vanity zones (and a MySQL database sitting between them). To make the BIND statistics channel conveniently available to suitably authorised users I can make http://HOSTNAME/BIND-status/ do a sneaky bit of reverse proxying, with DOCUMENTROOT/BIND-status/.htaccess containing ReWriteEngine On ReWriteRule ^(.*)$ http://[::1]:8053/$1 [P,NE] (port 8053 on the loopback ::1 being the statistics channel, of course). This almost works, except that the browser tries to get the style sheet from http://HOSTNAME/bind9.xsl rather than http://HOSTNAME/BIND-status/bind9.xsl (which would work). Of course, that can be fixed up in various ways, most crudely by just copying bind9.xsl from the distribution into the top level of the DOCUMENTROOT, but it's nigglingly annoying. So is there anything that could go wrong if the style sheet reference *was* relative rather than absolute? -- Chris Thompson Email: c...@cam.ac.uk ___ 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: bind9.xsl vs. /bind9.xsl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-14 2:28 PM, Chris Thompson wrote: So is there anything that could go wrong if the style sheet reference *was* relative rather than absolute? Not that I can see. It's probably that we never considered that use case. Send in a bug report, it seems like a quick fix and one that should help your use case and not affect others. - --Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4fU3sACgkQLdqv0r6eD6aSDgCffbs0xEm1bcez/+Qx0TJfybsW wFkAmQFOgvpFJtPn0rYC3A+Z0XED4HCa =VB7Q -END PGP SIGNATURE- ___ 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: Clients get DNS timeouts because ipv6 means more queries for each lookup
In message 4e1d3c05.7040...@kamens.us, Jonathan Kamens writes: You seem to have a really big chip on your shoulder about people who run = broken DNS servers. I don't like them any more than you do. But I=20 learned Be generous in what you accept and conservative in what you=20 generate way back when I started playing with the Internet well over=20 two decades ago. It holds up now as well as it did back then, and=20 there's no good reason why it shouldn't apply in this case. Perhaps I do, but it is with good justification. There is that much garbage out there that it is hard to get answers back within the 2-4 seconds a client waits for a response. There are broken servers out there. There are misconfigured servers out there. There are broken/misconfigured firewalls out there. There are broken NAT boxes out there. There are broken DNS proxies out there. There are administrator out there that don't care. What should be a clean straight forward request / response protocol no longer is. There are lots of workarounds built into recursive servers. It got to the point that its getting hard to add new workarounds without breaking old workarounds or breaking good answer processing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.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
