f



Re: Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure

> Hi,
> 
> I have a very strange problem with a Bind server version 9.2.5 on Fedora 
> Core 3.
> 
> Named listen to one IPv4 address and any IPv6 address. The configuration 
> has been running for many months. No changes where made recently to the 
> configuration except for adding or removing slave zones.
> 
> The symptom is that the server does not answer request to the IPv6 
> address + port UDP 53. It still answers requests to the UDP and TCP port 
> 53 using IPv4 and to the TCP port  53 using IPv6. Using dig on the 
> server, or on any server on the same LAN, leads to the following behavior :
> - dig ns some.domain @IPv4-address : works fine
> - dig +vc ns some.domain @IPv4-address : works fine
> - dig +vc ns some.domain @IPv6-address: works fine
> - dig ns some.domain @IPv6-address: works once or twice immediately 
> after restarting named, fails afterwards
> 
> The logs show the following message :
> Jan 16 23:34:25 named[32125]: failed to get request's destination: failure
> Jan 16 23:34:27 named[32125]: client.c:1325: unexpected error:
> 
> I had a look on client.c around line 1325 but it didn't help much.
> 
> Does someone on the list have an idea on what's wrong ?
> 
> Thanks very much in advance.
> 
> Roland.
> 
> -- 
> Roland Dirlewanger
> CNRS - D�l�gation Aquitaine-Limousin
> Esplanade des Arts et M�tiers - BP 105
> 33402 TALENCE CEDEX
> 
> T�l�phone: 05.57.35.58.52, T�l�copie: 05.57.35.58.01

	Run 9.3 or 9.4.  They both handle IPv6 a lot better than
	9.2 especially with Linux's broken IPv6 stack.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org


0
Mark
1/16/2007 11:57:35 PM
comp.protocols.dns.bind 16245 articles. 1 followers. Post Follow

0 Replies
812 Views

Similar Articles

[PageSpeed] 31

Reply:

Similar Artilces:

Re: Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure #2
> > > Hi, > > > > I have a very strange problem with a Bind server version 9.2.5 on Fedora > > Core 3. > > > > Named listen to one IPv4 address and any IPv6 address. The configuration > > has been running for many months. No changes where made recently to the > > configuration except for adding or removing slave zones. > > > > The symptom is that the server does not answer request to the IPv6 > > address + port UDP 53. It still answers requests to the UDP and TCP port > > 53 using IPv4 and to the TCP port 53 using IPv6. Using dig on the > > server, or on any server on the same LAN, leads to the following behavior : > > - dig ns some.domain @IPv4-address : works fine > > - dig +vc ns some.domain @IPv4-address : works fine > > - dig +vc ns some.domain @IPv6-address: works fine > > - dig ns some.domain @IPv6-address: works once or twice immediately > > after restarting named, fails afterwards > > > > The logs show the following message : > > Jan 16 23:34:25 named[32125]: failed to get request's destination: failure > > Jan 16 23:34:27 named[32125]: client.c:1325: unexpected error: > > > > I had a look on client.c around line 1325 but it didn't help much. > > > > Does someone on the list have an idea on what's wrong ? > > > > Thanks very much in advance. ...

Re: Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure #3
> Hello, > > Roland Dirlewanger a �crit : > > > > I have a very strange problem with a Bind server version 9.2.5 on Fedora > > Core 3. > > > > Named listen to one IPv4 address and any IPv6 address. The configuration > > has been running for many months. No changes where made recently to the > > configuration except for adding or removing slave zones. > > > > The symptom is that the server does not answer request to the IPv6 > > address + port UDP 53. It still answers requests to the UDP and TCP port > > 53 using IPv4 and to the TCP port 53 using IPv6. Using dig on the > > server, or on any server on the same LAN, leads to the following behavior : > > - dig ns some.domain @IPv4-address : works fine > > - dig +vc ns some.domain @IPv4-address : works fine > > - dig +vc ns some.domain @IPv6-address: works fine > > - dig ns some.domain @IPv6-address: works once or twice immediately > > after restarting named, fails afterwards > > > > The logs show the following message : > > Jan 16 23:34:25 named[32125]: failed to get request's destination: failure > > Jan 16 23:34:27 named[32125]: client.c:1325: unexpected error: > > I think I experienced a similar problem with BIND 9.2.4 on Debian Sarge. > It seems to be triggered when the IPv6 UDP socket receives an IPv4 > request, which can occur in t...

Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure
Hi, I have a very strange problem with a Bind server version 9.2.5 on Fedora Core 3. Named listen to one IPv4 address and any IPv6 address. The configuration has been running for many months. No changes where made recently to the configuration except for adding or removing slave zones. The symptom is that the server does not answer request to the IPv6 address + port UDP 53. It still answers requests to the UDP and TCP port 53 using IPv4 and to the TCP port 53 using IPv6. Using dig on the server, or on any server on the same LAN, leads to the following behavior : - dig ns some.domain @IPv4-address : works fine - dig +vc ns some.domain @IPv4-address : works fine - dig +vc ns some.domain @IPv6-address: works fine - dig ns some.domain @IPv6-address: works once or twice immediately after restarting named, fails afterwards The logs show the following message : Jan 16 23:34:25 named[32125]: failed to get request's destination: failure Jan 16 23:34:27 named[32125]: client.c:1325: unexpected error: I had a look on client.c around line 1325 but it didn't help much. Does someone on the list have an idea on what's wrong ? Thanks very much in advance. Roland. -- Roland Dirlewanger CNRS - D�l�gation Aquitaine-Limousin Esplanade des Arts et M�tiers - BP 105 33402 TALENCE CEDEX T�l�phone: 05.57.35.58.52, T�l�copie: 05.57.35.58.01 ...

Re: 'failed setting up socket' error with BIND9 on Solaris 2.5 #2
> Hi Mark, > > > Looks like you are dealing with a kernel bug in SunOS 5.5.1. > > My bet is that connect() is complaining that bind() has already > > been called on the socket. > > Yep, you're right ! :-) > > > This is done to get the correct > > source address for the packets. > > You should be able to remove the isc_socket_bind() call but > > transfer-source will nolonger be effective for the TCP connection. > [....] > > > I compiled the bind again with your suggestions and that seems to wo...

RE: ISC Bind 9 Service Fails with Fatal Error #2
When would a version for Windows be expected? If not for some time, what version before this would be the most stable because 9.2.2 crashed quite regularly? Russ -----Original Message----- From: Mark_Andrews@isc.org [mailto:Mark_Andrews@isc.org] Sent: Monday, August 25, 2003 4:45 PM To: Russell Findley Cc: 'comp-protocols-dns-bind@isc.org' Subject: Re: ISC Bind 9 Service Fails with Fatal Error > I am running Bind 9 on Windows with SP4 and the latest critical updates. I > rebuilt the machine on Monday because of the failures, but this morning the > ser...

Problem running bind 9.2.3, bind 9.2.4rc2 and bind 9.3.0beta2 on bsd/os 5.1
named.run gives me: 16-Apr-2004 17:35:17.656 starting BIND 9.3.0beta2 -d 9 -n 2 16-Apr-2004 17:35:17.668 found 1 CPU, using 2 worker threads 16-Apr-2004 17:35:17.679 loading configuration from '/etc/named.conf' 16-Apr-2004 17:35:17.705 set maximum stack size to 67108864: success 16-Apr-2004 17:35:17.706 set maximum data size to 1073741824: success 16-Apr-2004 17:35:17.706 set maximum core size to 0: success 16-Apr-2004 17:35:17.706 set maximum open files to 128: success 16-Apr-2004 17:35:17.719 listening on IPv4 interface lo0, 127.0.0.1#53 16-Apr-2004 17:35:17.720 clientmgr ...

BIND 9 2 BIND 9 transfer fails with KEY after CHROOT
Hello all, I have a master and slave named server running BIND 9.2.2. I recently changed them to use chroot. When they do a transfer with a TSIG key they fail with the error below. When I do allow-transfer{any;}; it works fine. When creating my chroot I copied over all the file including the key that I am including and do not get any errors when loading bind. I checked the key files and made sure they were the same by scp'ing it over. BTW this same setup worked fine with these keys prior to using chroot. At first I was getting some other errors until I created a random entry (wh...

Re: My ISP's nameserver confuses the resolver in glibc 2.3.2 and BIND 9.2.1 #2
> > > I've been seeing some DNS lookup failures on my redhat 9 box. > > They are accomapnied by this in /var/log/messages: > > > > Jan 1 22:29:11 localhost mozilla-bin: gethostby*.getanswer: asked for > > "www.google.com.au", got "www.google.akadns.net" > > > > A little experimentation with dig reveals that all the info is being > > returned, only the A record arrives first, followed by the CNAME: > > > > [david@localhost david]$ dig www.google.com.au > > > > ; <<>&g...

Re: TCP queries fail
Have tested some more different versions for Windows: 9.4.2 used to run this without any problems, and perhaps the best option at the moment even vulnerable to the spoofing attack. Typically our servers used about 40-50M RAM 9.4.2p1 leaks memory and crashes after few hours (even plenty of free RAM left). Named process is still on and responds to windows task manager, but no reply to DNS queries. 9.5.0 leaks memory & handles, takes 2-3 days and the server runs out of memory and named stops responding. Named process still keeps running though. Restarting the named process "fixes" the problem till 2-3 days again. 9.5.0p1 leaks memory and crashes after few hours (even plenty of free RAM left). Named process is still on and responds to windows task manager, but no reply to DNS queries. 9.5.1b1 leaks memory & handles, takes 2-3 days and the server runs out of memory and named stops responding. Named process still keeps running though. Restarting the named process "fixes" the problem till 2-3 days again. Currently running the 9.5.1b1 and restarting the service every day in every server.... Jukka ...

bind-9.5.1b1: mem.c:918: INSIST(ctx->stats[i].gets == 0U) failed.
Just built bind-9.5.1b1. Startup fails with: mem.c:918: INSIST(ctx->stats[i].gets == 0U) failed. Environment: Centos 5.0 IA x86_64 dual core w/ 1GB RAM Built using: ../configure --enable-threads \ --enable-largefile \ --with-openssl=/usr/local/ssl/ \ --with-gssapi=/usr GCC version info: gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) /etc/sysconfig/named: ROOTDIR=/var/named OPTIONS='-c /config/named.conf -u named' IDEAS???? TIA -- Jon K. -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA o: 843-849-8214 ...

Re: My ISP's nameserver confuses the resolver in glibc 2.3.2 and BIND 9.2.1
> I've been seeing some DNS lookup failures on my redhat 9 box. > They are accomapnied by this in /var/log/messages: > > Jan 1 22:29:11 localhost mozilla-bin: gethostby*.getanswer: asked for > "www.google.com.au", got "www.google.akadns.net" > > A little experimentation with dig reveals that all the info is being > returned, only the A record arrives first, followed by the CNAME: > > [david@localhost david]$ dig www.google.com.au > > ; <<>> DiG 9.2.1 <<>> www.google.com.au > ;; global opt...

Initial BIND 9.9.2 RPZ xfr (spamhaus) failing with "failed to connect: timed out" ?
hi, i've installed named -v BIND 9.9.2-rpz+rl.028.23-P1 i've registered my nameserver IP with spamhaus for use of its RPZ list; i've been approved for access. i've setup my bind9 conf for slave access to a spamhaus RPZ ... acl rpz4_spamhaus { 199.168.90.51; 199.168.90.52; 199.168.90.53; }; masters rpz4_spamhaus { 199.168.90.51; 199.168.90.52; 199.168.90.53; }; ... channel bind_rpzlog { file "/var/log/bind-rpz.log" versions 10 size 5m; print-time yes; print-category yes; print-severity yes; severity d...

Re: 'failed setting up socket' error with BIND9 on Solaris 2.5
> Hi all, > > I wonder if anyone has experience with BIND9 (9.2.5 or 9.3.1 in this case) on > a SunOS 5.5.1 (Solaris 2.5) Ultra-2 Box. > > I tried to set up a BIND9 on this machine and everything seems to be ok, > compiling, installation, resolving - no problems. > > But I did not manage to configure the BIND as a slave for several domains. > There is not one zonetransfer that did it successfully. Any attempt of an > axfr from the slave to the master fails with the following error: > > -- > Nov 20 04:20:58 moebius named[5278]: tra...

RE: BIND 9.8.1-P1:'make test' fails
On No.v 22, 2011 Niall O'Reilly wrote: "Since quite a few years, I habitually run 'make test' after building BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether anyone else is also." I got exactly the same error messages when testing "xfer" as well. We are running Linux Slamd64 12.0.0 . Our current bind is 9.6.1-P1. I tried upgrading to bind-9.6.1-ESV-R5-P1 . Compilation, i.e. make, went well but 'make test' failed because that single "FAIL" in xfer . The same story with bind-9.8.1-P1: compilation OK b...

Re: BIND 9.2.3: complains about low TTL's on startup? #2
> Mark Andrews <Mark_Andrews@isc.org> wrote in message news:<cv38m6$6k1$1@sf1.isc > .org>... > > > Hello, I'm actually migrating from BIND8 to BIND9 (9.2.3). I have some > > > entries with smaller TTL's (600) than the default TTL of the zone > > > (which is set to 43200). > > > Everytime I startup the named it complains like that: > > > > > > Feb 17 17:55:56 xxx named[19917]: [ID 873579 daemon.warning] > > > dns_master_load: x.y.in-addr.arpa.db:753: TTL set to prior TTL (43200) > > > ...

Re: 'failed setting up socket' error with BIND9 on Solaris 2.5 #3
> Date: Fri, 2 Dec 2005 14:35:55 +0100 > From: Udo Zumdick <uz@nic.dtag.de> > To: BIND-Users Mailinglist <bind-users@isc.org> > Subject: Re: 'failed setting up socket' error with BIND9 on Solaris 2.5 > > > Dear List, > > apart from the xfr problems I had with BIND under solaris 2.5, which are solved > with the help from Mark, the BIND 9 is still not working properly. This error > was related to some kernelbugs in solaris 2.5 Upgrade to a more modern OS. Solaris 2.5 is WELL past its "expire by" date. (Solaris 2...

RE: Bind 9.2.5 and errors
> -----Original Message----- > I use Bind 9.2.5 on two gentoo linux boxes as a slave dns > and bind 9.2.2 on a master dns (also a gentoo box ) and if do > a a "dig" or "rndc reload ...." > the following Error message appears in the messages Log of > the slave dns > servers: > > "Jul 16 23:05:47 websrv01 kernel: process `named' is using > obsolete setsockopt SO_BSDCOMPAT Jul 17 00:07:09 websrv01 > kernel: process `dig' is using obsolete setsockopt > SO_BSDCOMPAT Jul 17 00:08:31 websrv01 kernel: process `name...

Re: BIND 9
>>>>> "Elias" == Elias <elias@streamyx.com> writes: Elias> Hi BIND gurus, I've just tried using BIND 9 and have Elias> noticed something strange. Why is it that everytime my DNS Elias> server first sends out a query, the remote DNS server will Elias> respond with a format error? After getting the error reply, Elias> my server will send another query and this time it gets Elias> accepted. This is normal. It's nothing to worry about. BIND9 tries to use EDNS0 by default: essentially DNS with bigger packe...

Re: bind 9.10..0-P1 rndc: 'retransfer' failed: not found; other rndc commands are ok
--089e01536cf6477ac104fa09bcad Content-Type: text/plain; charset=UTF-8 Sorry for jumping in, so from your information I understand that when I have updated zone file at the master I should use `rndc reload <zone-name>` instead `rndc retransfer <zone-name>` to transfer the new zone file to other slaves, is it right ? Regards, T. Kittiratanachai (Te) On Fri, May 23, 2014 at 9:45 AM, Mark Andrews <marka@isc.org> wrote: > > In message <1400812816.1479.120623529.6C6AF450@webmail.messagingengine.com>, > gr > antksupport@operamail.com writes: ...

Re: Very odd errors from bind 9.2.2 #2
Ok, turns out you were right: On Sat, 25 Oct 2003 Mark_Andrews@isc.org wrote: > > Suddenly, with _no change in configuration_, I am seeing these three > > errors in /var/log/messages every time I HUP my named process: > > > > Oct 24 22:56:38 ns1 named[8255]: dns_master_load: /etc/namedb/s/.:1: > > unexpected end of line > > Oct 24 22:56:38 ns1 named[8255]: dns_master_load: /etc/namedb/s/.:1: > > unexpected end of input > > Oct 24 22:56:38 ns1 named[8255]: zone ./IN: loading master file > > /etc/namedb/s/.: unexpected end o...

Re: Migration from BIND 4.9 to 9.2 or Microsoft DNS #2
Mokwena Motseto <MotsetM@sapo.co.za> wrote: >> Do you know of any problems I might encounter if I migrate to Microsoft >> DNS I don't what version it is, or if it has versions at all phn@icke-reklam.ipsec.nu replied: > You won't get support from this forum :-) Sorry to disappoint Peter, but there have been discussions of the interaction between MS W2k (or W2k+3) DNS Server and BIND in the on this list (and on its now-defunct sister list bind9-users@isc.org). Check the list archives. Discussions of BIND interoperability with other DNS software is n...

RE: Re: Migration from BIND 4.9 to 9.2 or Microsoft DNS
Hi Sorry for the misunderstanding I was not looking for support, I was just asking from people, who have been in the same situation that I am in now What influenced their decision to choose what ever they chose to go with -----Original Message----- From: bind-users-bounce@isc.org [mailto:bind-users-bounce@isc.org] On Behalf Of phn@icke-reklam.ipsec.nu Sent: 11 October 2004 21:21 To: comp-protocols-dns-bind@isc.org Subject: Re: Migration from BIND 4.9 to 9.2 or Microsoft DNS Mokwena Motseto <MotsetM@sapo.co.za> wrote: > Hi > We are currently running BIND 4...

Re: Can I have a HPUX bind 4.9.7 slaved to a Solaris bind 9.2.2 master ?
>>>>> "Terry" == Terry Pike <terry.j.pike@gsk.com> writes: Terry> I have a HPUX bind 4.9.7 master server that I want to Terry> convert to a slave server. I want to create a new master Terry> on Solaris bind 9.2.2. Terry> Question: will the V4.9.7 server accept zone transfers from Terry> V9.2.2 ?? Of course. Why shouldn't it? The zone transfer protocol hasn't changed. However BIND9 by default tries a more efficient data transfer scheme that long-dead stuff like BIND4 doesn't understand. This behaviour ...

Re: same here 9.2.4rc2 (was Re: Bind 9.3.0
> > On a debian server running 9.2.4rc2 we've had it die couple times over > the past few days with a similar error: > > Jan 10 20:37:02 foo named[3192]: mem.c:653: > INSIST(ctx->stats[size].gets > 0U) failed > > We're wondering if its associated with a bad memory chip. > > -mark Firstly. Why are you still running a RC? Secondly the are completely different errors. Yours is a unbalanced number of isc_mem_put() / isc_mem_get() at a given size. More puts than gets. In your case I would upgrade to BIND 9.2.4 and see if ...

Web resources about - Re: Bind 9.2.5 and IPv6 fails with client.c:1325: unexpected error: failed to get request's destination: failure - comp.protocols.dns.bind

Resources last updated: 2/20/2016 9:33:00 AM