Re: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
> script in the top level source directory, manually edit the > > "config.h" header file that was produced by the configure > > script. > > > > - Locate the line that reads "#define HAVE_REGEX_H 1" and > > replace the contents of that line with "#undef > > HAVE_REGEX_H". > > > > - Run "make clean" to remove any previously compiled object > > files from the BIND 9 source directory, then proceed to > > make and install BIND normally. > > > > Active exploits: > > > >No known active exploits. > > > > Solution: > > > >Compile BIND 9 without regular expression support as described > >in the "Workarounds" section of this advisory or upgrade 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: 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: 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: 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
-category yes;
> >
> > print-severity yes;
> >
> > print-time yes;
> >
> > };
> >
> > channel "ops" {
> >
> > file"logs/named.ops" versions 3 size 2m;
> >
> > print-category yes;
> >
> > print-severity yes;
> >
> > print-time yes;
> >
> > };
> >
> > channel "sys" {
> >
> > syslog daemon;
> >
> > print-category yes;
> >
> > };
> >
> > category "xfer-in" { "xfers"; };
> >
> > category "xfer-out" { "xfers"; };
> >
> > category "notify" { "xfers"; };
> >
> > category "database" { "debug"; };
> >
> > category "config" { "debug"; };
> >
> > category "queries" { "ops"; };
> >
> > category "client" { "ops"; };
> >
> > category "resolver" { "ops"; };
> >
> > category "security" { "sys"; "misc"; };
> >
> > category "default" { "misc"; };
> >
> > };
>
> Maybe it's caused by too many logging. Try disable them temporarilly,
> or run named with "-g" argument in foreground, watch if there's
> something unusal or appeared repeatedly.
You can also append "-d99" parameter to check which activities named perform.
Note that output might be quite large.
Regards, Adam
>
> Another method you can try is simplify your named.conf to track down
> where the problem is. If it's not configuration problem, than it's
> named maybe problematic.
>
> > // Default zones
> >
> > zone "." {
> >
> > type hint;
> >
> > file "zones/root/db.root";
> >
> > };
> >
> > zone "localhost" {
> >
> > type master;
> >
> > file "zones/local/db.local";
> >
> > };
> >
> > zone "127.in-addr.arpa" {
> >
> > type master;
> >
> > file "zones/local/db.127";
> >
> > };
> >
> > 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.8.1: INSIST(! dns_rdataset _isassociated(sigrdataset)) failed
On 11/16/2011 01:35 PM, David Ford wrote: > can we have a paradigm shift from ISC please? instead of falling over > dead with insist/assert, please bleat a warning and drop the problematic > issue on the floor instead and press on with business. many BIND DoS > attacks (and zone typos) are very effective for just this reason. > > :) > +1. Something like kernel's BUG_ON() function & cleanup is better than INSIST() & abort. 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: OT: Bind 9.9.0B1 Inline-Signing Question
On 11/10/2011 11:16 PM, Evan Hunt wrote: >> I know that this isn't the forum for betas > Sure it is. :) > >> We have been testing with the alphas and now with the beta. What we are >> seeing is that whenever named starts, it initially creates the signed >> static zone file, but never really finishes. > What do you mean by "never really finishes"? > > What are the options that are set for the static zone? You should have > these: > > auto-dnssec maintain; > inline-signing yes; > key-directory ""; > > ...with set to the location of the DNSSEC signing keys for your > zone, including at least one KSK and one ZSK, both of which are set to > be published and active. > Ah, this was missing bit in my configuration, thanks for it :) I have just one question, what should inline-zone admin do? I assume that named automatically regenerates & removes expired RRSIGs so is it sufficient to put new KSK and ZSK to the key-directory when needed and revoke older ones? Thanks for your answer in advance. 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: 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: DNSSEC for recursive server
On Fri, May 21, 2010 at 09:54:01AM +0300, Techi wrote:
> Hallo,
> I try to setup (=prepare) the our DNS servers for the DNSSEC era.
> I have a Centos 5.x with Bind 9.3.6-4. I have one problem and 2 questions.
> The problem is that the specific version seems to lack support for DNSSEC
> validation! named-checkconf returns the following error:
> /etc/named.conf:212: unknown option 'dnssec-validation'
>
> !!!
> Now the questions:
> 1. I try to understand the concepts of DNSSEC and the signing of root zones.
> As far as I understand, all I need to add in my bind's configuration are the
> following lines:
>
> dnssec-enable yes;
> dnssec-validation yes;
>
> Is that correct?
DNSSEC validation & serving is controlled by one "global" DNSSEC
option in 9.3.X series:
options {
...
dnssec yes;
...
};
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: [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 > 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: Host/nslookup/dig queries wrong server
On Wed, Feb 03, 2010 at 03:04:45PM -, Duncan Berriman wrote: > Problem is I am specifying the server on the command line, it is supposed to > use only that server, not randomly decide because it can't connect to that > server to try any others it feels like. > > Even the -s option makes no difference. > > It should even been looking at files or dns Actually only nslookup and host utilities are affected. Both utilities use specified server but when they don't get response from it they simply try servers in /etc/resolv.conf. You are right this is not correct behavior, it will be fixed in future. You can use "dig" utility for DNS debugging purposes, in my opinion it is far more better than host/nslookup (and it works fine): $ dig @123.123.123.123 google.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-6.P1.1 <<>> @123.123.123.123 google.com ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached 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: 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
On Wed, Jun 10, 2009 at 08:37:52PM -0700, Chris Buxton wrote: > On Jun 10, 2009, at 7:01 PM, Chris Adams wrote: >> Once upon a time, Chris Buxton said: >>> On the other hand, the builds from the Linux vendors have been less >>> than perfectly stable at moderately high levels of traffic. >>> Rebuilding >>> from stock source code has always fixed this problem. We've seen this >>> problem with both the Red Hat build and the Debian build. >> >> What do you mean by "moderately high levels of traffic"? We run RHEL 5 >> and its build of BIND with no troubles. I don't really see anything >> in >> the source RPM for BIND that would cause it to be any more or less >> stable than a build from the standard distribution (modulo stability >> bugs in specific BIND versions itself). > > I can't really be any more specific than I have been - the servers in > question are not our servers, and I'm not able to analyze the source > code of the patches and of BIND to see what might be causing problems. > > A few of our customers, running servers that they describe as > experiencing high traffic (by their own standards), have had to have us > rebuild BIND from the stock source code for them to solve frequent > crashing during such high traffic episodes. Frequent in this case > typically means that named either just dies or dumps core within a few > seconds of starting up. Have you ever reported the problems to the Red Hat or Debian bug tracker? Generally you don't have to be experienced programmer. Your bug report can contain, for example, "named crashed with this INSIST failure: ..." only. Your vendor will ask you more information if needed. > The Red Hat BIND SRPM applies a variety of patches that have been back- > ported from later versions. These patches appear to not be 100% > compatible with the older code they use as a base. When we have torn > apart the SRPM, replacing the base source code and disabling all patches > except the one that changes the path to the PID files, and then rebuilt > the RPM, the result has been able to hold up for these customers. In such > cases, we're not changing the configure options, we're installing the > result on the same servers that are falling over with the RH-supplied > version, and the result is a server that runs and doesn't crash or dump > core. I don't think patches are incompatible. As I wrote above please open a bug report if you think they are. I think it is a good idea to use package from your vendor because you don't have to watch bind-announce, don't have to compile each time when bind is updated etc. You can simply run "yum update" or "apt-get upgrade" and you can be sure you have software without security issues. But feel free to compile named yourself if you prefer this approach. 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
nd a > > implementation bug. > > > > > Currently, my servers run BIND 9.3.4-10.P1 (as patched by Red Hat in > > > RHEL; we typically stick with their security patched version, since > > > that's what we pay them for). What does that mean with .ORG for > > > example, where NSEC3 is used? Would we just not see NXDOMAIN > > responses > > > as validated (and what happens to unvalidated responses)? I've put in > > a > > > request to Red Hat to update to a version that supports NSEC3 but I > > > don't know what their response will be yet. > > > > BIND 9.3 is already at EOL. > > > > > For our authoritative servers, we'll need to set up a system to sign > > the > > > zones. Is it expected that ISPs will sign every zone they serve, or > > > just the domains we consider "important"? What kind 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 > > > 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
Has PGP key been changed?
Hi, has PGP key been changed? I downloaded bind-9.6.1rc1.tar.gz and SHA512 signature and tried to verify the tarball. Unfortunately verification failed because the public key is not known. $ gpg --verify bind-9.6.1rc1.tar.gz.sha512.asc bind-9.6.1rc1.tar.gz gpg: Signature made Thu 21 May 2009 11:01:12 PM CEST using RSA key ID 0B7BAE00 gpg: Can't check signature: public key not found Current ISC key located on http://oldwww.isc.org/about/openpgp/pgpkey2006.txt has different ID - 1BC91E6C. Would it be possible to publish updated PGP key, 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
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=, 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=, client=0x0, query=4, > dbdata=0x2af59f3391e0, > rs=0x4542f918) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:324 > #6 0x2af59f09c80b in mysql_findzone (driverarg= 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=, 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=, > event=) at client.c:1898 > #13 0x2af5a0629e2c in run (uap=) 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: split view dns, with a shared dynamic zone?
On Tue, Dec 30, 2008 at 08:28:06PM -0800, Paul B. Henson wrote: > On Tue, 30 Dec 2008, [iso-2022-jp] JINMEI Tatuya / � wrote: > > > So, you at least need to fix one on-memory zone image that can be > > dynamically updated. You'll then have to configure the other view where > > the "shared" zone is a secondary of the real dynamic zone in the other > > view, or a forward zone for which all queries to be forwarded to the real > > zone. (I've not tried this configuration by myself, so I'm not 100% sure > > if this can implement what you need). > > It's making my brain hurt ;), but I kind of see what you're suggesting. A > single server both master and secondary for the same zone in different > views. That should work for the "both the same" part. Then if I configure > the secondary zone to forward updates to the primary zone both views would > be the same and clients in either view could update. I guess the primary > zone would have to be in the view in which the IP of the actual server > resides, so the forwarded update from the server to itself ( 8-/, will that > even work?) hits the primary. > > I think it's kind of a deficiency of bind not to support this type of > configuration more cleanly. It would be nice if you could have both split > view zones and standalone zones on the same server. Perhaps a feature > request :)? > > Thanks for the suggestion, I'll play with it and see what happens. > Btw setup with slave zone in second view is described in FAQ as well: - https://www.isc.org/faq/bind - Configuration and Setup Questions -> "How do I share a dynamic zone between multiple views?" 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 9.3.5-P2 download link required
On Thu, Dec 04, 2008 at 12:28:38PM +0530, [EMAIL PROTECTED] wrote: Hi, > > We need BIND 9.3.5-P2 version. But we are not getting the Download > link.Kindly provide me the link. so that we can download this version,. > ftp://ftp.isc.org/isc/bind9/9.3.5-P2 -- 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: Is it possible to use one KSK for multiple domains?
On Thu, Nov 20, 2008 at 09:18:01AM +, Niall O'Reilly wrote: > On Wed, 2008-11-19 at 21:55 +0100, Adam Tkac wrote: > > does anyone know if is it possible to sign multiple domains with one > > KSK? > > Adam, > > I suspect your question may need to be more specific. Right you are. > > Are you asking about the signing process itself, or rather > about how certain aspects of this process need to be exposed > in the DNS? > > The RFC-fragment you cite seems to me to require that each > signed zone needs its set of [KZ]SK exposed in the DNS, but > to be silent on whether a single key can be reused by appearing > as RDATA in the DNSKEY RRsets of multiple zones. > > I haven't read 4033/4034 thoroughly, so it's possible I may > have misunderstood completely. > > Best regards, > > Niall O'Reilly > I know people which maintains many domains so they would like to use scenario like this: - each zone has his own ZSK - all ZSKs are signed with one KSK and corresponding DS is in parent zone So, in theory, validation will look like: - get myzone.tld. DS from tld. - validate myzone.tld. DNSKEY (= validate KSK) - validate all ZSKs with myzone.tld. KSK If I understand correctly to section 2.1.1 of RFC 4034 then when I want validate for example "myzone1.tld." ZSK there are only two ways: - get myzone1.tld. DS from tld. zone - get another myzone1.tld. key which will validate it It isn't possible to validate myzone1.tld. with key from other zone, for example myzone2.tld., is 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
Is it possible to use one KSK for multiple domains?
Hi all, does anyone know if is it possible to sign multiple domains with one KSK? If I understand correctly what RFC 4034, section 2.1.1 says "... If bit 7 has value 1, then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name MUST be the name of a zone..." it is impossible. Each zone has to have his own KSK and ZSK pair, hasn'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: 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
