Randy, and others with this issue... On 4/25/05 5:24 PM, "Randy Bush" <randy@psg.com> wrote:
something *very* strange is going on. the worldnic servers have been giving delayed or no results for days now. and nsi is hoping we and the wsj/nyt won't notice.
i don't think this
roam.psg.com:/usr/home/randy> doc -p -w worldnic.net Doc-2.1.4: doc -p -w worldnic.net Doc-2.1.4: Starting test of worldnic.net. parent is net. Doc-2.1.4: Test date - Mon Apr 25 14:20:45 HST 2005 ;; res_nsend: Protocol not supported DIGERR (UNKNOWN): dig @a.gtld-servers.net. for NS of worldnic.net. failed ;; res_nsend: Protocol not supported DIGERR (UNKNOWN): dig @b.gtld-servers.net. for NS of worldnic.net. failed
is the worldnic problem, but could be. but it is a problem. (i generally ignore b root issues).
but it's probably time for us all to dump symptoms here and figure it out as a community, as the dog with the bone ain't 'fessing up.
I spent some time two months ago chasing this down with the same two gtld-servers.net records, on my mac. The culprit is dig. On any system that is both ipv4 and ipv6 enabled, *even if there is no ipv6 connectivity*, dig - which has no awareness of ipv6 v. ipv4 - attempts to connect using the ipv6 address if both an ipv6 and an ipv4 address is provided. When it fails to connect, it fails. It does not do the "better" thing, which is to try another address for the same hostname, in this case the ipv4 address. If you attempt a dig for the ipv4 address of a.gtld-servers.net or b.gtld-servers.net, you will get your answer. I am not sure whether the correct solution is to "fix" dig so that is tries ipv4, or to get the os "fixed" on a dual stack capable system so that if there is not ipv6 connectivity it disables that part of the system. I suspect the first is appropriate, because there are obviously internal processes that may validly want to use ipv6 even though there is no ipv6 connection. I also suspect that the same thing would occur for an A record that had multiple ipv4 addresses in a round robin configuration, but where the "first" ip address was unreachable, the behavior would be the same as if it was an ipv6 address being tried on a system that had no ipv6 connectivity. But I have not taken the time to test. I did ask the maintainers of dig to look at this, and perhaps provide a solution. Rodney Joffe CenterGate Research Group, LLC http://www.centergate.com "Technology so advanced, even WE don't understand it"(R)