Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver

2019-06-30 Thread Roger Dingledine
On Mon, Jul 01, 2019 at 10:06:08AM +0500, Roman Mamedov wrote: > On Mon, 01 Jul 2019 01:32:59 + > "Matt Westfall" wrote: > > > Just set your exit relay DNS to 8.8.8.8 and 1.1.1.1 I mean dns traffic > > isn't bulk traffic, let google and CloudFlare do the "work" > > It is considered to be a

Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver

2019-06-30 Thread Roman Mamedov
On Mon, 01 Jul 2019 01:32:59 + "Matt Westfall" wrote: > Just set your exit relay DNS to 8.8.8.8 and 1.1.1.1 I mean dns traffic > isn't bulk traffic, let google and CloudFlare do the "work" It is considered to be a bad idea privacy-wise:

Re: [tor-relays] obfs4 relay lost stable flag

2019-06-30 Thread Roger Dingledine
On Sun, Jun 30, 2019 at 02:12:49PM -0400, tor wrote: > I've been running an obfs4 bridge for about a month. Thanks for running a bridge! > My hashed fingerprint is: > E120A0492F789F5367EAD84C64F92EE279018F98 > > I recently lost the stable flag. Not sure why. I wouldn't worry too much about

Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver

2019-06-30 Thread Conrad Rockenhaus
> On Jun 30, 2019, at 8:32 PM, Matt Westfall wrote: > > Just set your exit relay DNS to 8.8.8.8 and 1.1.1.1 I mean dns traffic isn't > bulk traffic, let google and CloudFlare do the “work" > Utilizing Google DNS (and possibly Cloudflare DNS) provides a significant security flaw that allows

Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver

2019-06-30 Thread Matt Westfall
Just set your exit relay DNS to 8.8.8.8 and 1.1.1.1 I mean dns traffic isn't bulk traffic, let google and CloudFlare do the "work" Thanks, Matt Westfall President & CIO ECAN Solutions, Inc. Everything Computers and Networks 804.592.1672 -- Original Message -- From: "Tim Niemeyer" To:

[tor-relays] Tor Performance on Xen vs KVM

2019-06-30 Thread Conrad Rockenhaus
Hello, I’m just curious on how people feel about relay performance on Tor nodes running on Xen vs KVM. I’ve noticed on Xen I have increased network performance and I do like the improved modular architecture of Xen vs KVM (right now I’m working on an experimental OpenStack w/ XCP-ng

Re: [tor-relays] obfs4 relay lost stable flag

2019-06-30 Thread teor
Hi, > On 1 Jul 2019, at 04:12, tor wrote: > > Hi > > I've been running an obfs4 bridge for about a month. > > My hashed fingerprint is: > E120A0492F789F5367EAD84C64F92EE279018F98 > > I recently lost the stable flag. Not sure why. > > Any thoughts? The Stable flag isn't relevant for

Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver

2019-06-30 Thread Tim Niemeyer
Hi nusenu After reading your Mail, I realized that not the DNS records for the exit IPs are failing. Instead this list shows problems to resolve dns on the exit. I looked at our exit and all looks fine. Resolver works very fast and nothing imporint within the logfile. Only some dudes use

[tor-relays] obfs4 relay lost stable flag

2019-06-30 Thread tor
Hi I've been running an obfs4 bridge for about a month. My hashed fingerprint is: E120A0492F789F5367EAD84C64F92EE279018F98 I recently lost the stable flag. Not sure why. Any thoughts? thanks matt ___ tor-relays mailing list

Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS resolver

2019-06-30 Thread Paul
Am 28.06.19 um 22:16 schrieb nusenu: > Dear Exit relay operators, > > first of all thanks for running exit relays! > > One of the crucial service that you provide in addition to forwarding > TCP streams is DNS resolution for tor clients. > Exit relays which fail to resolve hostnames > are barely

[tor-relays] An easy self-DoS and how to avoid it

2019-06-30 Thread j4c4l4
Hi there, I have been operating a non-exit relay and a bridge for about one week now. I discovered by chance a quite silly self-DoS which could be triggered by using a NIDS (Network Intrusion Detection System) on relays. I don't know if it is known, but I thought it was worth reporting it here.