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@xxxxxxxxxx]
Sent: Sunday, January 11, 2015 12:00 PM
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays