Occasional problems were discovered where totd failed to deal with particular DNS server implementations. Some problems where dealt with in subsequent totd versions. One remaining problem is that some old nameserver implementations return a ‘Server Failed’ instead of the prescribed ‘No Such Domain’ response when asked for an IPv6 address record (that these nameservers have no knowledge of). Of course, these nameservers should be fixed, but in the meantime newer versions of totd work around the problem by always asking a nameserver for an IPv4 record even when it returns ‘Server Failed’.

Another DNS-related problem, that totd cannot solve is that some services use hardcoded IPv4 addresses instead of DNS names to save some DNS lookups. This is one of the main reasons why we preferred using HTTP ALGs running on dual-stack machines over translating HTTP connections on the network or transport layer. A few popular sites like www.hotmail.com and some advertisement suppliers used hardcoded IPv4 addresses in URLs. This generated many user-generated problem reports.

Finally, some servers advertise an IPv6 address in DNS but offer services that are IPv4-only. Due to totd, applications will use IPv4 through a translator when no IPv6 address is found, but they can/will not fallback to IPv4 through a translator when the IPv6 connection fails for some reason. An example of such a server was mail.netbsd.org which was a dual-stack machine with IPv6 address in DNS, but ran an IPv4-only sendmail configuration. Sending email from an IPv6-only mail server to mail.netbsd.org therefore failed. This problem was fixed some time after the NetBSD maintainers were notified of the problem, but many sites are not so responsive to complaints from a (still) small user population.