Problems with NS*.worldnic.com

Tue Apr 26 04:34:54 UTC 2005

Randy, and others with this issue...

On 4/25/05 5:24 PM, "Randy Bush" <randy at 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)