RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 766162 - Conncheck fails if IPv6 DNS servers are specified in /etc/resolv.conf
Summary: Conncheck fails if IPv6 DNS servers are specified in /etc/resolv.conf
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rob Crittenden
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On: 804630
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-10 17:54 UTC by Sigbjorn Lie
Modified: 2012-05-08 14:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-17 11:47:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sigbjorn Lie 2011-12-10 17:54:53 UTC 
Description of problem:
The "ipa-repl-conncheck --replica=<replica>" script fails when IPv6 addresses is listed as name server in /etc/resolv.conf, which is the default configuration of resolv.conf after running ipa-replica-install on a host with an IPv6 global address.

Port 464 fails when both the master and the replica have IPv6 enabled:

  Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): FAILED
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK

All ports except 389 fails when the master is IPv6 enabled, but the replica is only IPv4 enabled.

   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): FAILED
   Kerberos KDC: TCP (88): FAILED
   Kerberos KDC: UDP (88): FAILED
   Kerberos Kpasswd: TCP (464): FAILED
   Kerberos Kpasswd: UDP (464): FAILED
   HTTP Server: port 80 (80): FAILED
   HTTP Server: port 443(https) (443): FAILED

Switching to IPv4 only addresses in resolv.conf resolves the issue. 

This issue also creates a problem when making new replicas.


Version-Release number of selected component (if applicable):
IPA 2.1.3

How reproducible:
Every time

Steps to Reproduce:
1. Configure IPv6 ip addresses as dns servers in /etc/resolv.conf
2. Run: ipa-repl-conncheck --replica=<replica>
3. 
  
Actual results:
Fails, see above

Expected results:
Should work the same way as when using IPv4.

Additional info:
Comment 2 Dmitri Pal 2011-12-10 19:16:12 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/2183
Comment 3 Martin Kosek 2012-03-15 16:57:27 UTC 
I just run various tests on my VMs and I wasn't able to reproduce the issue. I tried 2 scenarios:

1) master is ipv6-only, replica is ipv6 only
2) master is ipv4+ipv6, replica is ipv4 only

and both worked for me well. ipa-replica-conncheck has an IPv6 fallback, i.e. when IPv4 connection fails, it tries connecting via IPv6 so it should just work when at least one connection works.

Can you please verify that:
- name server is responding correctly on the IP addresses you have in resolv.conf and have all records needed?
  dig -t a <replica> @srv-ipv4-addr
  dig -t a <replica> @srv-ipv6-addr
  dig -t aaaa <replica> @srv-ipv4-addr
  dig -t aaaa <replica> @srv-ipv6-addr
- there is no obstacle like ip6tables

You can also try testing the port with some custom tool like `nc'.
Comment 4 Sigbjorn Lie 2012-03-15 21:24:43 UTC 
The key to the issue seem to be the "options rotate" I have in my resolv.conf file.

The ipa-replica-conncheck command executes fine if I have only IPv4 DNS addresses and "options rotate" in my resolv.conf. BTW, it also excutes fine without the "options rotate".

However if I have both IPv4 and IPv6, or only IPv6 DNS servers specified in resolv.conf, and having "options rotate" at the same time, the issue occur.
Comment 5 Martin Kosek 2012-03-16 08:23:22 UTC 
Thanks for info Sigbjorn, but I still was not able to reproduce your issue (I tried "options rotate" with both IPv4 and IPv6 addresses in my /etc/resolv.conf). My previous concerns are left untouched.

Can you please verify that DNS and network is OK and the issue is really just in the ipa-replica-concheck script? The script does not use any special measures for DNS resolution, it uses standard connection via Python sockets, i.e. it should not be touched with IPv4/IPv6 address of DNS resolver.

You can use commands I posted above to verify that DNS is indeed served right on both IPv4 and IPv6 interfaces using standard Linux tools like `dig' or `host'. Few suggestions for testing in addition to above dig commands:

# host -4 <replica>
# host -6 <replica>

# telnet <replica> 636
# telnet <replica> 88
...
Comment 6 Sigbjorn Lie 2012-03-18 10:35:48 UTC 
I've ran all your requested "dig" and "host" commands, and they all resolved the hostname into IPv4 and IPv6 addresses successfully. Telneting into the requested ports also worked successfully. 

When I'm testing I'm leaving my IPv6 dns servers on the top of resolv.conf. I have also tried to comment out the IPv4 addresses completely, leaving only IPv6 addresses. I have verified both the IPv6 DNS servers that I specify in resolv.conf.

Same result as before when enabling options rotate.
Comment 7 Martin Kosek 2012-03-19 13:30:24 UTC 
Signbjorn, thanks for your results and cooperation. I did some more research and found it is actually a bug in glibc. I filed a Bug 804630. As you stated above, the key is in "options rotate" statement. It does not work well with IPv6 only nameservers.

As I found out with tcpdump, glibc always attached a domain to fqdn and thus made it invalid and not resolvable. You can check details and my test outputs in Bug 804630.
Comment 8 Martin Kosek 2012-04-02 07:44:28 UTC 
glibc team will fix this issue for _one_ IPv6 nameserver only in 6.3, details can be checked in Bug 804630.Other use cases are planned to be fixed (Bug 771204) in 6.4.

Until then, there are two workarounds that can be used:
1) Do not use "options rotate" in /etc/resol.conf
2) Add at least one IPv4 nameserver address to /etc/resol.conf
Comment 9 Martin Kosek 2012-04-17 11:47:27 UTC 
I tested the issue with fixed glibc-2.12-1.78.el6.x86_64 and everything worked fine then.

Closing this ticket as there is nothing to be done on IPA side. Please follow up on Bug 804630 and Bug 771204 to get additional updates.
Note You need to log in before you can comment on or make changes to this bug.