Bug 522999 - BIND 9.6.1-P1-RedHat-9.6.1-4.P1.fc11 is performing forward lookup using IPv6 when no publicly routable IPv6 address is assigned to the machine.
BIND 9.6.1-P1-RedHat-9.6.1-4.P1.fc11 is performing forward lookup using IPv6 ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-13 03:57 EDT by Tim Butterworth
Modified: 2013-04-30 19:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:25:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tim Butterworth 2009-09-13 03:57:32 EDT
Description of problem:
BIND is sending forward lookup requests using IPv6 when no publicly routable IPv6 address is assigned to the server.  I have commented out all of the IPv6 entries in the named.ca root DNS and updated it with the latest information from ftp.rs.internic.net. 

Version-Release number of selected component (if applicable):
BIND 9.6.1-P1-RedHat-9.6.1-4.P1.fc11

I am continuously seeing IPv6 lookup failures example:
Sep 13 16:37:14 server2 named[4264]: network unreachable resolving '221.90.in-addr.arpa/DS/IN': 2001:6b0:7::2#53
Sep 13 16:37:28 server2 named[4264]: network unreachable resolving 'Y.ARIN.NET/AAAA/IN': 2001:440:2000:1::21#53
Sep 13 16:38:29 server2 named[4264]: network unreachable resolving '176.73.184.65.in-addr.arpa/PTR/IN': 2001:500:13::63#53

Is there a way to disable IPv6 support for BIND other than manually compiling it with --disable-ipv6?

Thanks
Comment 1 Adam Tkac 2009-09-14 09:20:11 EDT
You can add '-4' parameter to OPTIONS= in your /etc/sysconfig/named. With this parameter named will use IPv4 stack only.

I will discuss current behavior in upstream. I think better will be to disable IPv6 if only link-local IPv6 interface is found.
Comment 2 Tim Butterworth 2009-09-14 09:55:54 EDT
Thanks it looks like that is the simple solution I did not try.  I was finally able to get it to stop by blacklisting IPv6 and disabling network manager to get ride of the IPv6 loopback and Local Link address.

/etc/modprobe.d/dist-oss.conf
alias net-pf-10 off
alias ipv6 off

/etc/modprobe.d/blacklist.conf
blacklist ipv6

I went ahead and added the -4 setting also just in case IPv6 finds its way back on again.
Comment 3 Tim Butterworth 2009-09-14 10:11:20 EDT
Oh and I forgot to mention one other strange thing.  When IPv6 was on named would start on boot but would not perform any name resolution until I manually restarted named.  After blacklisting IPv6 this issue went away also.
Comment 4 Adam Tkac 2009-09-14 10:27:57 EDT
(In reply to comment #3)
> Oh and I forgot to mention one other strange thing.  When IPv6 was on named
> would start on boot but would not perform any name resolution until I manually
> restarted named.  After blacklisting IPv6 this issue went away also.  

I don't think this issue is related to IPv6, it is probably related to NM - check bug #490275.
Comment 5 Tim Butterworth 2009-09-14 11:18:58 EDT
Yeah that makes sense.  I disabled NM and setup the blacklist entry in one pass so I just assumed IPv6 was the culprit.

Do you know if there is also a bug or know issue with the working directory?
Sep 15 00:15:53 server2 named[3510]: the working directory is not writable
I receive these on startup.  I check permissions and SELinux and everything looks good.  I do not have the chroot package installed.
Comment 6 Tim Butterworth 2009-09-14 11:25:45 EDT
Well everything is working now.  I have two issue to look into the working directory not being writable message and some unexpected RCODE (SERVFAIL) resolving messages.  I am going to leave well enough alone for the moment though thank you for your assistance.
Comment 7 Adam Tkac 2009-09-14 11:46:00 EDT
(In reply to comment #6)
> Well everything is working now.  I have two issue to look into the working
> directory not being writable message and some unexpected RCODE (SERVFAIL)
> resolving messages.  I am going to leave well enough alone for the moment
> though thank you for your assistance.  

The "working directory is not writable" message is not a problem, it is actually a feature ;)

There are so many reasons for SERVFAILs but generally the reason can be found in the system log.
Comment 8 Tim Butterworth 2009-09-14 12:04:31 EDT
I forgot to restrict recursion to only the local networks.  I added allow-recursion { 127.0.0.1; my; local; networks; }; and I am no longer seeing them.

Thanks again for your assistance.  Did you want to keep this open for the IPv6 Local Link issue?  From searching around it seems I am not the only one that stumbled onto it.  If not we can close it.

Thanks
Comment 9 Adam Tkac 2009-09-15 03:48:36 EDT
Yes, please, keep this bug open otherwise I might forgot to do something with the IPv6 link-local issue.
Comment 10 Andrew McNabb 2010-03-04 15:02:15 EST
I'm having this problem, too.  For now, I'll do the "-4" workaround, but it seems to me that if an IPv6 connection fails with "network unreachable", then named should fall back on IPv4.

By the way, I'm bumping the version to Fedora 12 because that's where I'm seeing the problem.  Thanks.
Comment 11 Bug Zapper 2010-11-04 06:03:55 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2010-12-05 01:25:22 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.