Re: [CNS-NS #16701] DNS b0rk3n?

rossd@quantum.me.berkeley.edu via RT wrote:
>>The nslookup results you see are probably due to the fact that the
>>servers are responding after nslookup has timed out, and that's
>>confusing nslookup as it cycles through all of the server addresses in
>>your resolv.conf.
>>
>>michael
>
>
> what was _really_ weird was this...
>
> rossd@rossd ~ $ dig @21.248.0.3 www.namesys.com
> ;; reply from unexpected source: 128.32.206.9#53, expected 21.248.0.3#53
> ;; Warning: ID mismatch: expected ID 4007, got 52093

One way to explain the above is this:

You did a query of 128.32.206.9 using dig. It "timed out" but
128.32.206.9 was still working on your query after dig gave up (there's
no UDP equivalent of the TCP RST flag). Then you started querying
21.248.0.3, but then 128.32.206.9 came back with the answer (probably a
ServFail) after you had started querying 21.248.0.3. The questions to
ask are:

1. Did you do an earlier 'dig' querying 128.32.206.9?
2. Did that query have ID 52093? (dig prints the IDs so you can see
what ID you're using...another reason to use dig instead of nslookup)

> All started when I was looking through the logs today on a sick
> Windoze box: machine was reporting some .dll errors, when i saw
> the following:
>
> Event Type: Warning
> Event Source: DNS
> Event Category: None
> Event ID: 5504
> Date: 12/28/2004
> Time: 4:13:45 PM
> User: N/A
> Computer: AXLE
> Description:
> The DNS server encountered an invalid domain name in a packet from 128.32.136.9. The packet is rejected.
>
> don't know if its related... Windows Event viewer information is about
> as clear as new england clam chowder. :-(

Hmmm. There's not enough information for me to really be able to see
what's happening here. But I can tell from the dnstrace output (which I
have snipped) that the servers for namesys.com are lame or
unreachable...pretty much what I was saying--all servers are either lame
or unreachable (the * at the end of the output for t-raenon.nmd.msu.ru
and ns.namesys.com indicate that. (Note that
ns.namesys.com=www.namesys.com, and tcptraceroute indicates that the web
server is working, just their DNS is screwed up.)

michael

------------------------------------------------------------------------
The following was automatically added to this message by the list server:

For information about Micronet, including subscribing to
or unsubscribing from its mailing list and finding out
about upcoming meetings, please visit the Micronet Web site:
<http://micronet.berkeley.edu/>.
Received on Tue Jan 25 10:28:50 2005