[tor-relays] eventdns: Address mismatch on received DNS packet.

Fri Feb 20 23:31:57 UTC 2015

I'm sorry for the late reply on this but I've been having problems with my 
Internet connection and am trying to catch up on emails. I've never received 
that message but months ago I started getting messages in the posts you 
referenced like:

Jan 05 12:36:58.138 [warn] eventdns: All nameservers have failed
Jan 05 12:36:58.354 [notice] eventdns: Nameserver 192.0.2.7 is back up

The timeframe of the "failure" was so short I assumed it was a timeout or 
packet loss issue. My research led me to those posts as well as all the 
replies that essentially were: me too and I ignore them, your DNS servers are 
too slow, or guesses that the issue was packet loss.

I'm running on a residential ISP as was one of the other referenced posts. 
I've run a relay for years and was already running Unbound so I initially 
ignored them too but they began to occur more frequently. I also began to 
notice that occasionally websites wouldn't even attempt to load but when I 
clicked refresh they would immediately display. I contacted my ISP for 
support. Over the months the problem has continued to worsen to the point 
where a few months ago the cable modem started to stop responding or 
power-cycles and recovers. I've stopped relaying because of the unreliability. 
I'm on the fourth cable modem, third router, and second PC. (My only expenses 
were one of each of those. While they were old they met my needs. I wish I 
hadn't had to spend the money to replace them but I have enjoyed the improved 
speeds and features.) The last troubleshooting step the ISP tried was 
replacing the cable lines and splitters from their equipment at the pole all 
the way to my modem. I was surprised to learn that the existing cable was 
RG-59/U since it was replaced only a few years ago after a storm damaged it. 
This time they replaced it with RG-11/U from the pole to service box at the 
house and RG-6/U from there to the modem. (I'd already replaced the cable to 
my TV's with RG-6/UQ when HD came out.) The problem has improved quite a bit 
but hasn't stopped. I'm waiting on a technician to arrive on-site to continue 
troubleshooting further.

The cable technician who replaced my lines thought for sure that it would 
resolve the issue. I told him how the problem had started slowly and grown to 
its present state. I asked what other symptoms one would notice if their cable 
lines needed to be replaced. He said that the lower cable TV channels would be 
poorer quality than the higher channels. I don't watch much TV but just last 
week I'd helped a neighbor with her TV and in her comments about how much she 
disliked the cable TV monopoly where we live she had said, "Just look at how 
horrible quality the lower channels are." She had complained to the cable 
company last month about several problems she was having and they hadn't 
replaced her cable lines. I checked the service box at her house and there 
wasn't any label to indicate the type but the interesting thing was that the 
splitter had the old logo for our provider over 20 years ago. When she called 
them and reported the "poor quality on the lower channels" they immediately 
scheduled to have her lines and splitter replaced. Evidently you can have lots 
of problems that they don't have a clue how to fix but if you say the key 
words that I wouldn't have used to describe her problem that's what the cable 
staff can recognize and resolve.

One of the things I did to collect more detail on the DNS issue was capture 
all DNS traffic on my network using DNSQuerySniffer by NirSoft available at 
http://www.nirsoft.net/utils/dns_query_sniffer.html. To filter and review it 
I'd export it to Excel. Surprisingly I found a lot of corrupt queries. You may 
not be having corruption but you could probably determine more about the 
problem using that utility or one like it. Another tool I used to troubleshoot 
further is WinMTR (Redux) by appnor.com. I believe it's a Windows version of 
the Linux mtr program. It essentially runs a continuous combined ping and 
trace route calculating loss and min, max, and avg response time. One of the 
nice things is you can set the packet size and you can get very different 
results by using 1472 bytes instead of the default 32 or 64 depending on 
program. At work once I had an ISP tell me their circuit was fine after 
connecting a laptop to each end and running a continuous 32 byte ping test 
without loss. I connected my laptop and using just the WinMTR 64 byte default 
the packet loss went to > 70%.  The (Redux) by appnor.com fork is better than 
others I've found because it doesn't require admin privileges to run and 
supports IPv6. With my current problem using a 1472 packet size the packet 
loss on their network is only .000016% or .999984% reliable which is just 
short of the "golden" "five nines of reliability" but nothing close to what 
would explain my problem.

The reason for the amount of detail is to help others who get this error 
message, those who have a similar setup and may have a problem now or in the 
future and may not even realize it, as well as share the tools that have been 
a big help to me. I'm not expecting anyone to have any insights on my problem 
but if they do they would be much appreciated.

Jacob

-----Original Message-----
From: Jeremy Olexa [mailto:jolexa at jolexa.net]
Sent: Sunday, January 11, 2015 12:00 PM
To: tor-relays at lists.torproject.org
Subject: [tor-relays] eventdns: Address mismatch on received DNS packet.

Hi List,

I'm seeing these messages in one of my relays. Pretty often, too.

    eventdns: Address mismatch on received DNS packet.  Apparent source was 
<IP>:<port>

I've searched this and found references[1] to a faulty resolver of some type 
and torservers.net ignores the message[2]. I use my ISPs resolvers which are 
physically close to the server. In an attempt to fix this, I've added a 
caching local resolver to my server and configured resolv.conf properly 
(problem persists). Then I switched to Google DNS with caching in front 
(problem persists).

Can anyone clarify what the problem may be? Or is it no problem at all?

[1]: https://lists.torproject.org/pipermail/tor-relays/2013-July/002209.html
[2]: 
https://lists.torproject.org/pipermail/tor-relays/2011-December/001034.html

Thanks!
-Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6364 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150220/80e2e1f6/attachment.bin>