ipv6 dns failing on LAN based web sites

Have the local DNS services provided by Mavericks Server been confirmed as working with dig (dig -6, etc), and have the logs or Console.app been checked for any relevant errors? Are any of the hosts or any of the servers involved referring to any off-LAN DNS servers, or (as is usually the case) are all hosts referencing just the Mavericks Server?

DHCP is set up to provide IP addresses and the 2 local DNS servers, both Mavericks servers, to all clients on the LAN. DNS has been working fine for years for both IPv4 and IPv6 until I started running a developer release of Yosemite last summer and then IOS on an iPad and iPhone. IPv4 still worked fine, but IPv6 started failing for the LAN web site. The Mavericks servers are setup to forward DNS requests on to OPEN DNS if addresses cannot be resolved by the local servers.

Well, today's my lucky day. After posting the failure of the Mavericks server on the same LAN as the clients as the OP of this thread, I applied the just released Security Update 2014-005 to both of my MacMini Mavericks servers and rebooted the servers. The 2 Mavericks servers hadn't been restarted in several months. After applying the security update and restarting the servers, the DNS failure resolved and now all the clients, Windows, OS X and IOS 8 clients resolve and load the IPv6 web page correctly. The External DNS server has always resolved and loaded the ipv6 test site correctly as confirmed by using several IPv6 test services. The external test site I use is: http://ip6.nl Hopefully, the Mavericks servers will just work for a while until the just released Yosemite Server software is stable enough to upgrade the Mavericks servers. If the failure occurs again, I'll do some more digging with "dig" to see if I can pinpoint what happened.

Thanks, Mr. Hoffman for your generous and prompt offers to help on this situation and many more situations over the years!

FWIW, when debugging, it's better to verify network access and DNS responses, and to read logs.

When something goes sideways, I don't care if I configured the network and the DNS servers myself, nor it the configuration had been running correctly for years. I still use dig and ping and test the translations and the routing, and still verify that the stuff is working, and dig through the logs for relevant errors. Assumptions made here can blind me to the trigger for the problem.

In short, "Trust, but verify".

I was probably too nonchalant in my reply that rebooting the Mavericks Servers resulted in the IPv6 connectivity returning for LAN clients so I was just moving blindly on. Yes it is important to trust and verify as MrHoffman rightfully points out, and I do that regularly. However, when you are dealing with DNS resolutions in a mixed IPv4 and IPv6 environment things get a little more complicated for the testing. There are additional factors that I don't know how to definitively test related to what is described in this Ars Technica posting that describes better than I some of the situations you run into with tunneled IPv6 as part of your infrastructure. I believe the problem that developed in my Mavericks Server/ IOS 8/Yosemite clients had to do with the timing of DNS resolution in the Mavericks Server with IOS 8/Yosemite Safari giving up before the slower IPv6 request was answered. Just a guess at this point. The basic connectivity was well tested when setup and continued to be solid during the failures.

http://arstechnica.com/apple/2012/05/the-future-is-forever-the-state-of-ipv6-in- the-apple-world/

This article describes how DNS is resolved across the two protocols and goes on to describe Apple's approach finishing up with this astute comment:

"For most users, this is an improvement. If one protocol is slow or fails, the system will use the other, thus minimizing the amount of time you're staring at a non-responsive application. But the downside is that it's really hard to debug IPv6 (or IPv4) for connectivity issues. You have no idea which protocol version is being used for any particular connection. It would be great if Apple could add the mechanism that lets system administrators change the rules that govern IPv4 vs IPv6 preference (the RFC 3484 policy table), something already possible in other operating systems."

I think we are still waiting for RFC3484 to be implemented in OS X and IOS. Without a policy table to set the preference it is a bit of a crap shoot whether you get to your web site before Safari (or the DNS responder?) times you out.

What do your DNS log show?

If you're running DNS on a Mac OS X Server they will not directly query the root domain servers and are dependent on a DNS forwarding server or other services. Additionally, OS X Server does DNS lookups via IPv6 first and then fails over to IPv4. During this failover clients will time out.

My ISP does not support IPv6, so all of my DNS lookups fail. After reviewing the logs and discovering that the server would not query the root domain, I opened a bug report with Apple during beta of Server 4.0 testing. I was told this is the way it should work, and was advised to either edit bind directly on the server (how this is possible without any technical documentation from Apple is beyond me, the Server.app does some very non-standard things to bind, so...) or build my own bind server and use that as a relay to the root domains.

On the server, launch Terminal.app and issue the following harmless DNS diagnostic command:

sudo changeip -checkhostname

While at the command line, the output of the dig commands can help troubleshoot these sorts of errors, as these commands will perform the specific query using either IPv4 and IPv6 as requested by -4 or -6 switch on the command line.