Hide Forgot
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:
Upstream ticket: https://fedorahosted.org/freeipa/ticket/2183
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'.
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.
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 ...
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.
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.
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
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.