keweonDNS - info, facts and what is keweon actually
First, I would like to thank everyone who has used and thus supported keweonDNS, because without you this would not have been possible. The XDA Developers Forum and the Android-Hilfe Forum many thanks, as sometimes things aren't easy with me.
Everything I've developed over the last few years has to do with DNS, and this provides a little insight into what you can accomplish with DNS. Clearly, it functions, it performs – but maybe some of you have a piece of advice on what I can do differently or perhaps even better, after all, I'm up for everything.
With that said, here's the answer to what is keweon. In a nutshell – THIS is keweon:
keweon is an artificial bio-neural network capable of autonomously detecting online threats of various types, effectively blocking them and thwarting threats before they pose a threat.
Self-developed AI algorithms are used, for example, to perceive and forecast threats, as the application of stochastics (probability theory) has proven to be ineffective or too slow. These predictions currently reach up to 4 days, or 96 hours, into the future.
keweonDNS identifies and blocks Internet addresses prior to them being enrolled and live, regardless of whether the address is a domain, an alias, or a host. Detection is performed with a reliability of slightly over 80% with an error rate of approximately 20000:1.
Bio-neural AI technology safeguards against online threats without the necessity or requirement for SSL decryption of network traffic.
Click to expand...
Click to collapse
At this stage, I will not be able to outline all the details here in the forum. On the one hand it becomes too much and on the other hand “the giants” – you have cribbed enough from me so far – also read here. By now, the planned public documentation exceeds 100 pages, and I intend to accommodate and cover everything. So, before I post everything on the website, I'll first share it here on the forum with a limited group of contributors, as I'm interested in questions, feedback, and perhaps one or two remarks.
Why bio-neural network?
The most well-known neural network is the brain, whether in humans, animals, or plants, where information is perceived, classified, prioritized, and processed. As far as humans are concerned, the information is transmitted via sensors. In IT, this is called an “agent”, an unfortunate choice of words, in my opinion.
Sensors refer to basically anything that receives and transmits data. Nose, tongue, and eye are for instance sensors that transmit information to the brain and when processed in the brain, the neural network, triggers an action. Example: Fire (vision – sensor eye) + Smoke (smell – sensor nose) = Action (decision triggered by the neural network) is escape.
The goal of an AI is to artificially reproduce this “biological” behavior or sequence. The same applies in IT as in biology, a neural network must always be part of an AI. For me, there is no superior way than to apply this kind of approach to DNS.
How does keweon act as an “artificial neural network”?
What you see here is the so-called “frontend”. The one you know as the keweonDNS server:
Spoiler: keweonDNS - Frontend
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
There is nothing special here yet, nor does it have anything to do with “AI” or “ANN”. We will go into this in more detail shortly.
Let's talk about the “bio” factor. — To ensure that the keweon AI only does what it is designed to do, it was essential to set up not just one, but several control instances. Policing of the AI rests not only with the AI itself, but also with the user and with me. That is why I have used the term “Shared Manage & Controlling” to describe this process.
Internal control mechanisms within the AI guarantee that the system regulates, manages, and even polices itself. As an example, if the AI is manipulated by an external attack, a variety of defensive countermeasures are triggered, up to the most severe case, shutting down the infrastructure entirely. At this point, the DNS would remain operational, but at a slower pace and only with the default responses of the global root DNS servers.
By leveraging keweonDNS servers, each user, and their device, whether it's a cell phone, PC, or IoT device, automatically becomes part of the artificial neural network. To top it off – none of the user data is required to be collected for this, or even necessary at all. Through the query arises the control, and through the control arises the answer. In this way, sensory control and sensory data transmission occur simultaneously with the DNS query. Based on the term “crowdsourcing”, I have called this process “crowd request sourcing”.
User data collection at keweon?
At this point, I will only briefly outline the matter of data collection and processing, since that would completely go beyond the scope here.
No information is collected from users, devices, or other sensitive data within the scope of the GDPR; rather, the information processed relates solely to the DNS request. In other words, the address, FQDN, host or alias of the DNS request, namely only data that a DNS server possesses inherently, is used for this purpose. It doesn't matter who or what requested the address, only how often an address is queried becomes an additional assessment criterion for the AI. In part, this looks like this:
Spoiler: DNS Counter example
As a result, you can spot things, as seen here on the Apple iPhone, wherein strange DoH resolvers are doing DNS resolution in a hidden way. Apple's commitment to data security and privacy already belongs to the past. Especially, with the implementation of the advertising framework in the iOS operating system, the company is sawing at the branch it is sitting on, in my personal view.
At no time will keweonDNS collect or parse user data. The mistakes made by Jan Koum have taught me a lot. That's why I designed the entire development to make it technically impossible to ever do that. Data is processed only from the “root DNS server” to protect the user's privacy. In this way, “hidden (user) data collection” is prevented and ruled out, even if investors enter the project.
The fact that this is impossible turned out to be something I did not expect, indeed a knockout criterion for investors. Still, my point of view in this regard should be well known. Further details on data protection can be expected on the website in the section “AI & Data Protection”.
How does DNS work at keweon?
It functions not unlike any other DNS server.
Query from your device to DNS: What is the IP address of www.example.com?
DNS looks in the cache. If the response resides there, your device will get the IP address.
If the address is not in the cache, the subsequent (virtual) response occurs:
Wait, I don't know the address, but I do know a DNS server that might be aware of the answer.
Passing the query to the next DNS server (henceforth, it is no longer the IP address of the user who asks the query, instead it's the DNS server).
Passing the query to the root DNS server, which looks up the response. If the root DNS server does not know the response, it returns an NXDomain response, which means “Not existing domain“, or the matching IP address is returned.
The response passes through one or more validations and is then returned to your device as a response via the DNS resolvers.
DNS Mission accomplished.
The so-called “Visible Layer“, which are the DNS servers that you use, respond as DNS, are DNS and do DNS. All they provide is DNS over port 53 – and nothing else. No proxy, no other technology. 100% DNS. Well, companies that offer solutions for DNS-layer security – please keep reading, you may learn something. (#CISCO, #Cloudflare, #Microsoft, #Google, #Apple)
The AI, the so-called “AI Hidden Layer”, is the exciting part. In this context, the term “hidden layer” is used when referring to an AI because the AI itself is never directly addressed and is invisible to the user.
The “AI Hidden Layer” is a self-contained layer, or rather should be, to prevent manipulation or attacks. By far the best example of how an AI should not be built is Microsoft's “Bing AI”. It is reported that the staff there is already busy working on the implementation of AI-provided advertisements and sponsored responses. Effectively, this soon means that whoever pays more has the privilege to manipulate on a larger scale. Like Apple, this clearly shows that mistakes (from the past) are obviously ignored instead of drawing lessons therefrom.
AI and ANN – an architectural overview
The DNS server, the “hidden layer” that enables the entire technology, is shown in the figure:
Spoiler: keweonDNS - an architectural overview
I tried to keep it simple, and I hope it turned out well. If you have any questions – please let me know.
Hidden Layer – how does keweon act as an “artificial bio-neural network”?
We take the address “www.i-net.nx” as an example and assume that this is requested for the first time. The address in question is a “good address” invoking a “bad address” in the background – i.e., “bad.i‑net.nx” via a JavaScript, and so remains invisible to the user. Even though the TLD “.nx” does not exist obviously, we assume that it does.
The query originates from a cell phone and is transmitted to the keweonDNS servers.
Assume that here a fictitious counter starts with 0ms (0 milliseconds).
The DNS server doesn't know the address and passes on this request.
So far, ordinary DNS – now we let the magic begin!
Prior to forwarding, two databases are queried to see if this address is known in the “Allow or Deny” database. Of course not, we assumed a totally unknown and completely unfamiliar address.
The query i-net.nx is now forwarded by the ANN (Artificial Neural Network) to the root DNS servers, which in turn query the global root DNS servers. Within the ANN, this address is “copied” and passes through some checks in parallel, regardless of what is returned as a response.
The query is passed to the keweon root servers, which in turn passes it to the AI and analyzes it via the Pre.Ident process, which works with data such as “Newly Registered Domains”.
Note: “DNS firewalls”, for example, have a feature that blocks all newly registered DNS domains. Basically, pointless, and wrongly implemented – yet companies spend a lot of money on this feature and fill meaningless colorful dashboards with it. All that matters though is that they are colorful and have KPIs – no one questions whether this makes sense.
The security benefit on a scale of 1 to 10 is -10, since this represents a security risk on one side and pretends a “misleading security” on the other side. “Newly Registered Domains” are verified at keweonDNS via the Pre.Ident process and are not blocked across the board.
Spoiler: DNS Pre.Ident process – an overview
The Pre.Ident process performs the initial analysis of the query and is responsible for detecting threats that are emerging or may arise. As mentioned at the beginning, this can also be done with probability theory, for example, but this has proven to be too inefficient and too slow. The current predictions for “bad domains” extend up to 96 hours (4 days) into the future. This is calculated using the HFRA algorithm (High Frequency Research Algorithm), among others.
All AI processes and algorithms, such as Pre.Ident and the HFRA, are completely independent of each other, but support each other or collude.
The idea for the HFRA algorithm initially originated from a good friend, who sadly passed away from a brain tumor in 2017. Harlim was the lead developer for high frequency trading at a large German bank, and he contributed a lot despite his illness. High frequency trading ends with buy or don't buy, or to stay with DNS, block or don't block.
After the Pre.Ident process, the domain is decomposed into FQDN, IP, and Alias and inspected i.e., using the certificate instance. The big secret with the certificates is hence, on the one hand, to assign a positive certificate to all blocked addresses and, on the other hand, to be able to check and classify the DNS data on the fly. This procedure eliminates the need to resort to further DNS data and ensures the (self-)control of the AI.
Meanwhile, the ANN has (pre)analyzed the address and the PAA (Perimeter Analytics Algorithm) checks whether the server contains, i.e., malware or ransomware or whether this server shows other critical or endangering indications.
Whether and how a server, address, or IP is “malicious” is weighed by the various logics. The current criteria catalog includes a total of 1394 so-called matching points, how an address is to be evaluated if it is known, and up to 83 matching points for unknown addresses (floating run), whereby various factors also play a role.
Using fuzzy logic within the AI and with the help of the ANN, not only is it decided whether an address is “good” or “bad”, but also the result “I'm not quite sure” can be generated. This in turn causes a weighting and the ANN decides here “Allow or Deny” – based on further algorithms.
This decision that it is probably a good address is passed to a “returning logic“, evaluated as good, and thus the original IP address is returned to the user. It looks roughly as follows (in excerpts):
Spoiler: DNS Rating example
Let's stop the fictitious counter here (which we started at the beginning) and now, about 20ms (milliseconds) later, the user gets the response.
The returning cycle decides here when and if this address must be examined again, in which level of detail and possibly via a second, third etc. analysis of the address in the background. Different criteria are used depending on the weighting. Some addresses are checked every hour, others every week.
The web page is loaded and, as noted, it contains a JavaScript with the bad address. Since this address has at no time been requested, it is blocked from point 5, at the latest from point 6. The user gets this address returned, but with an IP address that states this address was successfully resolved and passes a virtual “OK” to the browser or JavaScript to make it believe that the address was properly resolved and does not need to be requested again.
If the address has now been resolved, the AI's work continues anyway. The address is reviewed again for a more detailed assessment of the threat posed by the address, as well as its rating. For this purpose, the address gets analyzed in detail in the background using the crowd request sourcing method and the HFRA algorithm. This time the entire program, because now it compares, for example, where the server is located, what the IP address does, what the server does, along with other options, and the results are again compared with other and similar addresses.
For one or two addresses this still sounds logical, but if we now take 20 or 30 addresses, it becomes more complex. The database currently consists of about 960 million addresses.
Summary
This is just a small part of what keweon is all about. Obviously, there is much more, but for now I'm curious to see who copies all this and uses it for their marketing. Admittedly, who knows me a little, understands that this is far from being everything.
The thing I'd like to know from you now:
What do you think about it? How do you rate it? What information do you miss here?
Comments, hints, tips, and questions are welcome and appreciated.
Frequently Asked Questions (FAQs)
As an additional service to help users find certain information quickly, I will compile answers to some frequently asked questions about keweon here and continue to update this post.
Spoiler: keweonDNS Server Addresses and IP's – PRIVATE USAGE ONLY
Certificate:
https://pki.keweon.center
Apple DoH Profile:
https://apple.keweon.center/DOH/dns.mobileconfig
Apple DoT Profile:
https://apple.keweon.center/DOT/dns.mobileconfig
DoH Server Address:
https://dns.keweon.center/nebulo
or
https://dns.keweon.center/dns-query
DoT Server Address:
dns.keweon.center
DNS IPv4:
84.16.252.137
84.16.252.147
DNS IPv6:
2a00:c98:4002:1:8::5
2a00:c98:4002:2:c::80
Spoiler: Find the Post in your Preferred Language
German – Android-Hilfe Forum
Spoiler: The “GOOD OLD” Thread
keweonDNS - now with improved Certificate (iOS, Mac & Android)
Spoiler: PersonalDNSFilter with keweonDNS – PRIVATE USAGE ONLY
Initially, disable any active “Private DNS” in the Android connection settings.
Certificate:
https://pki.keweon.center
In the PersonalDNSFilter app itself:
Open the list of registered DNS servers.
Check the box next to “Disable DNS server discovery - Manual DNS servers as follows:” and activate the slider next to “Text based editing mode” in the section.
Add the following addresses to the displayed list using Copy&Paste:
DoH Server Address:
[178.162.228.115]::443::DOH::https://dns.keweon.center/nebulo
or
[178.162.231.49]::443::DOH::https://dns.keweon.center/dns-query
DoT Server Address:
[84.16.252.138]::853::DOT::pdnsfilter.keweon.center
or
[84.16.252.138]::853::DOT::personaldnsfilter.keweon.center
Next, uncheck the slider next to “Text based editing mode”.
Finally, check the boxes next to the added DNS servers and uncheck all others.
Spoiler: NetGuard with keweonDNS – PRIVATE USAGE ONLY
Initially, disable any active “Private DNS” in the Android connection settings.
Certificate:
https://pki.keweon.center
In the NetGuard app itself:
Located under “Settings” is the interesting “Advanced Options” feature.
Then enter either both IPv4 or IPv6 addresses for “VPN-DNS”:
DNS IPv4:
84.16.252.137
84.16.252.147
DNS IPv6:
2a00:c98:4002:1:8::5
2a00:c98:4002:2:c::80
Note: In order for the IPv6 addresses of the DNS servers to be accessible from your home network, it must be IPv6-capable.
Spoiler: AdGuard with keweonDNS – PRIVATE USAGE ONLY
Initially, disable any active “Private DNS” in the Android connection settings.
Certificate:
https://pki.keweon.center
In the AdGuard app itself:
Tap the “shield icon” at the bottom of the screen and activate the slider in the “DNS Protection” section.
On the same screen, tap the “DNS Protection” label to access the DNS settings.
Located under “Choose DNS Server” is the interesting “Add Custom DNS Server” feature.
Type in “keweonDNS” as the “DNS server name”.
Then enter either DoH or DoT for “DNS Upstream”:
DoH Server Address:
https://dns.keweon.center/nebulo
or
https://dns.keweon.center/dns-query
DoT Server Address:
tls://dns.keweon.center
@MrT69 Greetings. Please check your PM inbox. Thank you.
-Regards: Badger50
another "dns" dev here
This sounds exciting and novel. All the best!
@MrT69 great to se the DNS still going on. I hope you still remember older people
So, how do i set this up on Android using the Adguard app?
Blackeyedangel said:
So, how do i set this up on Android using the Adguard app?
Click to expand...
Click to collapse
Take a look at post #2.
There you can see the spoiler for “keweonDNS server addresses and IP's – PRIVATE USAGE ONLY”.
There you will find all the addresses you need. I don't know the AdGuard app, but I'm pretty sure you know what to use when you see the addresses.
Or just use the Android internal option “Private DNS” and set the “DoT Server” there.
methuselah said:
@MrT69 great to se the DNS still going on. I hope you still remember older people
Click to expand...
Click to collapse
Of cause It's years ago but some people I still remember.
:::UPDATE::: The configurations of AdGuard and NetGuard are added in the FAQ.
Related
Originally Posted by timothyon Saturday October 20, @08:27AM
from the that's-why-they-buy-guns dept.
Trailrunner7 writes "There are thousands of apps in the Google Play mobile market that contain serious mistakes in the way that SSL/TLS is implemented, leaving them vulnerable to man-in-the-middle attacks that could compromise sensitive user data such as banking credentials, credit card numbers and other information. Researchers from a pair of German universities conducted a detailed analysis of thousands of Android apps and found that better than 15 percent of those apps had weak or bad SSL implementations. The researchers conducted a detailed study of 13,500 of the more popular free apps on Google Play, the official Android app store, looking at the SSL/TLS implementations in them and trying to determine how complete and effective those implementations are. What they found is that more than 1,000 of the apps have serious problems with their SSL implementations that make them vulnerable to MITM attacks, a common technique used by attackers to intercept wireless data traffic. In its research, the team was able to intercept sensitive user data from these apps, including credit card numbers, bank account information, PayPal credentials and social network credentials."
Refrence http://yro.slashdot.org/story/12/10...mentations-leave-many-android-apps-vulnerable
I myself have implemented them for shopping apps (SSL for anything dealing with user details, payment, etc.). When you're communicating with an external service that requires (or where you want to use) encrypted connections and that service only offers SSL (this is probably 90% of the time) you need to use it. Now the catch here is that the standard SSL handlers available to you in Android provide an "ideal" setup, where servers and certs are exactly as they "should" be. The problem is unless you are paying rediculous amounts for dedicated SSL services and high quality certs your setup will not be the "ideal", and you'll have to make exceptions by overriding code.
As an example, in the shopping system I set up there were two sets of certs, one set was signed [payment gateway] the other wasn't [user control panel]. I had to jump through a few hoops, and the app would be open for man-in-the-middle if set up right - but luckily all they'd get would be user login details, address and phone number - billing is all external and requires a separate authorization.
As spreading news about the issue among would only be able to protect privacy and crucial information of the consumers
all discussion regarding this issue are being welcomed kindly try to focus to fix this issue
Pronounced "say candy", the goal of SecAndy is to come up with as secure and private of an OS as possible. So as not to reinvent the wheel, we'll base this initiative on our open source code of choice (Android or maybe other developers' choice).
I am not a developer myself but I can without a doubt, because of former professional experiences, organize a project and gather the right people together as a community in order to make sure that project sees the light of day after it has acquired a life of its own if needed, which I think we will agree is something that this kind of project requires because of the scrutiny it will quickly attract.
I am officially calling upon this post all interested developers that could help us fork Android or other open source OS.
Let's get a kickstarter funded and let the party begin. I will update you later today on the advancement of such.
This thread welcomes constructive ideas and developer participation, but here are beginning requirements we'll need to fulfill eventually to privatize and secure android :
- default browser allowing custom search engines such as https://ixquick.com or duckduckgo
- default system search pointing to those custom engines for online component
- control of gps at firmware level to allow full disability
- peer to peer file exchange (think BitTorrent sync) with 1024 to 2048 bit encryption
- implementation of secure sms and mms exchange (think textsecure)
- implementation of encrypted voice channels (think redphone or SIP with end-to-end encryption)
- root vpn for all online access
- systemwide warning of insecure solutions (example : wanting to use gmail or regular email)
- PGP transparent email solution
- Tor option for root vpn (subject to mitm attacks but more on that later)
- peerguardian type auto-updated database to identify suspicious IP address ranges
- systematic in-out firewall control auto updated with peerguardian database and community based rules database
- hardened malware protection and app permissions with automatic permission audit based on application type
- full device encryption and lockup (in case of unauthorized user)
- full remote wipe out and bricking with auto IMEI reporting (in case of theft, might have to be amended because of attack vector)
- full remote location capability with real time tracking (that one might have to be scratched, high security risk because of attack vector)
This obviously doesn't cover all the bases but would be a good start... I know a lot of these options can be implemented with a mismatch of apps and custom Roms but having it all at an OS level AOKP style would greatly help in building an android by the people for the people community that could eventually loosen the stranglehold of less than transparent corporations.
60 views in 24 hours and not one comment. Obviously I'm approaching this the wrong way. More news at 11.
e-motion said:
60 views in 24 hours and not one comment. Obviously I'm approaching this the wrong way. More news at 11.
Click to expand...
Click to collapse
I don't want to be insulting, but no programming work has been done on your part, and you're just asking for people to dive in this project to get managed by someone they never heard of. It's not really surprising no one has commented yet.
I understand what you're saying but any comment, even if only just to show interest in such a project, will be key to drive developers to it.
I might not have started any development but I have clear understanding of how to design secure solutions. I can't go into details of why that is, however you can clearly see with my 2nd post that some research has been done. If I wanted a solution for me alone, I could just go on with my own little pudding of custom ROM and security apps.
However, because of the recent news events that SHOULD have awaken this population, I thought now might finally be the right time to try to get such a project off the ground. But without anyone even showing any interest, why would any developer be drawn to it ? If people would rather focus more on content consumerism than on what might happen under an umbrella of spooks that they're paying for with their taxes, then they have learned nothing from history and deserve what's coming to them, simple as that.
This is NOT a development thread in case you haven't noticed, so telling me I haven't developed anything yet is not even relevant.
In case anyone cares, this will be moved shortly in the t-mobile Note 2 Android development thread as a Touchwiz proof of concept ROM. Little steps, little steps...
Sent from my SGH-T889 using Tapatalk 2
mobile sec
While I am not a developer I would be interested in this project. I've been thinking about this a bit lately given recent events. I think a useful privacy preserving security related app and phone combo might have these features:
-some way to separate the baseband processor (radio) from the OS. It seems most phones share memory with the radio and this fact can and has been exploited. Own the bb processor and you own the phone. Perhaps a 3g dongle plugged into an android phone in host mode would work. Some of these usb "data only" radios can be unlocked for voice too. I believe a rooted phone with IP tables/firewall running would be much more secure than a conventional mobile phone.
-an anonymising network for connecting to servers/peers. I think the i2p network is well suited for this purpose. Rather than connect to services that are not designed with your anonymity/privacy in mind, connect to hidden/darknet servers that make it extremely difficult to ascertain your real IP and location. Perhaps an i2p router running on your home computer relaying i2p traffic while also maintaining a long lived encrypted connection to your mobile in order to "push" data to it. In this way the user benefits from the anonymising network, contributes to the network, but doesn't have the battery drain of relaying packets from the phone (if this is even possible).
-end-to-end encryption. Perhaps OTR messaging for texting and perhaps openPGP for transferring binary files as I don't believe file transfer in OTR is available at this time.
-an app that uses the above network that is capable of sending/receiving encrypted text, audio, video, gps location etc and does not leak any personal information that you don't want leaked. XMPP might be a good choice (with perhaps out-of-band binary transfers for efficiency). Giving your unique identifier to another person that is using the same app would allow you to communicate with them while not revealing your phone number, imei, imsi, etc. There would be some latency in the communication especially with binary transfers but I would gladly accept that for the added security.
anyway, just wanted to add this to the conversation and hope to see this project take shape as we definitely need more security enabled os's and apps.
Private DNS has been around for a little bit on newer devices. However, finding a service that provides both the Private DNS side (TLS) and ad-blocking, filtration of bad domains, etc., has been another whole mess.
I've launched a donation-backed Private DNS service which provides an internet-side option. Think pi-hole style blocking without needing a VPN or only working from your LAN.
What's this entail?
1. Running Android Pie (or anything with the feature ported to it)
2. Using a custom Private DNS Server address that I will provide.
What happens?
1. Your DNS requests are routed via DNS-over-TLS to my CDN virtual machines.
2. Your DNS requests are then locally processed through several internal systems including the infamous Pi-Hole.
3. Final data requests from the local resolver are forwarded via DNS-over-HTTPS to root DNS servers such as 1.1.1.1 and others that are found to support HTTPS protocol.
4. No personal data is stored. Only data with respect to filtration is stored such as blocked versus permitted domains, hit/misses, and caching statistics to continue to develop a more fluid system.
What do I do?
Put "DNS.DEREKGORDON.COM in your Private DNS settings for Android.
Use IP address 35.243.170.151 for other applications to include your home network router, ChromeOS, etc.
Like it? CONSIDER DONATING. This system is kicking out almost one million responses a day for users.
More information is at http://www.derekgordon.com/dns/.
Always provide THANKS no matter what folks. It's the nice thing to do....
So we are looking at a encrypted dns with ad blocking? I would be into trying that.
I'm using dns.agduard.com at the moment on my Huawei P20 pro running Android pie.
Have a number of people using it without issue now....
Check it out here:
https://www.derekgordon.com/dns
crypted said:
Have a number of people using it without issue now....
Check it out here:
https://www.derekgordon.com/dns
Click to expand...
Click to collapse
I'm gonna check it out
Cool. Give it a go. My only concern now rests with the attack prevention stuff I've added. It rate limits and bans those who are hitting the server or servers if expanded quite hard. Basically it's to ward off attackers. Anyway no bad reports from it but it's the only factor I'm not totally sure of.
Gonna give it a shot and give you my results in 24hrs.
Cool. I have zero issues on our family's Pixel 2s and 3s. No one said much bad except someone who had login issues on an Xbox when they used the system for their network's DNS. I solved that for them.
Note I'm not filtering Google ads domain as a few people complained since they click the first couple links on Google. I haven't felt intruded upon by ads with this change since making it a couple weeks back.
hi,
sometime i can use this dns, sometime cannot.
my mi 8 using baskalos rom stated coudlnt connect.
issit because of my isp?
Very strange. No one has reported that issue. Is it the same result on WiFi vs mobile data? Want to give me your IP to search logs?
I've used the server in four countries on various WiFi and mobile netwiens without issue on Pixel 3.
How did you get the Private DNS in android Pie to recognize your dns server? I've got my own pi-hole server, yet when I put in my FQDN, I lose internet access on my phone.
First, I don't use Pi-Hole only. I made a custom Debian image and deployed it into the world of CDN. Pi-Hole's opensource software was incorporated as one of my mechanisms for blacklists.
To your point on connection, you need two things: 1) a TLS server to establish the connection and 2) signed certificates for the domain you are using installed on your server. Android will connect via TLS and will verify that your certificate is valid against its root certificates on the device.
Happy note - my server is providing over 250,000 queries daily now and over 90% connect via TLS so that indicates lots of happy Android users.
I'm check yours out and see how well it compares to the VPN connection I currently use to my pihole.
Been loving your Private DNS so far. Great job on it. Question though, do you have a form or something for people to submit domains that are blocked and shouldn't be?
Hey. Feel free to tell me these domains. There is such high usage and hardly any feedback so I haven't even thought about it. I could make a Google Form later.
Actually, I had a spare moment at lunch. Try this: https://forms.gle/oGtAFKAc7yJPmmEZ6
crypted said:
Actually, I had a spare moment at lunch. Try this: https://forms.gle/oGtAFKAc7yJPmmEZ6
Click to expand...
Click to collapse
Was gonna request https://go.redirectingat.com be unblocked since many many sites use it to link to products on sites like Walmart and Amazon. Can't use that form though since you require a screenshot URL, and I can't screenshot a redirection site.
You figured out a good workaround to make your request. Processing now, give it a minute and should be good.
All of your requests are cleared if you didn't notice yet. Happy browsing.
Not really sure how to publicize this and it probably isn't worth trying to do... But for those who do use this, and there are plenty of folks, I have been working on some changes.
1. These will not work with Android as I don't have the extra cash to blow on more SSL certificates. But, they will work for home networking purposes:
US.EAST.DNS.DEREKGORDON.COM
US.WEST.DNS.DEREKGORDON.COM
DE.FRUNKFURT.DNS.DEREKGORDON.COM
BR.SAO.DNS.DEREKGORDON.COM
2. DNS.DEREK.GORDON.COM is now a pool of a number of VM instances that are connected to Google's CDN. It will grow as necessary. This helps spread out some of the intensity that has been hitting the TLS daemon.
3. Servers will automatically reboot between once a week to every other week depending on load and latency. Sometimes the intense flood of queries really makes things sluggish. Reboot takes just a few seconds and I'm working for it to time it during off-peak hours so hardly anyone will notice.
Hi, I have my own pihole installed on aws server. Could you please share tutorial how could i make it work with private dns in android pie. Thanks.
Firstly some little rant about keweon which is the most hypocrite security service I've ever seen:
[
The mentioned bet was with me. PM for details or public if you make me care enough.
>Copypasting all the elaborate posts from the Telegram sphere as I cant bother to spend much time on it.
I mostly agree with whats written there.
Seriously I dont care about Thorsten (MrT69) personally or in any other way.
I am actually quite sick of this topic. Even mad that I have to deal with basic **** like that. These people managed to trigger a hermit into logging on to tracking heavy XDA.
Why I do this? It needs to be done.
I could have never imagined that such a blatant scam could gain enough traction that it regularly annoys me.
]
<<< A little bit of ranting about keweon >>>
"
Evidence and proof of concept that keweon Online Security is not as secure as claimed by its developer.
After a group of independent IT and cyber security specialists proved that keweon is not as secure as claimed by the developer, they confronted the developer with the results and reminded him of a bet. All keweon support groups on TG then were deleted by the developer personally and without further explanation on the morning of February 4, 2019.
We all know by now that the way keweon DNS works is based on users using keweon's DNS and the keweon root certificate.
What has now been proven is exactly what keweon could do with its users, but Torsten vehemently denies and claims "that's impossible" and "that doesn't work":
1. get users to use your DNS server.
2. get users to use your root certificate.
3. redirecting a page, e.g. mybank.com, to one of the keweon servers (by changing the DNS record)
4. issue your own SSL certificate for the website, users have installed your Root-CA and so this is not a "witch work"
5. read username/password from the connection (if 2FA is used, just wait until the user logs in and use the token again quickly as it is valid for 30 seconds).
We now have proof that this is possible without a doubt. In fact, this is a classic MITM attack, and anyone who denies that it is possible either has no idea (you shouldn't assume this from Torsten) or is trying to hide something from his users.
The developer of keweon has repeatedly asserted and insisted that a root certificate cannot intercept connections or collect data.
Quote from the keweon developer with his PayPal bet:
"Prove that to me. Give me any DNS and a root certificate and try to get my PayPal data.
I'll then even contact you when I sign up for PayPal. If you manage to get my PayPal data this way, you can log in and transfer 500 Euro to your account. I have made this offer very often and this is a serious offer from my side."
Unfortunately the developer of keweon didn't contribute his part to the test as he promised so often and of course he didn't log into Paypal via our provided DNS and root certificate.
The only reaction on his part was, apart from some insults, the deletion of all keweon groups on TG.
The security test of the keweon servers also revealed that under certain conditions connections are even redirected to keweon's own termination server and answered with 1x1 pixel gifs.
The fact is that the requests contain tracking IDs that can be easily managed from these servers.
So even Torsten's statement that the keweon SSL server only terminates requests with empty (0 byte) responses is wrong.
This again contradicts Torsten's own statement.
The point now is that the developer of keweon Online Security is actively trying to deny that it is possible for him to abuse the root certificate, although it has now been proven that it is actually possible for him to do exactly that with the keweon root certificate and its users.
Until the developer decides to disprove the accusations made against keweon Online Security or can prove that the accusations against him are unfounded, it is advisable for obvious reasons of security not to use keweon Online Security for the time being.
Anyone who is interested in repeating this test can do so at:
http://https-interception.info.tm/, where you will find a DNS and a root certificate, same as with keweon Online Security.
Furthermore there is a real-time log about recorded connections.
Everything else can be found there.
Please be careful not to use your correct email address or password for this test!
#keweon #test #bet #evidence #ProofOfConcept
"
<<< /rant >>>
<<< Explanation of some DNS and TLS/HTTPS basics for noobs >>>
DNS And Root Certificates - What You Need To Know
e8aebe8eb8b24035ae75260ca0ea80a7 / 20190205
Due to recent events we felt compelled to write an impromptu article on this matter. It's intended for all audiences so it will be kept simple - technical details may be posted later.
1. What Is DNS And Why Does It Concern You?
DNS stands for Domain Name System and you encounter it daily. Whenever your web browser or any other application connects to the internet it will most likely do so using a domain. A domain is simply the address you type: i.e. duckduckgo.com. Your computer needs to know where this leads to and will ask a DNS resolver for help. It will return an IP like 176.34.155.23; the public network address you need to know to connect. This process is called a DNS lookup.
There are certain implications for both your privacy and your security as well as your liberty:
- Privacy
Since you ask the resolver for an IP for a domain name, it knows exactly which sites you're visiting and, thanks to the "Internet Of Things", often abbreviated as IoT, even which appliances you use at home.
- Security
You're trusting the resolver that the IP it returns is correct. There are certain checks to ensure it is so, under normal circumstances, that is not a common source of issues. These can be undermined though and that's why this article is important. If the IP is not correct, you can be fooled into connecting to malicious 3rd parties - even without ever noticing any difference. In this case, your privacy is in much greater danger because, not only are the sites you visit tracked, but the contents as well. 3rd parties can see exactly what you're looking at, collect personal information you enter (such as password), and a lot more. Your whole identity can be taken over with ease.
- Liberty
Censorship is commonly enforced via DNS. It's not the most effective way to do so but it is extremely widespread. Even in western countries, it's routinely used by corporations and governments. They use the same methods as potential attackers; they will not return the correct IP when you ask. They could act as if the domain doesn't exist or direct you elsewhere entirely.
2. Ways DNS lookups can happen
2.1 3rd Party DNS Resolvers Hosted By Your ISP
Most people are using 3rd party resolvers hosted by their internet service provider. When you connect your modem, they will automatically be fetched and you might never bother with it at all.
2.2 3rd Party DNS Resolver Of Your Choice
If you already knew what DNS means then you might have decided to use another DNS resolver of your choice. This might improve the situation since it makes it harder for your ISP to track you and you can avoid some forms of censorship. Both are still possible though, but the methods required are not as widely used.
2.3 Your Own (local) DNS Resolver
You can run your own and avoid some of the possible perils of using others'. If you're interested in more information drop us a line.
3. Root Certificates
3.1 What Is A Root Certificate?
Whenever you visit a website starting with https, you communicate with it using a certificate it sends. It enables your browser to encrypt the communication and ensures that nobody listening in can snoop. That's why everybody has been told to look out for the https (rather than http) when logging into websites. The certificate itself only verifies that it has been generated for a certain domain. There's more though:
That's where the root certificate comes in. Think of it as the next higher level that makes sure the levels below are correct. It verifies that the certificate sent to you has been authorized by a certificate authority. This authority ensures that the person creating the certificate is actually the real operator.
This is also referred to as the chain of trust. Your operating system includes a set of these root certificates by default so that the chain of trust can be guaranteed.
3.2 Abuse
We now know that:
- DNS resolvers send you an IP address when you send a domain name
- Certificates allow encrypting your communication and verify they have been generated for the domain you visit
- Root certificates verify that the certificate is legitimate and has been created by the real site operator
How can it be abused?
- A malicious DNS resolver can send you a wrong IP for the purpose of censorship as said before. They can also send you to a completely different site.
- This site can send you a fake certificate.
- A malicious root certificate can "verify" this fake certificate.
This site will look absolutely fine to you; it has https in the URL and, if you click it, it will say verified. All just like you learned, right? No!
It now receives all the communication you intended to send to the original. This bypasses the checks created to avoid it. You won't receive error messages, your browser won't complain.
All your data is compromised!
4. Conclusion
4.1 Risks
- Using a malicious DNS resolver can always compromise your privacy but your security will be unharmed as long as you look out for the https.
- Using a malicious DNS resolver and a malicious root certificate, your privacy and security are fully compromised.
4.2 Actions To Take
Do not ever install a 3rd party root certificate! There are very few exceptions why you would want to do so and none of them are applicable to general end users.
Do not fall for clever marketing that ensures "ad blocking", "military grade security", or something similar. There are methods of using DNS resolvers on their own to enhance your privacy but installing a 3rd party root certificate never makes sense. You are opening yourself up to extreme abuse.
5. Seeing It Live
5.1 WARNING
A friendly sysadmin provided a live demo so you can see for yourself in realtime. This is real.
DO NOT ENTER PRIVATE DATA!
REMOVE THE CERT AND DNS AFTERWARDS
If you do not know how to, don't install it in the first place. While we trust our friend you still wouldn't want to have the root certificate of a random and unknown 3rd party installed.
5.2 Live Demo
Here is the link: http://keweonbet.info.tm/
- Set the provided DNS resolver
- Install the provided root certificate
- Visit https://paypal.com and enter random login data
- Your data will show up on the website
6. Further Information
If you are interested in more technical details, let us know. If there is enough interest, we might write an article but, for now, the important part is sharing the basics so you can make an informed decision and not fall for marketing and straight up fraud. Feel free to suggest other topics that are important to you.
For more information/feedback/corrections visit our chat linked in the pinned post. (Search ID 0728e516cf2446e7b25af7622c26d8d + 5 in case you hid it.)
All content is licensed under CC BY-NC-SA 4.0. (Attribution-NonCommercial-ShareAlike 4.0 International https://creativecommons.org/licenses/by-nc-sa/4.0/)
- DNS resolvers send you an IP address when you send a domain name
- Certificates allow encrypting your communication and verify they have been generated for the domain you visit
- Root certificates verify that the certificate is legitimate and has been created by the real site operator
How can it be abused?
- A malicious DNS resolver can send you a wrong IP for the purpose of censorship as said before. They can also send you to a completely different site.
- This site can send you a fake certificate.
- A malicious root certificate can "verify" this fake certificate.
This site will look absolutely fine to you; it has https in the URL and, if you click it, it will say verified. All just like you learned, right? No!
It now receives all the communication you intended to send to the original. This bypasses the checks created to avoid it. You won't receive error messages, your browser won't complain.
All your data is compromised!
4. Conclusion
4.1 Risks
- Using a malicious DNS resolver can always compromise your privacy but your security will be unharmed as long as you look out for the https.
- Using a malicious DNS resolver and a malicious root certificate, your privacy and security are fully compromised.
4.2 Actions To Take
Do not ever install a 3rd party root certificate! There are very few exceptions why you would want to do so and none of them are applicable to general end users.
Do not fall for clever marketing that ensures "ad blocking", "military grade security", or something similar. There are methods of using DNS resolvers on their own to enhance your privacy but installing a 3rd party root certificate never makes sense. You are opening yourself up to extreme abuse.
5. Seeing It Live
5.1 WARNING
A friendly sysadmin provided a live demo so you can see for yourself in realtime. This is real.
DO NOT ENTER PRIVATE DATA!
REMOVE THE CERT AND DNS AFTERWARDS
If you do not know how to, don't install it in the first place. While we trust our friend you still wouldn't want to have the root certificate of a random and unknown 3rd party installed.
5.2 Live Demo
Here is the link: http://https-interception.info.tm
- Set the provided DNS resolver
- Install the provided root certificate
- Visit https://paypal.com and enter random login data
- Your data will show up on the website
6. Further Information
If you are interested in more technical details, let us know. If there is enough interest, we might write an article but, for now, the important part is sharing the basics so you can make an informed decision and not fall for marketing and straight up fraud. Feel free to suggest other topics that are important to you.
For more information/feedback/corrections visit just PM the poster here.
He activated Mail forwarding.
All content is licensed under CC BY-NC-SA 4.0. (Attribution-NonCommercial-ShareAlike 4.0 International https://creativecommons.org/licenses/by-nc-sa/4.0/)
I appreciate you taking the time to write this up.
After reading this, im a bit scared because yesterday i installed both the dns and cert from keweon and since then i logged into bank accounts and several important sites (apps and browser).
Is this really that bad? Is keweon creator really capable of stealing users data just by using a custom dns and cert?
2 yrs later the same s**t again?
I'm honored about the fact that you try to fight against keweon. It seems you are someone from the advertising industries and this statement is almost the same as you have started the big ****storm against me 2 yrs ago.
Did you ever talk about the 46 Root Certificates within Windows which are responsible to share Ransomware, Malware, Spyware and other crap? No.
Did you ever talks about all the Apps which are using hidden root certificates to spy user data? No.
Did you ever talk about custom ROMS which contains hidden Root Certificates? No.
But you are still fighting against me? What will ever happens when I would shut down keweon?
keweonDNS is cleaning up the internet for various threats and of cause advertising. Because of blocking this it's causing HTTPS errors. To suppress this errors I have developed this Root Certificate. At the moment everything is still just for testing and when I launch the "real Infrastructure" there will be definitely a different Root Certificate.
You can use the DNS even without the certificate. Where is the problem? It's not a need or a must to use it but then Adblock detection is possible and a lot of other things. All addresses outside are working via HTTPS and the only reason for this certificate is to prevent HTTPS errors caused by Adblocking. I was asking you for a better Idea - no answer. Even various data protection agreed to me that this is a good Idea to protect against data collections.
I'm 100% sure you are someone from the advertising industries because until today you are only talking about common things that "might" happens or that "can" happens or "possibilities". In the meantime a lot of companies are using keweonDNS and there are some big Companies and this will definitely show that you have no idea about HTTPS and how it is working.
I repeat again. Using keweonDNS is cleaing up the internet within an incredible way. If you want to have everything faster or if you want to suppress the upcomming HTTPS errors cause by Adblocking YOU CAN USE the Certificate. It's not a MUST HAVE. But if you ever have a better Idea to fight against data collection and privacy violation without a certificate then any idea is welcome. That's the reason why it's still a TEST SYSTEM.
This certificate suppress all Adblock detections and data collections. Why you don't talk about this? Why you only talk about this is possible and that is possible? Why you don't write about the actual facts? Why you don't write about the things which are possible with the certificate?
In the meantime there are worldwide 32 million users who are using keweonDNS. Do you honestly think I didn't expect someone to try a ****storm against me or keweon? keweonDNS is a war declaration against Google, Facebook, Microsoft, Yahoo and the entire worldwide ads industry and you are talking about evil things what "might" happens? But hey, it's OK for me
I still offer to you - if you have a better idea let's do it together. I'm open for any idea or help. If you still want to fight against me then this shows me you support Google, data collection and privacy violation.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
RethinkDNS is an anti-internet censorship tool with DNS-based adblocking and a firewall built-in for Android 6+ devices.
The app itself is free to use and comes with RethinkDNS (previous name BraveDNS) resolver with support custom denylists, allowlists, ability to store DNS logs for later analysis, view those logs consolidated from multiple devices in a single interface and so on: Pretty much a pi-hole in the cloud.
Why'd we build this?
As concerned Android users: It absolutely irks us that people who do care enough about privacy still couldn't use privacy-enhancing apps without requiring a degree in computer science. We saw this pattern unfold multiple times and a lot of tools over the years have done a tremendous job of making niche security tools accessible to naive users. We wanted to further that conversation on Android with a vision for what we think such a tool should look like:
1. Anti-censorship: Enable open internet. DNS over HTTPS (and the imminent ESNI standard) is going to effectively break censorship as implemented in a lot of countries without requiring to route the traffic through VPNs. VPNs (and distributed tech like IPFS and mesh networks like Lantern) are still required in countries that employ Deep Packet Inspection. That's something we'd like to tackle in the near future.
2. Anti-surveillance: Expose apps, their activity logs, network logs, and provide some actionable insights to the users on what they could do next. Exodus Privacy does a good job at statically analyzing an app and laying bare the trackers and permissions in-use, whilst the evergreen NetGuard does ever-so-well in revealing an app's connectivity history. We believe, there's a lot more that can be done than simply firewall an app: For instance, you could disable it, uninstall it, remove its permissions, remove the so-called special permissions (like read notification permission, read SMS permission, read app-usage statistics permission etc). Basically, empower the user with whatever control is available without-root in a neat little interface (think CleanMaster vs using the stock Settings app but being actually effective and not lie).
The current version of RethinkDNS (previous name: BraveDNS) is a start in the direction laid out above partly because we want such an app ourselves and partly because we feel people deserve more such tools, and we hope to build it with this community's input, because god knows we have been wrong plenty when it comes to "what people really want".
As privacy enthusiasts: We were frustrated that if we wanted to use NetGuard we couldn't use another VPN app, or if we wanted to use a DNS changer like Blokada then we couldn't use NetGuard (though, NetGuard + Private DNS feature alleviates the problem on Android 9+). We wanted something that wasn't as restrictive because we knew it could be built and so we did.
Key points:
1. Easy configuration.
2. No root required.
3. Free and open source (forked from Intra).
4. No built-in trackers or analytics.
5. In continuous development.
Current features:
1. DNS over HTTPS (circumvent censorship and prevent surveillance of DNS logs by ISPs and everyone else), DNSCrypt v2 with Anonymized Relays, and DNS over Tor.
2. View DNS logs, including latencies and other metadata.
3. Ad-block through RethinkDNS (previous name: BraveDNS) free resolver and local blocklists.
4. Add your own DNS over HTTPS / DNSCrypt v2 servers.
5. Firewall by app categories.
6. Firewall individual apps.
7. Firewall individual IP addresses.
8. Firewall when apps are in the background (not-in-active-use).
9. Firewall when device is locked.
10. Forward DNS and TCP connections to Orbot (Tor as a proxy).
11. Forward HTTP connections to any HTTP proxy.
12. Forward TCP connections to any SOCKS5 endpoint or to Orbot.
13. Forward DNS connections to any app running locally on-device or any endpoint (either local or on the Internet).
14. [v053g / Sep '21] Firewall when apps bypass DNS (for example, block connections to IPs that apps resolve themselves).
15. [v053g / Sep '21] Pause: Pause the Firewall and DNS for a brief time-period.
16. [v053g / Sep '21] DNS Trap: Proxy all requests made on Port 53 to user-set DNS endpoint (for instance, this traps and redirects all custom DNS requests WhatsApp sends to Google's `8.8.8.8` DNS servers to the DNS endpoint of a user's choice).
17. [v053i / Jul '22] IPv6 support.
18. [v053i / Jul '22] Firewall based on metered (LTE) or unmetered connection (Wifi).
Planned (in order):
0. Custom DNS allowlists/denylists.
1. WireGuard VPN integration.
3. Per-app DNS and VPN (route traffic to multiple VPNs / DNS based on which app is making those connections).
See: github/celzero/rethink-app/feature-backlog.
We can't emphasize this enough: Let us know what you'd like to see us build and more importantly what'd make this tool use-able for other Android users who care enough but aren't as tech-savvy.
If you'd like to contribute, please feel free to send pull requests our way.
Thanks.
---
Source: github/celzero/rethink-app
Website: rethinkfirewall.com
Blog: blog.rethinkdns.com
Twitter: twitter.com/rethinkdns
FAQ: rethinkdns.com/faq
License: Apache 2.0
Download: via RethinkDNS.com | PlayStore | F-Droid.
---
Reserved.
pls add system apps block on firewall, also block domain on dns log and dns server change
Thanks.
System apps: Good catch. We'd look to put that in the coming days.
DNS block button against a domain in the logs: We do plan add that but not sure if it ends up violating PlayStore terms. May be we need two versions, one for f-droid and another for PlayStore like Blokada has.
Can you elaborate what you mean by block domain on DNS server change?
ignoramous said:
Thanks.
System apps: Good catch. We'd look to put that in the coming days.
DNS block button against a domain in the logs: We do plan add that but not sure if it ends up violating PlayStore terms. May be we need two versions, one for f-droid and another for PlayStore like Blokada has.
Can you elaborate what you mean by block domain on DNS server change?
Click to expand...
Click to collapse
block/allow individual domains which are showed by log.
change dns servers just like nebulo app.
also proxy on tor n dnscrypt support like invizible-pro app.
> change dns servers just like nebulo app.
Dnscrypt shouldn't be much trouble to implement but I wonder what extra protection it affords over DNS over HTTPS. That said, I've added it to our backlog.
> block/allow individual domains which are showed by log.
Gotcha but as mentioned before I am not sure if this feature breaks PlayStore terms. Added.
> also proxy on tor n dnscrypt support like invizible-pro app.
Yes! This is something that we want to do next. Once the part with Firewall and DNS is done (our immediate attention is adding missing features and later add support for Android 6+). Thanks for the heads-up: invizible-pro looks great, and exactly the kind of app that we envision to build ourselves.
Is this affiliated in any way with https://brave.com/?
No it isn't affiliated with brave.com.
We won a grant from Mozilla Builders, however; to pursue this, which we are now doing so full-time.
Hello, I am on a stock Pixel 2 XL, Android 10, latest security patches as of August. The app starts and runs, but tapping the start circle does nothing. DNS or Firewall doesn't start.
So this still exposes one's real IP address, yes?
y0himba said:
Hello, I am on a stock Pixel 2 XL, Android 10, latest security patches as of August. The app starts and runs, but tapping the start circle does nothing. DNS or Firewall doesn't start.
Click to expand...
Click to collapse
Strange. This is unlikely related to Pixel or the latest Android Oreo update. Please check if any other VPN app has been set to "Always-on VPN" like-so (also see attached):
1. Settings -> Wifi and internet -> VPN.
2. Click on the sprocket icon against the apps.
3. Check if "Always-on VPN" is check-marked.
Disable that setting (if and only if you do not want that VPN app to be an "Always-on VPN") and BraveDNS should now prompt you for VPN access once you click "Start".
BraveDNS (or any app that requires VPN API access to function) cannot work with other VPN apps in-tandem (especially, not with "Always-on VPNs").
pocholo36 said:
So this still exposes one's real IP address, yes?
Click to expand...
Click to collapse
Yes, BraveDNS isn't a VPN service like ProtonVPN / Mullvad / Lantern etc are. Right now (though we do have plans to add VPN servers like Lantern et al in probably two to three months from today but that'd be only to support anti-censorship and not anonymity). See: https://github.com/celzero/brave-android-app/issues/52 and https://github.com/celzero/brave-android-app/issues/51
We're adding support for SOCKS5 and HTTPS-Proxy in the upcoming release (next week) which would help forward traffic to VPNs (like NordVPN) that support those protocols: https://github.com/celzero/brave-android-app/issues/45
Right now, BraveDNS uses VPN access on-device to change DNS and implement Firewall functionality (similar to what the excellent NetGuard app does).
ignoramous said:
Yes, BraveDNS isn't a VPN service like ProtonVPN / Mullvad / Lantern etc are. Right now (though we do have plans to add VPN servers like Lantern et al in probably two to three months from today but that'd be only to support anti-censorship and not anonymity). See: https://github.com/celzero/brave-android-app/issues/52 and https://github.com/celzero/brave-android-app/issues/51
We're adding support for SOCKS5 and HTTPS-Proxy in the upcoming release (next week) which would help forward traffic to VPNs (like NordVPN) that support those protocols: https://github.com/celzero/brave-android-app/issues/45
Right now, BraveDNS uses VPN access on-device to change DNS and implement Firewall functionality (similar to what the excellent NetGuard app does).
Click to expand...
Click to collapse
I've been looking for an all in one solution. Currently forced to use AdGuard+Nord...
Looking forward to it. Thanks for all you guys do.
Thanks. Nice work.
Unfortunately, it usually comes down to firewall or VPN
Would love to see what you guys do (if at all) to allow third party VPNs
My brief experience with this is not great. Breaks several apps once turned off the app no longer opens so has to be uninstalled to turn it back on. Ad blocking did not seem to function at all.
ignoramous said:
Strange. This is unlikely related to Pixel or the latest Android Oreo update. Please check if any other VPN app has been set to "Always-on VPN" like-....
Click to expand...
Click to collapse
That fixed it. I should have figured as much, but I'm getting too old for this I think. I can't wait until you offer subscriptions! This is brilliant. I hope it's on the up and up though, I'm paranoid so don't mind me.
bladestonez said:
My brief experience with this is not great. Breaks several apps once turned off the app no longer opens so has to be uninstalled to turn it back on. Ad blocking did not seem to function at all.
Click to expand...
Click to collapse
So sorry this app has forced you to uninstall apps in order to use them. That definitely sounds like something went wildly wrong.
Would you please tell us more about the device, the Android version, and probably the list of steps that led to this issue you saw? You could also email us logs or a screen recording at [email protected]
We do know of crashes especially on flaky networks and on network changes, and we would eventually fix those but they have been extremely hard to track-down in production builds to a root cause (due to lack of stack trace / debug symbols for native crashes).
BraveDNS has been in development for a total of 2 months and was released three weeks back. It is a baby app and I fully expect stupid bugs to appear in the wild but cautiously hopeful that we'd fix most if not all.
Re: adblocking:
Adblocking is done exclusively through DNS. If the default endpoint doesn't work, you can point the app to a custom DNS over HTTPS endpoint. https://dns.adguard.com/dns-query is AdGuard's content blocking DNS endpoint. And https://doh.pi-dns.com/dns-query is another volunteer-run content-blocking DNS.
How is this different from adguard?
Using a VPN method to firewall on a rooted device is a no from me (i can totally understand if you use this to increase your userbase to non-root users, but thats not for me), ill stick with Invisible (for DNSCrypt & its ability to load my 19Mb blacklist) and my root firewall for now.
Really need to change the name.
Brave = Brave Browser
A lot of people are going to assume it's a VPN by Brave.
It's like calling it FirefoxVPN.