Your message dated Sun, 13 May 2007 18:27:33 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#422258: Not related to IPv6
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: bind9
Version: 1:9.3.4-2
Severity: normal
Since upgrading from Sarge to Etch, I get log messages in
/var/log/daemon.log for every external DNS lookup that my server
performs, either for itself or for a client which uses the server as
it's DNS server. This bug may or may not be a duplicate of #312189,
which complains about a similar problem with different error messages.
May 4 16:09:39 draconix named[2627]: FORMERR resolving 'lwn.net/AAAA/IN':
194.159.73.6#53
May 4 16:09:39 draconix named[2627]: FORMERR resolving 'lwn.net/A/IN':
194.159.73.6#53
The ip address 194.159.73.6 is my ISP's primary nameserver. What I
think is happening (after some google searching) is that bind tries to
forward the request to my isp's dns server, using ipv6. That server
does not support ipv6, so the error message appears. After trying it
twice (see above, AAAA/IN and A/IN), it apparently falls back to ipv4,
as the resolve does succeed.
I've tried the following to get rid of this behaviour:
- removed ipv6 support completely by not loading ipv6 module and net-pf-10
module. This seems to have worked as the modules are not listed, and ifconfig
does not show an ipv6 address for my interfaces.
- removed ipv6 localhost address from /etc/hosts, just to be sure.
- start bind with the -4 option using /etc/default/bind9.
None of that changes the behaviour, error messages still occur. I've
added a filter rule to logcheck so I don't receive email about it
(that rule is in the logcheck package by default, since recently). I
doubt that's the proper solution though? Seems like a bug that bind
would try everything the wrong way twice, before falling back to the
"right" way.
Is there a way to stop bind from doing this?
Kind regards,
Hein Zelle
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages bind9 depends on:
ii adduser 3.102 Add and remove users and groups
ii libbind9-0 1:9.3.4-2 BIND9 Shared Library used by BIND
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libdns22 1:9.3.4-2 DNS Shared Library used by BIND
ii libisc11 1:9.3.4-2 ISC Shared Library used by BIND
ii libisccc0 1:9.3.4-2 Command Channel Library used by BI
ii libisccfg1 1:9.3.4-2 Config File Handling Library used
ii liblwres9 1:9.3.4-2 Lightweight Resolver Library used
ii libssl0.9.8 0.9.8c-4 SSL shared libraries
ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip
ii netbase 4.29 Basic TCP/IP networking system
bind9 recommends no packages.
-- no debconf information
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
Hein Zelle [EMAIL PROTECTED]
http://www.icce.rug.nl/~hein
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<
--- End Message ---
--- Begin Message ---
* Hein Zelle:
> [EMAIL PROTECTED]:~$ dig @194.159.73.6 lwn.net +bufsize=4096
>
> ; <<>> DiG 9.3.4 <<>> @194.159.73.6 lwn.net +bufsize=4096
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13808
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
Yuck. That server doesn't offer recursion to you. No wonder it
doesn't work. 8-/
> My apologies if I've reported a configuration error as a bug. I'll
> try to restore ipv6 networking on this machine to see if that makes a
> difference, but I don't expect it will as everything used to work fine
> before.
I'm sure this won't make any difference, so I'm closing this bug.
--- End Message ---
