Re: BIND 9.8.2 is now available
I will take this opportunity now to point out that upgrading to 9.9.X from any release prior to it might cause problems if you have any slave zones. 9.9.X by default saves slave zone files using masterfile-format raw;, and 9.8.X and earlier defaults to masterfile-format text;. It's easy to fix if you convert all of your slave zones beforehand with named-compilezone. That's the one big gotcha I've been dealing with at my job. I didn't see any gotchas going from 9.7.X to 9.8.X. On Apr 10, 2012, at 1:14 PM, Mike Bernhardt wrote: In order to save me poring through lots of archives and posts for the answer to a simple question: Are there any differences between 9.7x and 9.8x that require a change in named.conf configuration? The bottom line is that if I want to upgrade from 9.7 to 9.8, are there any Gotchas that I need to know about? What I have in mind is something like the change in default recursive query functionality that occurred between 9.3 and 9.4, not new features. If there are, just let me know the area to research and I'll get the details myself. 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 ___ 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: Feature request for dig
That's a little more output, but when you try it, notice that there's no dig org. DNSKEY in the output, which is the query that was hanging in my case. On Mar 6, 2012, at 9:10 PM, Mark Andrews wrote: dig +trace +qr +comment +question -- 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
Re: Feature request for dig
On Mar 7, 2012, at 6:23 PM, Mark Andrews wrote: Compile in +sigchase support and give it a root key. Evan Hunt told us (regarding +sigchase) in its current state it's terrible and you really shouldn't use it. I'm not sure who to believe. TCP has *never* been optional for DNS. Unfortunately there are lots of myths out there and your firewall administrators listened to them. I didn't ask about TCP. I am very aware of the various firewall holes that need to be open for DNS to work. My firewall administrator is too. In this case it was inadvertently left out of our firewall, and was quickly fixed once identified. The issue in this case was that *identifying* it with dig was very difficult. ___ 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
Feature request for dig
Hi, fellow BIND users. The other day I was attempting to diagnose a problem on a recursive resolving name server. I had just enabled DNSSEC Validation, and certain digs (such as www.isc.org, www.dnssec-failed.org) were failing. Even queries to non-signed domains such my own personal domain (which also happens to be in .org) were failing. I was testing it with this command line: dig +dnssec +bufsize= www.isc.org. a Where is our locally-configured edns-udp-size value. This DNS lookup took a long time to finish (it was timing out), and then eventually failed with a timeout error. I tried to see where it was failing with: dig +dnssec +bufsize= @127.0.0.1 www.isc.org. A +trace I got this output before it hung: = ; DiG 9.8.1-P1 +dnssec +bufsize= @127.0.0.1 www.isc.org. A +trace ; (1 server found) ;; global options: +cmd . 506674 IN NS a.root-servers.net. . 506674 IN NS e.root-servers.net. . 506674 IN NS l.root-servers.net. . 506674 IN NS m.root-servers.net. . 506674 IN NS d.root-servers.net. . 506674 IN NS g.root-servers.net. . 506674 IN NS i.root-servers.net. . 506674 IN NS f.root-servers.net. . 506674 IN NS h.root-servers.net. . 506674 IN NS c.root-servers.net. . 506674 IN NS k.root-servers.net. . 506674 IN NS b.root-servers.net. . 506674 IN NS j.root-servers.net. . 506674 IN RRSIG NS 8 0 518400 2012031300 2012030523 51201 . kBn5abbR2172kIhOfAdf38Mi4IpqkclowMxD2BKh2hg3udwGeJfK3YOA I1Pz9lcb/NzFzh+ndVXZERaofryyoeE15ZD0HQxMqLai7HV6nVKQyiPZ vGXA3CsIua9g8dnnN4RNbYrPnM7i6f/hBgKph8/AcFHXAQfRFZIxiJL1 O50= ;; Received 397 bytes from 127.0.0.1#53(127.0.0.1) in 817 ms = I ended up spending an hour or two trying to figure out what was causing it to hang, and in the end, this query was hanging: dig +dnssec +bufsize= @a0.org.afilias-nst.info. org. DNSKEY It turns out that the answer to that query is larger than our bufsize, so the packet came back truncated, and BIND was re-trying over TCP, but our ACLs weren't set up right to allow that. My request is this: Please add something to dig that replicates the behavior of BIND as closely as possible with regards to the many queries it issues as part of a DNSSEC-validing resolution. I ran tcpdump on an unloaded server and captured all DNS query traffic immediately after running rndc flush, and the queries it asked, in order, were: Remote serverDomainType === = === M.ROOT-SERVERS.NETwww.dnssec-failed.org. A M.ROOT-SERVERS.NET . NS d0.org.afilias-nst.orgwww.dnssec-failed.org. A dns105.comcast.netwww.dnssec-failed.org. A f.root-servers.net . DNSKEY dns104.comcast.netdnssec-failed.org. DNSKEY a2.org.afilias-nst.infodnssec-failed.org. DS b0.org.afilias-nst.org org. DNSKEY k.root-servers.net org. DS dns101.comcast.netdnssec-failed.org. DNSKEY dns105.comcast.netdnssec-failed.org. DNSKEY dns103.comcast.netdnssec-failed.org. DNSKEY dns102.comcast.netdnssec-failed.org. DNSKEY c0.org.afilias-nst.org dns104.comcast.org. dns101.comcast.net dns104.comcast.org. (The edns-udp-size for this server is 4096.) I realize that some of this traffic might be unusual (such as the query for dig @M.ROOT-SERVERS.NET . NS), but the rest of it is normal DNSSEC resolution. It would be *extremely helpful* if dig printed out the queries it was doing as it was doing them, so I could have seen that it was re-trying a truncated response, and hanging on TCP. This doesn't even show the fallback-to-TCP that might happen if the edns-udp-size was lower, like in my other location. I understand I'm asking dig to do what BIND normally does, but since they're both packaged together, it seems like a reasonable request. Does anyone else see a need for a tool like this? ___ 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 to INADDR_ANY
There are some caveats to trying to use interface-interval to pick up new
IPs. If your BIND drops privileges (e.g., by using the -u command-line
option to named), you might have a problem getting BIND to bind() to the new IP
addresses.
For example, on FreeBSD if you use -u to drop privileges, BIND will not be
able to bind() to new addresses without modifying the kernel to allow non-root
users to bind() to port 53.
On modern versions of Linux, BIND can bind() to new IP addresses even with the
-u option because the kernel has a mechanism to allow it.
In my environment (FreeBSD) we've worked around this problem (just recently, in
fact), and I can provide more details if there's any interest.
On Jan 10, 2012, at 11:42 AM, michoski wrote:
On 1/9/12 5:12 PM, Bostjan Skufca bost...@a2o.si wrote:
is binding to all interfaces at once already supported in bind9? I know named
binds to each at-the-moment-available IP address but in HA environment with
virtual interfaces a rndc reload is necessary for named to pick up a new
interface, which leaves a bit of a window of unavailable service.
According to Bv9ARM.pdf p67 listen-on-v6 { any; }; does a wildcard bind on
supporting systems, while listen-on { any; }; behaves as you describe:
OPS:55 mhosk...@dev-ops-test1.vega:~$ grep listen-on /etc/namedb/named.conf
listen-on { any; };
listen-on-v6 { any; };
OPS:56 mhosk...@dev-ops-test1.vega:~$ netstat -an|grep 53
tcp0 0 10.8.36.47:53 0.0.0.0:*
LISTEN
tcp0 0 127.0.0.1:530.0.0.0:*
LISTEN
tcp0 0 127.0.0.1:953 0.0.0.0:*
LISTEN
tcp0 0 :::53 :::*
LISTEN
tcp0 0 :::5308 :::*
LISTEN
udp0 0 10.8.36.47:53 0.0.0.0:*
udp0 0 127.0.0.1:530.0.0.0:*
udp0 0 :::53 :::*
However (I usually just set it to 0), the caveat you might have missed is
that you can control how often (if at all) BIND rescans the list of
available interfaces (ARM p73):
The server will scan the network interface list every interface-interval
minutes. The default is 60 minutes. The maximum value is 28 days (40320
minutes). If set to 0, interface scanning will only occur when the
configuration file is loaded. After the scan, the server will begin listen-
ing for queries on any newly discovered interfaces (provided they are
allowed by the listen-on configuration), and will stop listening on
interfaces that have gone away.
Setting interface-interval to a reasonably low value should keep you from
needing to rndc reconfig/reload.
http://www.isc.org/software/bind/documentation
--
Don't worry about avoiding temptation -- as you grow older, it starts
avoiding you. -- The Old Farmer's Almanac
___
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: Bind to INADDR_ANY
On Jan 10, 2012, at 5:53 PM, Doug Barton wrote: On 01/10/2012 17:34, Mark K. Pettit wrote: In my environment (FreeBSD) we've worked around this problem (just recently, in fact), and I can provide more details if there's any interest. well I'm definitely interested. :) The short answer is we wrote a script that basically does this: sysctl net.inet.ip.portrange.reservedhigh=52 rndc reconfig wait until the new IP is working sysctl net.inet.ip.portrange.reservedhigh=1023 Then run that script as root whenever we add a new IP to a host. ___ 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: epza.gov.tw. MX
On Aug 8, 2011, at 1:50 PM, Chris Thompson wrote: On Aug 8 2011, Mark K. Pettit wrote: My resolvers, running BIND 9.7.3P3, are having a difficult time resolving the MX record for the zone epza.gov.tw.. [...] Any idea why this might be happening? The delegation for epza.gov.tw from the gov.tw zone specifies a single nameserver dns.epza.gov.tw (with glue 163.29.43.1). But the server there thinks that the nameserver for the zone is called ns.epza.gov.tw, and that dns.epza.gov.tw is a CNAME with target ns.epza.gov.tw. Using CNAMEs like that doesn't work correctly. Making dns.epza.gov.tw have a duplicate address record instead would work, but of course what is really needed is to get the delegation in step with the zone itself. Having more than one nameserver for the zone wouldn't be a bad idea, either ... Thanks, this explained everything we've been seeing. Fortunately, it's not our fault, so we can punt. :) ___ 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: big improvement in BIND9 auth-server startup time
Not sure where to report this, but there's a problem in the documentation of BIND 9.7.4, as distributed by ISC. The Release Notes included in the bind-9.7.4 tarball, as well as the release notes on the web site: ftp://ftp.isc.org/isc/bind9/9.7.4/RELEASE-NOTES-BIND-9.7.4.html state that the environment variable to improve loading times for name servers with large numbers of zones is: BIND9_ZONE_TASKS_HINTS But that is incorrect. The actual variable name is: BIND9_ZONE_TASKS_HINT I discovered this because I was curious how this change was implemented (I had not seen the blog post http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance when I started to look into this), and couldn't find the string BIND9_ZONE_TASKS_HINTS anywhere in the source code. ___ 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 performance
One of the things that got us is we didn't know BIND 8 automatically created
delegation records in a zone at the zone cut, if the nameserver knew of the
existence of the cut.
For example, if we have the following zones in our named.conf:
zone example.com { ... };
zone sub.example.com { ... };
and inside example.com, we do *not* have any delegation records for
sub.example.com, BIND 8 will automatically create the NS records in
example.com.
BIND 9 will not do this. Be sure all of your zones that have zone cuts also
have the proper delegation records.
On Jun 15, 2011, at 1:30 PM, Eivind Olsen wrote:
abushla...@ies.etisalat.ae wrote:
What about zone configuration in BIND 8 and BIND 9? Is there any
difference between the two ?
Do you mean the zone configuration in named.conf, or the zonefiles?
BIND9 has a doc/misc/migration document which gives plenty of good advice
on configuration changes from BIND8 to BIND9.
In general, what I'd recommend is:
1) Read that migration document
2) Test your existing named.conf + zonefiles by either loading them into
BIND9 directly, or by using the named-checkconf / named-checkzone commands
from BIND9.
3) Watch your logs
Regards
Eivind Olsen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
