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 agree 100%.
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
On Mon, 25 Apr 2005 22:19:51 PDT, william(at)elan.net said:
Perhaps a solution is to specifically enable ipv6 dns resolution as
preferable to ipv4 or the other way around. This could perhaps be
switch in resolv.conf or nsswitch.conf. Something like:
/etc/resolv.conf
search example.com
Have to say we see no issues here with the worldnic.com nameservers, other
than they appear to be located on the same physical network.
I think people should post queries that fail, including date/time, and full
dig output for that query from the server they used, and the version of
recursive
Suresh Ramasubramanian wrote:
I'd say fix the resolver to not try resolve v6 where there exists no
v6 connectivity
I'd say fix the broken v6 connectivity.
- Kevin
On Tue, 26 Apr 2005, Simon Waters wrote:
Have to say we see no issues here with the worldnic.com nameservers, other
than they appear to be located on the same physical network.
I think people should post queries that fail, including date/time, and full
dig output for that query from the
lots of folk sent email to me and not the list. most report
worldnic responding with tcp 53 and not udp. would love to
hear confirmation on list. can think of a number of causes,
one possible, but just a stab in the dark, would be an
intentional hack as a defense to a spoofed-ip attack.
what
At 21:34 -0700 4/25/05, Rodney Joffe wrote:
The culprit is dig.
Ahh, dig. What version? You have to be running the latest at all
times these days...so many changes...
In my experiences with v6 the problems I have come down two are:
1) Broken testing tools. (See change 1610 in the BIND CHANGES
Randy Bush [EMAIL PROTECTED] wrote:
lots of folk sent email to me and not the list. most report worldnic
responding with tcp 53 and not udp. would love to hear confirmation
on list. can think of a number of causes, one possible, but just a
stab in the dark, would be an intentional hack as a
On Tue, 26 Apr 2005, Randy Bush wrote:
lots of folk sent email to me and not the list. most report
worldnic responding with tcp 53 and not udp. would love to
hear confirmation on list. can think of a number of causes,
one possible, but just a stab in the dark, would be an
intentional
On Tue, 26 Apr 2005, Brett Frankenberger wrote:
On Tue, Apr 26, 2005 at 01:22:41PM +, Christopher L. Morrow wrote:
On Tue, 26 Apr 2005, Simon Waters wrote:
The worldnic.com and worldnic.net appear to use the MMDDVV convention
for
SOA serial numbers, and so it would
In message [EMAIL PROTECTED], Christ
opher L. Morrow writes:
On Tue, 26 Apr 2005, Randy Bush wrote:
lots of folk sent email to me and not the list. most report
worldnic responding with tcp 53 and not udp. would love to
hear confirmation on list. can think of a number of causes,
one
- Original Message -
From: Randy Bush [EMAIL PROTECTED]
To: Christopher L. Morrow [EMAIL PROTECTED]
Cc: nanog@merit.edu
Sent: Tuesday, April 26, 2005 16:35
Subject: Re: Problems with NS*.worldnic.com
lots of folk sent email to me and not the list. most report
worldnic responding
I saw some mention of this in a previous thread. Is anyone else still
experiencing problems? We're seeing general slowness and the use of the
truncate bit in responses, forcing to TCP mode.
]
To: [EMAIL PROTECTED]
Sent: Monday, April 25, 2005 21:34
Subject: Problems with NS*.worldnic.com
I saw some mention of this in a previous thread. Is anyone else still
experiencing problems? We're seeing general slowness and the use of the
truncate bit in responses, forcing to TCP mode.
I saw some mention of this in a previous thread. Is anyone else still
experiencing problems? We're seeing general slowness and the use of the
truncate bit in responses, forcing to TCP mode.
We're still having a wack of issues with all names on NSI nameservers. Poking
around at other
On Mon, 25 Apr 2005, Graeme Clark wrote:
I saw some mention of this in a previous thread. Is anyone else still
experiencing problems? We're seeing general slowness and the use of the
truncate bit in responses, forcing to TCP mode.
We're still having a wack of issues with all names on
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:
On Mon, 25 Apr 2005, Randy Bush wrote:
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:
Well, the first thing any engineer worth their saly would
ask in a situatin such as this is Were any changes implemented,
concurrent with the appearance of these problems, which would
have possibly account for this?
This problem has fairly wide-spread implications, it would
appear, and the lack
Matt Larson wrote:
a.gtld-servers.net and b.gtld-servers.net have records. Some
applications and stacks try the v6 address first if it's available and
will appear to hang if you don't have v6 connectivity. That may very
well be what's happening here.
Are the records for a
Randy, and others with this issue...
On 4/25/05 5:24 PM, Randy Bush [EMAIL PROTECTED] 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
On 4/26/05, Rodney Joffe [EMAIL PROTECTED] wrote:
The culprit is dig.
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
On Mon, 25 Apr 2005 21:34:54 PDT, Rodney Joffe said:
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
So how is it supposed to know that it doesn't have an ipv6 connection?
in my case, because
o no interfaces have v6 addresses
o v6 stack is not present
o ...
it should also not use smoke signals, analog voice phone, ...
the chances of a box having a v6 connection to *anything* today
is
On Tue, 26 Apr 2005 [EMAIL PROTECTED] wrote:
On Mon, 25 Apr 2005 21:34:54 PDT, Rodney Joffe said:
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
25 matches
Mail list logo
