Re: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
to the patched release most closely related to your current version of BIND. These can be downloaded fromhttp://www.isc.org/downloads/all. BIND 9 version 9.8.4-P2 BIND 9 version 9.9.2-P2 Acknowledgements: ISC would like to thank Matthew Horsfall of Dyn, Inc. for discovering this bug and bringing it to our attention. Document Revision History: 1.0 Phase One - Advance Notification, 11 March 2013 1.1 Phase Two Three, 25 March 2013 2.0 Notification to Public (Phase Four), 26 March 2013 Related Documents: Japanese Translation:https://kb.isc.org/article/AA-00881 Spanish Translation:https://kb.isc.org/article/AA-00882 German Translation:https://kb.isc.org/article/AA-00883 Portuguese Translation:https://kb.isc.org/article/AA-00884 See our BIND Security Matrix for a complete listing of Security Vulnerabilities and versions affected. If you'd like more information on our product support please visit www.isc.org/support. Do you still have questions? Questions regarding this advisory should go tosecurity-offi...@isc.org Note: ISC patches only currently supported versions. When possible we indicate EOL versions affected. ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: https://www.isc.org/security-vulnerability-disclosure-policy This Knowledge Base articlehttps://kb.isc.org/article/AA-00871 is the complete and official security advisory document. Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an AS IS basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. (c) 2001-2013 Internet Systems Consortium ___ 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 -- Adam Tkac, Red Hat, 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: chroot/etc/named/ directory?
On Wed, Feb 13, 2013 at 02:18:20PM -0500, Robert Moskowitz wrote: On 02/13/2013 01:44 PM, Lightner, Jeff wrote: Haven't done it on RHEL/CentOS 6.x yet but in RHEL5 with the bind-chroot installed I've always had: /var/named/chroot as the jail for BIND. /var/named/chroot/etc = Location of global config files such as named.conf /var/named/chroot/var/named = Location of the zone files. These I am use to and have used them for years. I don't see a /var/named/chroot/etc/named in RHEL5 but then again that is based on BIND 9.3. RHEL6 is almost certainly based on a higher upstream version. Since CentOS is built from RHEL source it would have that higher version as well. Yes. I am going from Centos (RHEL) 5.5 to 6.3, so the new directory just has me wondering. I found it also as /etc/named/ so it is part of their base bind rpm, but no documentation on what they expected to be place there. Just here is something new and I want to know why so that I am not supprised. Hi, the directory is intended for configuration files included by named.conf via include directive. After that the directory is mounted via `mount --bind` into chroot so you can just put files into /etc/named/, include them into named.conf and chrooted configuration will work for you out of the box (i.e. you don't have to create symlinks for files included by named.conf etc...) Regards, Adam -- Adam Tkac, Red Hat, 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: Moving from type forward to type static-stub
On Thu, Sep 20, 2012 at 07:49:08PM -0500, Oscar Ricardo Silva wrote: I have several recursive, caching BIND servers that were running the Redhat package of BIND. Our servers started crashing because of a bug (previously identified AND fixed by ISC) so we've decided to ditch that version and run from source, 9.9.1-P3. (I'm still not sure why redhat decided to use the rc1 version of source on which to build their rpm ... seriously ... the bug that hit us was fixed in rc2 AND the final release) Because rc2 was released too late to get it into RHEL 6.3... Btw which is the bug that bothers you? Why don't you report it to RH bugzilla? Regards, Adam -- Adam Tkac, Red Hat, 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: RH release selection (was: Moving from type forward to type static-stub)
On Fri, Sep 21, 2012 at 09:36:11AM +0100, Niall O'Reilly wrote: On 21 Sep 2012, at 08:55, Adam Tkac wrote: Because rc2 was released too late to get it into RHEL 6.3... Btw which is the bug that bothers you? Why don't you report it to RH bugzilla? I don't understand why RH would choose to include a release candidate rather than a stable release. ISC's RCs are generally OK. When I updated BIND in 6.3, I could choose either 9.8.1-P* or 9.8.2rc1. So I decided to pick 9.8.2rc1 because it contains many bugfixes over 9.8.1. And from 9.8.2 changelog it doesn't seems there are regression fixes for bugs which aren't present in 9.8.1, are present in 9.8.2rc1 and are fixed in 9.8.2 (except RT #27738 which is already fixed). However it seems you hit some bug which isn't present in 9.8.1, is present in 9.8.2rc1 and is fixed in 9.8.2. Can you please tell me number of that bug so we can backport the patch? Thank you in advance. Regards, Adam -- Adam Tkac, Red Hat, 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: Question about connections to BIND and tcp 443
On Wed, Aug 22, 2012 at 08:38:18AM -0600, Moore, Mark A. wrote: Good afternoon. We are currently running BIND on our RHEL 5.x servers and see connection attempts from our internal clients to the BIND on tcp 443. They are currently being block from connecting to 443 since these servers are only DNS. Is there any reason for clients to connect to tcp 443 for any type of DNS resolution? Just want to confirm before I dig deeper into this issue. Thx in advance for any assistance provided. Mark If some of your clients use dnssec-trigger for DNSSEC setup (http://www.nlnetlabs.nl/projects/dnssec-trigger), it can probe your server for DNS-over-SSL. Check dnssec-trigger overview, section How does it work for more details. Note this doesn't mean you should allow connections to port 443. Regards, Adam -- Adam Tkac, Red Hat, 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: BIND 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.3 Very High CPU Utilization
;
};
zone 0.in-addr.arpa {
type master;
file zones/local/db.0;
};
zone 255.in-addr.arpa {
type master;
file zones/local/db.255;
};
___
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
--
Adam Tkac, Red Hat, 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: Trying to do reverse lookups, but crashing named instead.
On 01/19/2012 09:18 PM, Stack Kororā wrote: Hello, The dhcpd mailinglist sent me your way with a problem I am having with named/dhcpd. The problem I have is that I can not seem to get reverse hostname lookups in my PXEboot, which means my PXEboot clients think they are localhost. The problem that may be more relevant to the BIND list is that I can reproducibly cause named to crash with a nasty looking error. I am running on Scientific Linux 6.2 (rolling) with bind-9.7.3-8.P3.el6.x86_64 and dhcp-4.1.1-25.P1.el6_2.1.x86_64. In my log files below what I did was run `service named restart service dhcpd restart` then promptly start a PXEboot. The log file starts with the first named message. Please let me know if there are other files or any other information you would care for. The crash always starts with this line first failed to create new zone: already exists. Files are attached in this order: dhcpd.conf named.conf resolv.conf project project.reverse messages rndc.key- Nope, don't care that I am posting this. I know it is supposed to be secret but this is a virtual machine test lab with zero importance and isn't connected to the internet. There are two other logging files mentioned in the conf files: /var/log/named-auth.info never has any information in it. /var/log/update-debug.log mostly complains about this: update: info: client 127.0.0.1#46599: updating zone 'project.local/IN': update unsuccessful: aa001.project.local: 'name not in use' prerequisite not satisfied (YXDOMAIN) I know the error says that it thinks the domain does not exist. I have read the FAQ and the rfc2136.txt, yet I still don't understand why it thinks that. Any help is appreciated. Thanks! This indicates a bug in named or in the bind-dyndb-ldap plugin. Please open a bug report in Red Hat bugzilla (https://bugzilla.redhat.com). Regards, Adam ___ 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: dnssec-keygen not responding
On Wed, Nov 30, 2011 at 12:18:04AM -0500, Alan Clegg wrote: On 11/30/2011 12:15 AM, vishesh kumar wrote: Hi All I am trying to generate keys for signing vishesh.com http://vishesh.com domain using following command (for testing purpose) dnssec-keygen -a RSASHA1 -b 768 -n ZONE vishesh.com http://vishesh.com. But its not responding , i waited around 30 minutes but there is no result Operating system is RHEL6 on VirtualBox 4.1 You don't have enough entropy in the virtual environment. You can (if you understand the issues surrounding it), use /dev/urandom as your random source, or look at installing something like haveged (http://freecode.com/projects/haveged) to solve the problem. Another good solution is to pass -r keyboard to dnssec-keygen. Regards, Adam -- Adam Tkac, Red Hat, 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: bind 9.7.4 on centos6
On 09/06/2011 01:54 AM, Mark Andrews wrote: In message 1315237316.31288.2.ca...@ns.five-ten-sg.com, Carl Byington writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dnssec-lookaside auto; only pulls the dlv.isc.org key out of that file. The root's key is just for reference in BIND 9.7.x. If you just include that file into named.conf it will load the root's key and org's answers will validate. e.g. include /etc/named.iscdlv.key; BIND 9.8 has dnssec-validate auto; which pulls the root's key out of that file. Thanks! That works. Good. ISC ships the file as /etc/bind.keys with the following comments per version. The comments are there to prevent issues such as this. Please report the lack of appropriate comments to the RPM maintainer. Hello, on RHEL6 the /etc/named.iscdlv.key file is simple copy of the ISC's bind.keys with all comments: [root@rhel6 ~]# rpm -q bind bind-9.7.3-2.el6_1.P3.2.x86_64 [root@rhel6 ~]# cat /etc/named.iscdlv.key |head -5 /* $Id: bind.keys,v 1.5.42.2 2011-01-04 19:14:48 each Exp $ */ # The bind.keys file is used to override built-in DNSSEC trust anchors # which are included as part of BIND 9. As of the current release (BIND # 9.7), the only trust anchor it sets is the one for the ISC DNSSEC # Lookaside Validation zone (dlv.isc.org). Trust anchors for any other Just for information, I renamed the bind.keys to named.iscdlv.key because we shipped ISC DLV key in named.iscdlv.key file before ISC started to ship bind.keys. It made sense not to break existing configurations which had named.iscdlv.key included in the named.conf. We are also shipping the root key in the /etc/named.root.key so you can simply put include /etc/named.root.key; into your named.conf and root zone should be validated correctly. Regards, Adam ___ 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: Does the CVE-2011-1910 vulnerability affect the BIND 9.7.0-P2?
On 06/10/2011 01:45 PM, Chris Thompson wrote: On Jun 10 2011, Mark Andrews wrote: In message 201106100709.qaa04...@osspc4.sra.co.jp, YABUKI Youichi writes: The BIND security advisory for CVE-2011-1910 does not mention about versions 9.7.0, 9.7.0-P1 and 9.7.0-P2. Does the CVE-2011-1910 vulnerability affect these versions? No, they are not affected. Then the advice I got from someone else at ISC, that if if (r.length 2) return (ISC_R_NOSPACE); occurs c. line 188 in lib/dns/ncache.c (as opposed to r.length 3), then the version is vulnerable, was not complete? Because the 9.7.0* versions certainly have that code. Hello Chris, that was too short cut from ncache.c. 9.7.0* contains: /* * Copy the type to the buffer. */ isc_buffer_availableregion(buffer, r); if (r.length 2) return (ISC_R_NOSPACE); isc_buffer_putuint16(buffer, rdataset-type); /* * Copy the rdataset into the buffer. */ which is correct, you checked there are at least two bytes in the buffer and then copy uint16 (which has 2 bytes) there. However affected 9.7.3 contains: /* * Copy the type to the buffer. */ isc_buffer_availableregion(buffer, r); if (r.length 2) return (ISC_R_NOSPACE); isc_buffer_putuint16(buffer, rdataset-type); isc_buffer_putuint8(buffer, (unsigned char)rdataset-trust); /* * Copy the rdataset into the buffer. */ Notice that now you are copying three bytes (uint16 + uint8) but you only checked there is place for two bytes, which is the bug. Regards, Adam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dynamically updating the forwarders with bind/rndc
On Tue, Mar 29, 2011 at 01:12:38PM +0100, Phil Mayers wrote: On 29/03/11 12:25, Paul Wouters wrote: Hi, Is there a way for bind9 (or planned for bind10) to dynamically update the forwarders via rndc? I believe currently the only way to do this is to rewrite the config file and then cal rndc reload. I believe there's a DBUS interface that NetworkManager on Linux uses for this purpose. http://opensource.apple.com/source/bind9/bind9-31/bind9/contrib/dbus/README.DBUS ...but it seems to be absent from the bind build on my Fedora 12 box, so I don't know if it's fallen by the wayside. Hello, the DBus interface is old and is not compatible with current NetworkManager interface. Due this reason BIND in Fedora is built without it. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Threaded bind on CentOS
On Mon, Feb 28, 2011 at 09:30:10PM +, Jack Tavares wrote: Recap: running named with -n 1 will spin up one worker thread and approx 4 other threads. Hello, Is there an official discussion or explanation of what these other threads do? official explanation can be found in BIND source code. $ grep -r isc_thread_create bind-9.8.0rc1/ shows me this (stripped): 1. lib/isc/unix/socket.c - this thread handles dispatching of all incomming queries. The thread reads DNS packet from socket and send it to pool of worker threads which process it (DNSSEC validation, authoritative/recursive response etc.) 2. lib/isc/timer.c - this is the timer thread. It handles all timer events, i.e. asynchronously put specified actions to pool of worker threads 3. the main named process is the third thread other threads, called worker threads are created in lib/isc/task.c. So number of threads (as shown via `ps -eLf |grep named`) is always number of worker threads + 3. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC with 9.7.2-P2
On Sat, Nov 13, 2010 at 11:35:57AM +1100, Mark Andrews wrote:
In message 4cdd6467.9050...@imperial.ac.uk, Phil Mayers writes:
On 12/11/10 15:45, Lightner, Jeff wrote:
For Production (RPM based system) you should use RHEL or CentOS which
has a much longer life cycle. (Speaking of which, RHEL6 was just put in
I don't agree with your line of reasoning. RHEL may have longer update
cycles, but there's no guarantee a particular RHEL install will be
applying updates in real-time, so the keys in the dnssec-conf package
may still get out of date, or a RHEL install may run after it's 5-year
update cycle ends.
I think the dnssec-conf package should have had a nightly cron job to
refresh these keys, and it was a mistake to deploy without such.
Just my opinion of course.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
I use the following scripts (update-trusted-keys and commit-trusted-keys)
to manage my trust anchors. I run update-trusted-keys nightly from cron
and manually update when I get email that there has been a change.
update-trusted-keys replaces the trust anchor when the tld gets a DS
record added to the root zone. With no arguements it just updates the
current list of zones listed is /etc/trusted-keys.
Isn't sufficient to configure the root trust anchor inside managed-keys {};
statement? If I understand correctly the key should be automatically
updated, shouldn't it?
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: upgrade BIND 9.3 to 9.7.2
On Mon, Oct 25, 2010 at 11:54:02AM +0200, Javier Civera wrote: Hello colleagues, Hello, I have a REDHAT 5.4 (gcc 4.1.2) , named -v BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1 The latest released version of BIND for RHEL 5 is # rpm -q bind bind-9.3.6-4.P1.el5_4.2 # /usr/sbin/named -v BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 It contains fixes for all public DNSSEC vulnerabilities. I have seen the “Actualización de ISC BIND 9.7” for the vulnerability with DNSSEC My question , Is possible to install the last bind version 9.7 p2 directly in my REDHAT? Yes, it is. You can download it from ISC site and compile it. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Reason for separate libdns and libisc export libraries
Hello all, I would like to ask you for the reason why there are separate versions of libdns, libisc friends, called export libraries in BIND 9.7 series. If I understand correctly those export libs are supposed to be used from non-BIND9 applications and some methods are lightweight compared to full-featured BIND9 versions. In my opinion it's good idea to offer two versions of certain methods. However I don't understand why those methods need to be in separate library and, which is even worse, this library has the same name as full featured BIND9 lib. It is the best way to various run-time issues, like unresolved symbols. Another issue is that isc-config.sh utility (which is used to determine CFLAGS, LDFLAGS etc) has no support for this dual-library setup. In my opinion export libs and standard libs should be merged together or should be renamed (for example to libdns-export.so). I must note rename is probably worse case because dynamic linker can randomly pick methods with same name from libdns.so or from libdns-export.so. I think the best solution is to merge two libs into one and select methods via preprocessor flag (-DBIND9). The merged library will look like: isc/namespace.h: #ifdef BIND9 #define isc_something isc__something #endif libisc.so: isc_something isc__something So there will be no runtime issues. May I ask you if you can change current dynamic libraries setup somehow? I can prepare the patches, if you are interested. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: max-cache-size query
On Tue, Jun 01, 2010 at 03:52:56PM +0300, Techi wrote: On Tue 01 of Jun 2010 15:43:54 you wrote: What version of BIND are you running? If you're getting FD limits, I'd think it's an older version with a bug, and your problems might also be alleviated by upgrading. Version: bind-9.3.6-4.P1.el5_4.2 I cannot upgrade. Company's policy is to use only Centos packages :( Anyway, I believe that it is not a true 9.3 since for example, I can set the allow-query-cache statement of 9.5. Of course, only RH can say that and I am not RH. You are right, it is not a true 9.3.6-P1, it contains numerous enhancements from later releases (like allow-query-cache). If you set too low max-cache-size and it is really busy recursion server (from number of connections it seems it really is) then BIND will often hit upper cache watermark and will start cache cleanup, which is, at least in 9.3.X series, quite expensive operation. Additionally, when cache is too small and cleaned too often, BIND will ask again and again for the same records, which means huge number of connections. If you hit again the crash you should probably open a report in the CentOS tracker. Regards, Adam -Original Message- From: bind-users-bounces+tsnyder=rim@lists.isc.org [mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of Techi Sent: Tuesday, June 01, 2010 8:36 AM To: bind-users@lists.isc.org Subject: max-cache-size query Hallo, Recently, I faced huge problems with my DNS servers (bind crashed with no apparent reason). Some of the symptons were: * Huge number of connections on our firewalls (15). * A lot of errors in syslog about max file descriptors limits reached (currently on system, the FD limit is 4096, the default of centos) Anyway, after the proposal of a friend of mine, I removed the the max-cache- size limit (that was set to 256MB. After a restart of bind, the FW guys reported a huge drop on connections (1)! Additionally, I have no crashes so far (in contract with 1-2 per week). So, why: a. bind generated so much traffic? b. Is it possible to have bind crash because I could not handle the cache clean-up and on the same time to serve requests? Thank you ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [Fwd: Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories]
On Fri, Feb 05, 2010 at 06:22:26AM -0800, Alan Clegg wrote: I find this important enough to forward on to bind-users. Please not the importance of trust anchor management. We (= me and Paul Wouters) are working on dnssec-conf update. Sorry for troubles. Regards, Adam Date: Fri, 05 Feb 2010 14:25:10 +0100 From: Anand Buddhdev ana...@ripe.net To: dnssec-deploym...@dnssec-deployment.org Subject: [Dnssec-deployment] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 [Apologies for duplicates] Dear Colleagues, We have discovered that recent versions of the Fedora Linux distribution are shipping with a package called dnssec-conf, which contains the RIPE NCC's DNSSEC trust anchors. This package is installed by default as a dependency of BIND, and it configures BIND to do DNSSEC validation. Unfortunately, the current version of this package (1.21) is outdated and contains old trust anchors. On 16 December 2009, we had a key roll-over event, where we removed the old Key-Signing Keys (KSKs). From that time, BIND resolvers running on Fedora Linux distributions could not validate any signed responses in the RIPE NCC's reverse zones. If you are running Fedora Linux with the standard BIND package, please edit the file /etc/pki/dnssec-keys//named.dnssec.keys, and comment out all the lines in it containing the directory path production/reverse. Then restart BIND. This will stop BIND from using the outdated trust anchors. If you do want to use the RIPE NCC's trust anchors to validate our signed zones, we recommend that you fetch the latest trust anchor file from our website and reconfigure BIND to use it instead of the ones distributed in the dnssec-conf package: https://www.ripe.net/projects/disi/keys/index.html Please remember to check frequently for updates to our trust anchor file, as we introduce new Key-Signing Keys (KSKs) every 6 months. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nslookup not showng TTL
On Thu, Oct 15, 2009 at 09:06:56AM +0100, John Horne wrote: Hello, Hi, Using BIND 9.5.1 it seems that the nslookup command is not showing the TTL value of found records. It makes no difference if I set 'debug' or 'd2'. Example: == nslookup set debug www.plymouth.ac.uk Server: 127.0.0.1 Address:127.0.0.1#53 QUESTIONS: www.plymouth.ac.uk, type = A, class = IN ANSWERS: - www.plymouth.ac.uk canonical name = extranet.plymouth.ac.uk. - extranet.plymouth.ac.uk internet address = 141.163.163.185 AUTHORITY RECORDS: - plymouth.ac.uk nameserver = dns0.plymouth.ac.uk. - plymouth.ac.uk nameserver = dns1.plymouth.ac.uk. ADDITIONAL RECORDS: - dns0.plymouth.ac.uk internet address = 141.163.1.250 - dns1.plymouth.ac.uk internet address = 141.163.177.1 www.plymouth.ac.uk canonical name = extranet.plymouth.ac.uk. Name: extranet.plymouth.ac.uk Address: 141.163.163.185 == How can I see the TTL value using nslookup? I'm not sure how force nslookup to show TTL but the `dig` utility is far more better tool for getting such information: $ dig www.plymouth.ac.uk ; DiG 9.7.0a3-RedHat-9.7.0-0.5.a3.fc13 www.plymouth.ac.uk ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 17054 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.plymouth.ac.uk.IN A ;; ANSWER SECTION: www.plymouth.ac.uk. 3143IN CNAME extranet.plymouth.ac.uk. extranet.plymouth.ac.uk. 85943 IN A 141.163.163.185 ;; AUTHORITY SECTION: plymouth.ac.uk. 85943 IN NS dns1.cs.strath.ac.uk. plymouth.ac.uk. 85943 IN NS dns0.plymouth.ac.uk. plymouth.ac.uk. 85943 IN NS dns1.plymouth.ac.uk. plymouth.ac.uk. 85943 IN NS dns2.cs.strath.ac.uk. ;; ADDITIONAL SECTION: dns1.cs.strath.ac.uk. 42744 IN A 130.159.196.126 dns2.cs.strath.ac.uk. 42743 IN A 130.159.196.125 Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
On Wed, Sep 16, 2009 at 05:20:21PM +0200, RUOFF LARS wrote:
Hi,
i'm using BIND9 on an Ubuntu-8.10-server.
I'd like to configure the following:
For a given name (eg. vega.lab.ts), I'd like to forward the request to
two external DNS servers, *simultaneously*, and respond with the first
response that i get.
Is this possible?
I didn't see how to do it directly, so i tried using a subdomain, (eg.
x.vega.lab.ts) and specifiying the two DNS for this subdomain:
Extract from the lab.ts zone file:
[...]
x.lab.ts. IN NS vega-a.x.lab.ts.
x.lab.ts. IN NS vega-b.x.lab.ts.
vega-a.x.lab.ts.IN A 172.25.32.252
vega-b.x.lab.ts.IN A 192.168.2.3
[...]
But this doesnt seem to work:
named-checkzone lab.ts /etc/bind/db.lab.ts says:
zone lab.ts/IN: x.lab.ts/NS 'vega-a.x.lab.ts' (out of zone) has no
addresses records (A or ) zone lab.ts/IN: x.lab.ts/NS
'vega-b.x.lab.ts' (out of zone) has no addresses records (A or )
zone lab.ts/IN: loaded serial 2 OK
How can i do it?
Thanks,
Lars
You can use `forward` zone. Check
https://www.isc.org/software/bind/documentation/arm95#zone_statement_grammar:
zone example.com IN {
type forward;
forward only;
forwarders { IPaddr; };
};
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: forwarder that doesn't ask root servers
On Mon, Sep 14, 2009 at 01:31:24PM +0200, Marcos Lorenzo de Santiago wrote:
I believe bind has some root servers hardcoded inside and bind always
looks for root servers even if you give it a list of forwarders, I see
this in the firewall blocked connections.
So the question is quite simple: Is there anyway to disable this? I
mean, I just want bind to forward queries related to not-owned maps to a
list of forwarders as FW will drop all packages going to non-local nets.
Does any of you know how to accomplish this?
options {
...
forward only;
...
};
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
of problems might be expected here? =20 In both cases, what kind of CPU and/or RAM overhead will large-scale use of DNSSEC add? --=20 Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users =20 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. -- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Core dumping DLZ
On Thu, May 07, 2009 at 09:20:28PM -0700, Scott Haneda wrote: On May 7, 2009, at 6:51 PM, Mark Andrews wrote: (gdb) backtrace #0 0x2adb2b0e0215 in raise () from /lib64/libc.so.6 #1 0x2adb2b0e1cc0 in abort () from /lib64/libc.so.6 #2 0x2adb27c4c9e0 in assertion_failed (file=0x2adb2922428b mem.c, line=918, type=value optimized out, cond=0x2adb292245b5 ctx-stats[i].gets == 0U) at ./main.c:166 #3 0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918 #4 0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at mem.c:1067 #5 0x2adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./ main.c:1064 This is indicative of a memory / reference leak being detected on shutdown. I just had two more happen. This is not even a production server as of yet, it is being readied for that though. There should be very little hitting named-sdb at this point... (gdb) backtrace #0 0x2af5a089fdfb in ?? () from /usr/lib64/mysql/ libmysqlclient.so.15 #1 0x2af5a08a0179 in my_net_read () from /usr/lib64/mysql/ libmysqlclient.so.15 #2 0x2af5a0899922 in cli_safe_read () from /usr/lib64/mysql/ libmysqlclient.so.15 #3 0x2af5a089a9f9 in ?? () from /usr/lib64/mysql/ libmysqlclient.so.15 #4 0x2af5a0898f9e in mysql_real_query () from /usr/lib64/mysql/libmysqlclient.so.15 #5 0x2af59f09c67a in mysql_get_resultset (zone=0x4542f960 ns1.*.com, record=value optimized out, client=0x0, query=4, dbdata=0x2af59f3391e0, rs=0x4542f918) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:324 #6 0x2af59f09c80b in mysql_findzone (driverarg=value optimized out, dbdata=0x2af59f3391e0, name=0x4542f960 ns1.**.com) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:515 #7 0x2af59f7c8353 in dns_sdlzfindzone (driverarg=0x2af59f2fc410, dbdata=0x2af59f3391e0, mctx=0x2af59f2ea6c0, rdclass=1, name=0x4542fdf0, dbp=0x45430058) at sdlz.c:1461 #8 0x2af59f72cf22 in dns_dlzfindzone (view=0x2af59f3d8d20, name=0x2afda090, minlabels=3, dbp=0x45430058) at dlz.c:294 #9 0x2af59f06add4 in query_getdb (client=0x2afd1b20, name=0x2afda090, qtype=value optimized out, options=0, zonep=0x45431050, dbp=0x454310b8, versionp=0x45431058, is_zonep=0x454310cc) at query.c:925 #10 0x2af59f06fe92 in query_find (client=0x2afd1b20, event=0x0, qtype=1) at query.c:3805 #11 0x2af59f0735cd in ns_query_start (client=0x2afd1b20) at query.c:5095 #12 0x2af59f06026d in client_request (task=value optimized out, event=value optimized out) at client.c:1898 #13 0x2af5a0629e2c in run (uap=value optimized out) at task.c:862 #14 0x2af5a1ae2367 in start_thread () from /lib64/libpthread.so.0 #15 0x2af5a259f0ad in clone () from /lib64/libc.so.6 This looks MySql related. I have mysql query logging enabled, so I can see what comes in. So far, nothing looks malformed, which is a sure fire way to make one of these core dumps happen. Please open a ticket in Red Hat issue tracker (preferred method) or in Red Hat bugzilla about this issue. It is a bug somewhere in code. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named daemon hangs
On Sat, May 02, 2009 at 04:06:18PM +0100, Nelson Vale wrote: Hi all, I've been facing a problem in my private network which I was not able to fix yet. In my gateway (linux debian alike) I have bind 9.5 installed and running, and I have one IPSec tunnel to another gateway over the internet. It also has configured a forward zone with the name server being the other gateway internal address (accessibly through the IPSec tunnel only). Recently the other IPSec endpoint was shutdown and, of course, my queries to the forward domain started failling. Nothing strange here... The real problem is that I suddendly were not able to resolve any other DNS queries, like www.google.com, from inside my network: host www.google.com ;; connection timed out; no servers could be reached I took a look at the named daemon and I see that it does not respond to anything as long as the IPSec tunnel is down, but only if it's the other endpoint that is down. I've tried stopping my endpoint and this problem do not occur as long as I restart named. I think this happens because as long as my endpoint is up the routes to the other endpoint are set, and named trys to querie the forward domain name server. The problem is that the queries do not timeout and named hangs there: Please check this: - https://bugzilla.redhat.com/show_bug.cgi?id=427629 - http://lkml.org/lkml/2007/12/4/260 - http://lkml.org/lkml/2008/4/17/474 $ echo 1 /proc/sys/net/core/xfrm_larval_drop should help you. Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RHEL and named with DLZ
On Thu, Mar 05, 2009 at 09:47:07PM -0800, Scott Haneda wrote:
Hello, I am trying to get named with DLZ on RHEL.
My build line is below, I can start named, and I have base configured it
so that it will return a lookup for `dig example.com @localhost +norec`
which returns a custom IP I put in to make sure it is really working.
So far, I know named is working.
I added in dlz Mysql zone { ... }
rndc and restarting named all work fine, no errors that I can see. But
in a successful build on OS X, I was getting a line in the log for named
that said
'Mysql zone' using driver mysql
I do not get that on RHEL, and I am not getting answers back for my test
zones I have in the database. MySql is running, I know that much.
Any suggestions?
BIND in RHEL5 is based on 9.3 series and DLZ stuff has been merged in
9.4 development cycle. It is impossible to get DLZ working with bind
package that is shipped in RHEL5.
Could I ask you why you can't use SDB, please?
Regards, Adam
--
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
libbind for 9.6 series is still not available
Hi all, I would like to ask when libbind for 9.6 series will be available? There is change 2447 which says libbind has been split out as a separate product but AFAIK such product is not anywhere. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind crash with timer.c
On Tue, Nov 25, 2008 at 11:36:36AM +0100, Olivier JUDITH wrote: Currently use bind 9.2.4.-30.el4 as primary server synchronized with NTP by a GPS time sources. recently, bind daemon crash with following error messages in //var/named/log/general file. Nov 12 09:41:15.417 general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997041001 Nov 12 09:41:15.439 general: info: zone so.srsa/IN: loaded serial 811051400 Nov 12 09:41:15.439 general: notice: running Bad 00 99:99:99.999 general: critical: timer.c:645: fatal error: Bad 00 99:99:99.999 general: critical: RUNTIME_CHECK(isc_time_now(now) == 0) failed Bad 00 99:99:99.999 general: critical: exiting (due to fatal error in library) Nov 17 14:30:45.669 general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997041001 Nov 17 14:30:45.670 general: info: zone so.srsa/IN: loaded serial 811171428 Nov 17 14:30:45.670 general: notice: running Nov 17 15:39:23.507 general: info: loading configuration from '/etc/named.conf' Nov 17 15:39:23.511 general: info: zone so.srsa/IN: loaded serial 811171539 After made research in bind archive list i found one answer from *Mark Andrews* talking about time of day problem. I checked my time source and local date on the server. Everything seem to be correct. Can you give me more explanation on this crash? Hi, it is quite hard to determine where exactly problem is from information written above. The best solution will be open ticket in RH support tracker or RH bugzilla and attach core dump there. Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind9 no longer detect my ipv6 interface after having upgrade from ubuntu server 8.04 to 8.10
On Tue, Nov 18, 2008 at 04:13:35PM +0100, Thomas Manson wrote: Hi, Hi, I've my secondary DNS Server that run bind9 version 9.5.0-P2 (from ubuntu 8.10 server) Before, I was using the version on ubuntu 8.04 and it was working successfully with ipv6. I think BIND from Ubuntu distribution is not compiled as GNU source (with _GNU_SOURCE macro defined). It is needed to get IPv6 working. The best solution is to open ticket in Ubuntu bug tracker. Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
