Monitoring BIND
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.? Best Regards, Arie Lendra Putra 陈维文 -- Together is a beautiful word, Coming together is the Beginning, Keeping together is Progress Thinking together is Unity, Working together is Success si↑ ,n image001.png___ 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 statistics-server: JSON?
On 15 Feb 2013, at 05:57, Jan-Piet Mens wrote: would there be a chance of ISC adding this to stock BIND9? Even better: would ISC take on the work of doing it? ;-) FWIW: +1 /Niall ___ 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: [SOLVED] dns_journal_write_transaction on managed-keys-zone
* Thomas Leuxner t...@leuxner.net 2013.02.11 21:13: * Evan Hunt e...@isc.org 2013.02.11 20:30: I haven't seen this problem before. Can you share the rest of your configuration with me? You can open a ticket by mailing bind9-b...@isc.org. Config sent. Regards Thomas Finally found the root of this issue. While the named has been stopped and started multiple times during investigation it appears a zombie 'named' process has been left running. The init script seems not have noticed this process and started without errors all the time, hence I did not notice this state. Eventually this created the problem when two instances wanted to write to the same log file and produced the errors. Sorry for the noise, but I was under the impression that the start/stop scripts 'sanitize' the environment good enough. I can confirm that both views and the RRLP work fine now. Cross-Posted to actual Bug Report. Regards Thomas signature.asc Description: Digital 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: BIND9 statistics-server: JSON?
-Original Message- From: Jan-Piet Mens jpmens@gmail.com Date: Friday, February 15, 2013 12:57 AM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: BIND9 statistics-server: JSON? As a fan of BIND's statistics-server I was tempted to see if I could reduce the size of the data (XML) named produces by adding an option to produce JSON. The patch [1] (which is terribly quick and dirty) does that. [1] https://gist.github.com/jpmens/4958763 Just wanted to say thanks for this, and hope it becomes official at some point. Many here prefer JSON anywhere it is available...sounds like we are not alone. ___ 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
MX failed lookup and BIND
We're seeing email failures to outlook.uga.edu. dig uga.edu +nssearch shows only dns3.uga.edu responds with an soa record. and dig -t mx outlook.uga.edu @dns3.uga.edu returns an mx record. outlook.uga.edu.86400 IN MX 10 707341637.mail.outlook.com. And we see a problem with the uga.edu nameservers when attempting to get an MX record. 3 of the 4 nameservers don't seem to be communicating with the world ... but one, dns3, is. There are 4 name servers defined as authorities for uga.edu. dns1.uga.edu. dns2.uga.edu. dns3.uga.edu. dns4.uga.edu. It has been suggested that an AD server is consistently getting correct answers ... ie, is cycling through all 4 nameservers and coming up with the mx record ... but BIND servers are not consistently getting an answer. Confused about this. I believe I've read that resolv.conf will only take the 1st 3 nameservers in a search list ... but doubt that's really related to this issue.Guessing that during a recursive search that goes through the TLD nameservers info about all 4 of the uga.edu nameservers is passed along to whatever recursive server is performing the query. Then I would expect that server to try all the nameservers in the list. In fact, a test I've run seems to confirm this. Can anyone offer any other thoughts on this? Any reason this MX record check might fail on BIND servers? Obviously the fact that 4 nameservers are delegated authority for the domain and only 1 of them can be reached is an issue. Thanks, Marty ___ 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: Building a fresh named.root
On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grep A.ROOT-SERVERS.NET returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. Chris Buxton BlueCat Networks___ 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: Export / Import all zone data
On Feb 14, 2013, at 11:46 AM, Mailinglists wrote:
I'm looking to migrate all of the zone data from one installation of Bind to
another...hardware move. One machine is very old but running a pretty modern
version of Bind 9.6-ESV-R8. The other server is running Bind 9.8.2 and is in
use, so I'm merging existing zone data with new data, although none of the
zones will overlap.
The problem I see is that the actual zone files, the way they are structured,
are in an old format. Bind 9.6 must still understand them, but I don't think
they are structured the proper way. I was hopeful there was an export /
import procedure whereby that process would sanitize the zone info and log
any errors for manual fixing.
Either this process is dead simple and so nobody documents it or it is all
but impossible so nobody documents it...I'm not sure. But an hour of web
searches hasn't turned up much, just lots of info about migrating to or from
a Windows based DNS to BIND.
named-compilezone is your friend here.
I use this 3 line script to sanitize inputs when I'm migrating customers from
their old platform to our appliances:
#!/bin/bash
mv $2{,.orig}
named-compilezone -i none -k ignore -o $2 $1 $2.orig
Chris Buxton
BlueCat Networks
___
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: Building a fresh named.root
On 02/15/2013 12:37 PM, Chris Buxton wrote: On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grepA.ROOT-SERVERS.NET http://A.ROOT-SERVERS.NET/ returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. I have a /48 allocated to my home lab :) (I also have a /26 IPv4 allocation here) - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. ___ 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
rndc.key
I am now running without chroot and relying on selinux for protection. I created a /etc/named.d/ directory for all my many includes in named.conf which I know I have to keep in /etc/ My rndc.key is in /etc/named.d/ and is an include in my named.conf. When I first started bind, it reported that it was creating rndc.key and now I find /etc/rndc.key. rndc is working, that is it returns results from commands like 'rndc status'. What is going on here? Which rndc.key is being used? 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
Randoming ports and firewall rules
So it is past time for me to only use port 53 and support port randomization. But I do run iptables (and ip6tables) and the server sits behind a Juniper SSG firewall. Where are there instructions for setting up iptables for port randomization and for general firewall rules (I doubt I will find specific for my Juniper). thank you. More questions to come as I peel this onion! I am rather behind the times! ___ 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
builtin hints working - Re: Building a fresh named.root
I commented out include for the root.hints and things are working still so obviously it is built in even though the string search is not working on my binary. On 02/15/2013 12:57 PM, Robert Moskowitz wrote: On 02/15/2013 12:37 PM, Chris Buxton wrote: On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grepA.ROOT-SERVERS.NET http://A.ROOT-SERVERS.NET/ returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. I have a /48 allocated to my home lab :) (I also have a /26 IPv4 allocation here) - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. ___ 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: Randoming ports and firewall rules
-Original Message- From: Robert Moskowitz r...@htt-consult.com Date: Friday, February 15, 2013 1:33 PM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Randoming ports and firewall rules So it is past time for me to only use port 53 and support port randomization. But I do run iptables (and ip6tables) and the server sits behind a Juniper SSG firewall. Where are there instructions for setting up iptables for port randomization and for general firewall rules (I doubt I will find specific for my Juniper). I'm likely misunderstanding the question, but I think stateful firewalls will address this for you. Unlike the days of ipchains, iptables makes this easy...as should any commercial firewall. The idea being that when you receive a query on 53/tcp or 53/udp and answer back on a random src port, that entire conversation is tracked as one session and therefore succeeds without a bunch of extra rules (the stateful rules are generated and expired on the fly). https://wiki.archlinux.org/index.php/Simple_Stateful_Firewall Fully agreed that you need to leverage src port randomization in the modern world. ___ 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
empty-zones not set warning, but have net 192.168.128/24
I have been getting this warning, and wonder why? I have read: https://kb.isc.org/.../Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html I have a 128.168.192.in-addr.arpa.zone zone in my internal view. So what might I be missing? Do I need to create my own delegation tree? ___ 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: Building a fresh named.root
On 02/15/2013 03:40 PM, Chris Buxton wrote: On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote: I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. Appearently so. Very interesting. using my IP address and I got a nice return back of the root servers. Just like I get from the 'real ones'. And I have commented out the hint stub, so I am good on this matter. One more item checked off. thanks ___ 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: Building a fresh named.root
On Feb 15, 2013, at 3:56 PM, Robert Moskowitz r...@htt-consult.com wrote: The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. Appearently so. Very interesting. using my IP address and I got a nice return back of the root servers. Just like I get from the 'real ones'. And I have commented out the hint stub, so I am good on this matter. One more item checked off. If recursion is allowed on 127.0.0.1 (and your non-loopback IPv4 addresses), you may want to permit it over IPv6 as well. Might save some debugging time when you enable externally visible IPv6. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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: Building a fresh named.root
On 02/15/2013 03:40 PM, Chris Buxton wrote: On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote: I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. I just looked at the dig results using localhost again, and there it was, ::1! I also realize that I have to add my IPv6 prefix to my allowed internal addresses, along with ::1 ___ 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
