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@jolexa.net] Sent: Sunday, January 11, 2015 12:00 PM To: tor-relays@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