Bravedns is a fast, secure, private, transparent, configurable DNS resolver and a firewall. A DNS resolver is an address book of the internet-- it helps locate IP addresses of the servers given a domain name. For example, dns.google.com (a domain name) is located at 8.8.8.8 (IP address). This mapping is retrieved by a DNS resolver.

• Fast: With end-to-end median latency as low as 30ms, our resolver is quite fast, though not the fastest. Primary reason is that the resolver runs in over 200+ locations worldwide in Cloudflare’s data centers, and the user requests are routed to the closest possible server.
• Secure: Security means a lot of different things to different people. Bravedns is secure in the sense it only responds over TLS, a secure protocol that underpins the world-wide web. This means primarily two things: The Internet Service Providers and the Governments could no longer track your browsing behaviour through DNS requests that were previously sent in plain-text; and it helps overcome DNS Manipulation Attacks that are widely employed to censor the Internet in most countries.
• Private: Each user gets their own endpoint which pretty much functions as if the resolver was setup and running solely for the user.
• Transparent: The resolver, optionally, can send per-user logs for analysis, and to generate analytics and reports; so a user can see what’s up.
• Configurable: Users can choose from preset blocklists to define firewall rules according to their preferences.

Bravedns companion app for Android doubles up as a firewall and includes rules such as, block apps by category, block when app is in the background, block an app when device is locked, or block an app forever.

It isn’t a VPN, at least not yet. Though, it is effective in circumventing internet censorship in most if not all countries. Bravedns uses VPN APIs to only route the DNS traffic and not the actual internet traffic.

Bravedns isn’t a tracker. Bravedns logs DNS requests if a user opts-in. Bravedns doesn’t sell any user information or use it for anything else other than to provide analytics and reports to the user.

Bravedns is a stub resolver, and not a recursive resolver-- bravedns forwards user requests to another recursive resolver like Cloudflare’s 1.1.1.1 or Quad9’s 9.9.9.9, but does so in a way that doesn’t reveal who really the actual user is. Think of it like a proxy resolver that sits in-between a recursive resolver and you, the user.

Yes, bravedns functions are similar to a pi-hole and it "blocks content" by blackholing traffic intended for certain domains. Most operating systems, including Android and Windows, resolve DNS requests on behalf of apps installed on the device (though this isn’t strictly always true that apps use OS or network provided DNS resolver, it mostly is). If these DNS requests are blackholed, it effectively means every app on the device is then unable to initiate a connection to that domain, since an IP address is required to establish such a connection in the first place, which wasn't supplied by the DNS resolver. For example, if one chooses to block all requests to facebook.com, bravedns would simply return 0.0.0.0 as the IP Address for facebook.com, effectively blackholing the traffic from all apps installed on the device to facebook.com, for example. Read more.

Bravedns, the resolver, is running in 200+ locations world-wide. Bravedns, the app (if you’ve installed it), should be on your Android.

DNS requests aren’t encrypted today. DNS over HTTPS is simply DNS traffic tunneled within HTTPS. This has the benefit of not only bypassing most firewalls but being fast and secure at the same time. Again, security isn’t really about just the traffic flow, but DNS over HTTPS is a good start towards a more secure internet infrastructure. Mozilla Firefox, Google Chrome, Microsoft Windows all support DNS over HTTPS out-of-the-box or will do so in the near future. Read more.

DNS over TLS is quite simply DNS connections encrypted with the TLS protocol. This protocol is arguably better than DNS over HTTPS in the sense that it isn’t really abusing another protocol to transport its own payload, and sticking to the original vision of seven OSI layers describing an ideal network stack. Read more.

Eventually, yes. It is a top priority item, but requires its own merry time to implement, especially given the current infrastructure that is exclusively HTTPS-only which gives us a bit of an advantage with respect to powering not only a highly accessible backend but also a highly available one. We expect to see no availability issues with the current infrastructure whatsoever (given that software bugs don’t take the resolver down). We take availability very seriously and continuously look to mitigate as many availability threats we encounter (the “known knows”).

Choose form a predefined set of blocklists that power some of the most popular content-blockers on the web. These blocklists define rules to firewall traffic to a predetermined and vetted set of endpoints, usually that of spyware, malware, and ransomware web properties. If you’re on Android, install our app to use bravedns. On other platforms, use a DNS over HTTPS client and point it to bravedns endpoint specific to you (this is visible after you sign-up for the service).

The steps are a bit involved, we ought to release a Firefox extension but until then:

1. Go to Preferences. Scroll to Network Settings, and click on Settings.
2. Check Enable DNS over HTTPS.
3. Set Use Provider to Custom.
4. Type in the bravedns endpoint specific to the signed-in / registered user.
5. Make sure by visiting about:config that network.trr.mode is set to 3 (the default is 2, which results in Firefox leaking DNS queries to System resolver).

We continue to add blocklists based on user-requests. Please write to us, and we would add yours too. Please note that due to inherent complexity in supporting regular expression (wildcard) based lists, we currently may not be able to add them, but don’t let that stop you. Let us know if it is a deal-breaker for you. We promise, we’d try everything to make it work.

Bravedns is ways off being a bullet-proof content blocker. There, unforunately, are many scenarios where content simply couldn’t be blocked by bravedns. Some companies take extensive measures to evade content-blocking of which, perhaps, DNS based content blocking remains easy to circumvent, but despite that, not many apps employ tactics to counter it, but some popular ones do, like instagram and youtube.

Adding support for custom blacklists and whitelists is a top-priority item and we are actively working on it.

No, we don’t, yet, but we are working on it as we speak. Btw, DNSCrypt-Proxy does and we recommend checking the project out.

For support queries, please reach out to us with more information.

bravedns needs to provision an end-point per user, and registration provides a way to do so without being subject to incessant spam. bravedns' services are not free (though it does have a free-tier), and an account is required to bill the user for services consumed.

On-device firewall is free. The in-the-cloud bravedns content-blocker is not. Currently, pricing isn’t implemented and so the service is essentially free till then.

No, bravedns resolver does not respect or forward the EDNS Client Subnet (ECS) flag due to privacy concerns, currently, though, this breaks websites like archive.is. Let us know if you need this and we would selectively enable it for you specifically. Write to us.

Yes, bravedns follow CNAME redirects and match them against the domains in the blocklist to counteract DNS CNAME cloaking.

Currently, we support both. HTTP GET requests are cached and might be a tad faster than POST.

Yes. Note that the bravedns companion Android app communicates over HTTP/2 and TLS v2 for now.

The logs are stored encrypted with AWS servers in the United States. There’s no way to change the location where the logs are stored today. We plan to add the ability to choose the location of the logs storage in the near-future.

Logs aren’t stored by default; however, if you, the user, should so choose to enable them, would be able to analyze the logs to answer questions such as:

• Which countries are your devices connecting to and when?
• What percentage of connections are to known trackers, malware, spyware, ransomware, and other such web properties?
• Which blocklists are the most effective?
• How many connections per app are made from your devices?
• and so on...

Yes, by default, no logs are sent or stored. Only if you, the user, choose to enable logs are they even captured; otherwise, there’s zero information that’s stored on our servers with respect to the DNS requests sent to bravedns' resolver.

Yes, you can. This will be self-service eventually, but for now, drop us a note and we’d purge our systems of your logs.

Logs are stored in Amazon S3 encrypted with AWS KMS-managed master-key and never transmitted in plain text between different systems.

Logs are stored, if enabled, for 3 months by default. This will be configurable in the future to allow for storage as long as 2 years or as short as 1 day.

Users cannot access each other's logs, this is ensured through AWS Cognito-enforced policies. As for engineers at bravedns, they do have access to all logs, but we would work to improve that and restrict access to a need-only basis. bravedns is a three-person bootstrapped team right now. We must note though, the logs, as stored, are de-anonymized, as in, access to a separate user-information database is required to tie the logs to a particular user.

The information shared by the end user during signup (like email) and user configuration, user payment status and other related metadata for metering payments are stored to provide services effectively. If the end-user opts to store their logs, then that’s stored for analysis too, at the end-user’s behest. To delete account and other related information, please write to us.

We’re in the processes of building a self-service front-end to let the users do so themselves, but in the interim, please write to us.

Our DNS resolver runs on Cloudflare’s low-latency, globe-scale serverless environment viz Workers. The control plane is on AWS. The logs are stored in AWS data-centers in the United States. Our payments are powered by Stripe. Google's Play Store hosts our Android application.

Cloudflare can essentially see the requests that reach our resolvers including the contents of the request and the your IP addresses. Though one may not trust Cloudflare, we believe their track record is admirable and that they truly believe in making the internet better for everyone, which is a mission we can relate to very much, besides 10% of all HTTP traffic runs through Cloudflare.

Logs, if enabled, are sent to AWS encrypted-in-transit, de-anonymized, and subsequently stored in S3 encrypted with bravedns-supplied master-key managed by AWS KMS. Metering information, for invoicing and billing, is sent to Stripe, and this information doesn’t have any DNS related content in them, just the count of DNS requests sent by a user in a given time period.

Other customer related information, like DNS configuration (blocklists and whitelists), email, payment status and related information is stored in Amazon Dynamo DB tables, encrypted at rest and in transit, and accessed exclusively via the AWS AppSync endpoint from the clients which has pretty tight built-in access protections.

Data is encrypted-at-rest and encrypted-in-transit, that is, it is never transferred or stored unencrypted. We haven’t gone through third-party audits yet, but we should eventually, especially if we continue to add more users, we’d owe this much to them. The data is currently accessible to anyone with access to our backend accounts with Cloudflare and AWS which is a team of 3 engineers (the whole of bravedns). This setup isn’t ideal, and we’d eventually have to improve access-control mechanisms, which we would.

This is worth a blog post but we acknowledge that this is a real and present danger. Access to our AWS and Cloudflare accounts remain the biggest single point of failure as far as a breach is concerned. Apart from following the usual practices of protecting the account with a strong password and two-factor authentication, disabling root account (AWS) in favour of scoped-down accounts; we haven’t really done much else. That said, we plan to continually audit the resources spun up in AWS (with help of AWS supplied tools like AWS Security Hub) and continue to scan provisioned AWS resources for any weak access protections. This is an ongoing process and hopefully we reach a point where we can afford a third-party audit that can help us get over the line.

In event of a breach; however, we plan to infrom the users right away without any delay (GDPR requires us to report breaches within 24 hours anyway to any EU citizens that might be using the service) and promise to err on the side of transparency.

No, but we do plan to have one, if and when the budget permits. It isn’t a matter of time or priority, at this point. If you do have any tips or suggestions, please don’t hesitate to reach out to us.

The front-end Android app is open-source under Apache License and you are welcome to contribute to the codebase or report issues at the project’s github page. The backend and the website sources are closed, primarily because the code is very specific to the infrastructure we have built and it is likely in an incomprehensible and inconsumable state from all the constant influx in changes that it sees on a day-to-day basis. We do plan to blog about the engineering challenges we faced building a service like this that would lift the covers a bit on the secret sauce that isn’t really ground-breaking anyway, if we are being honest.

Apart from adding features to the existing product, we’re working on a VPN next (primarily, as an anti-censorship tool); and plan to start working on a cloud-based browser. Things we've considered but aren't likely to pursue: An on-device no-root Android application sandbox, an custom Android distribution, start a ISP, a MVNO...?

If you'd like to collaborate, partner with us, or generally have any ideas you want to share, feel free to write to us.

Not yet (as of August, 2020). Would we take VC money is a better question. May be, but VCs aren’t exactly lining up to fund us.

We're Mohammed, Murtaza, and Santhosh three friends with 20 years of software development experience between us at Amazon, IBM, and Scientific Games. We are based out of Coimbatore, a sleepy city on the foothills of the Western Ghats in South Western India.

No, we won't; we will never be in the business of selling user data. That's not us. That's not what bravedns is. And in the hypothetical scenario that we do get acquired, it really depends on the other hypotheticals on what the outcome would be (for example, would we have a significant enough a say to veto a sale, say). From our experience in talking to investors and their general outlook on the fate of consumer startups let alone security focused ones such as us, it is safe to say it'd be a cold day in hell if and when that happens (the acquisition or funding, that is). That said, in all seriousness, we believe in working with like-minded partners and so, hopefully, things won’t change that much post-acquisition by a company that puts users over profits (hypothetical again); and hopefully, we pick up investors that don't veer off-track and stand-firm with us on protecting user's data.

In any case, users won't be sucker-punched. We promise to be transparent about such situations if and when they arise.

You shouldn't. We built a tool we wanted for ourselves and for friends and family, and hope that it stirs others to build more such tools in the security and privacy space. GuardianApp, Blokada, pi-hole, nextdns are examples among many such tools done right.

We'd be pleased to hear from you, please write to us.

We are sorry to hear that, please write to us and we'd try to help you to the best of our ability.

Here's a direct download link, and a PlayStore link. We plan to host it on F-Droid, too.

On devices with Android 9 (or lower versions), support required to run both DNS and Firewall at the same time isn't available, and so any one of them could only be running at any given point in time. On Android 10 (and higher); however, both should be able to run side-by-side.

The DNS stops requests from being sent to known adware, malware, spyware, and ransomware servers across all apps whilst Firewall prevents an app from making connections to any server whatsoever. DNS mode, in addition, may circumvent internet censorship and prevent surveillance of your browsing behaviour (by analysing your DNS requests) by the Internet Service Provider (and every other malicious actor on the network).

Here. You're welcome to contribute to it, suggest features, or fork it.

Bravedns uses VPN APIs on Android to selectively route only a device’s DNS requests to bravedns' servers and to build Firewall functionality. It isn't like other VPN apps that relay the entire device's internet bound traffic via their remote VPN servers.

No, it doesn’t. Bravedns doesn’t capture or send any user analytics (“phone home”) from the app.

The app’s firewall feature lets users disable and enable internet traffic for an app depending on whether it is in the foreground (allow) or background (disallow). For example, consider games, not all games really need internet connectivity when they are in the background, but may need it when they’re in the foreground. To track which applications are in the foreground and background the app uses the Accessibility permission. Bravedns doesn’t send any information captured through Accessibility permissions back to its servers.

Pi-Hole is a better private content-blocking DNS resolver but one that requires a bit of a non-trivial though easy setup. It is also local to a network by default, though it can be set up to answer requests from the clients over the internet. With bravedns, though, the setup is comparatively easy. Bravedns runs at the closest server near the user, and is accessible from anywhere out-of-the-box. See: Pi-Hole.

NextDNS is the best configurable DNS resolver out there in the market today, and they’ve got a generous free-tier, but their focus is different. At bravedns, we aim to democratize security and privacy tools to turn Android device into "user-agents" (like the browsers) and not just stop with DNS, even though the name suggests otherwise. The poor choice of name is rather reflective of how hard really it is to name things, I guess.

Both OpenDNS and Cloudflare Gateway are run by organizations with a great track record for running internet scale applications. They are feature rich but their focus is different to bravedns’ and that shows in the feature-set and products themselves. Besides, bravedns is just getting started.