Add custom DNS blocking rules

[ghost]

Operating system: iOS 15
App version: 2021.4

On iOS, the Mullvad app (which does not use IKEv2) cannot run simultaneously with other DNS-controlling apps. I understand this is done knowingly and no plans for an IKEv2 version are planned. Fair enough.

However, a major perk of DNS-controlling apps, such as Adguard, is the possibility to add custom DNS blocking rules (not talking about entire lists here, but about specific rules, such as blocking iOS-related telemetry or specific websites the user wants to block for personal reasons).

Would it be possible to add custom DNS blocking rules to the app? This is different from using a custom DNS server and complementary to activating "block ads" and "block trackers" in the app.

[faern]

I don't fully follow what you want. Do you as a user want to be able to enter domains into the app that should be blocked? User created lists of domains that should be blocked?

[ghost]

Hi @faern. Yes, I would like to be able to tell the Mullvad app to block DNS requests, for instance, to iadsdk.apple.com.

[askew07]

@TommieWong, weeks ago I have added similar request to yours here: #3169.

Our feature requests might not match 100%, but conceptually, we are loooking for the same: have the ability (server-side or client-side), to subscribe/unsubscribe on-demand to block lists, and additionally, whitelist/blacklist specific domains (example: *.facebook.com)

@faern Mentioned that they would better implement a client-side solution (I am not entirely convinced about the idea, to be honest).

@faern In my ideal world, I would go into my account in mullvad.net, and have a NextDNS-like interface on which I can subscribe/unsubscribe to block-lists, whitelist / disallow domains and its subdomains, and why not a Parental section.

Effectively, taking NextDNS (wonderful) idea, but applied directly into a VPN tunnel.

I know this is a pretty large feature (client-side or server-side), but please**, give high-priority to it if you can; it is really needed.

[faern]

Why are you not convinced this is a good idea client side? Much easier for the app to inspect requests and match them towards a local list than having the server do that. If the server did that it would need individual lists per user, and it would cost a lot of memory and performance on the servers. Also, if it was per account it would automatically apply to all your clients. If it's done client side you can block different stuff on your different devices.

[askew07]

@faern yes, your points are very valid. I was thinking more about the breakability of the implementation.

Moving the "firewall" (because that is what it is) responsibility from server to client, means that any change Apple does to iOS implementation might potentially break this client-side solution (or may be I am talking BS). An example of this could be Apple iCloud+ Private Relay. You will never have this problem server-side.

On the other hand, solutions like NextDNS update their lists in real-time (mostly), and even the final aggregated list is updated in real-time. Best scenario, Mullvad client-side implementation might update block lists on a weekly basis (which is not the big deal to be honest).
They also have a "AI-Driven Thread Detection" option there. I guess server-side implementation open up more powerful posibilities (at the cost of performance/memory consumption, as you said)

The most important aspect IMO is peformance: we can easily affect device performance when using massively huge block lists (example, the full version of OIDS list: https://oisd.nl/downloads, currently 23.6 MB), so by going client-side route, you will be forced to find a balance in "how much we can block without affecting device performance" — You do not have this problem server-side.

If the server did that it would need individual lists per user

Why? I do not want to keep track and manually block the massive amount of domains that (example) Facebook has. That's why I can subscribe to "No-Facebook" list, and the list will do the work for me. Of course, additionally, I might block a specific domain, but the real power relies in reusing the block lists, without reinventing the wheel.

if it was per account it would automatically apply to all your clients. If it's done client side you can block different stuff on your different devices.

Not really. I was thinking about using "Profiles" for each config (just like NextDNS does): I can have multiple config profiles, each with its own respective block/allow list, etc... and on-app, select the profile that applies to that device: and my problem would be solved.

[ghost]

All good points left and right, but I just want to underline that the core point of this feature request is about client-side dns blocking, which may be less than what some want, but is also easier to put in place and would go a long way in providing users with more flexibility and privacy (and making up for the loss of other apps that do this).

[faern]

Moving the "firewall" (because that is what it is) responsibility from server to client, means that any change Apple does to iOS implementation might potentially break this client-side solution

If you use our app it means you already trust us to not leak any data. If you are afraid of the above, then why are you only afraid of DNS leaking? The app is responsible for making sure NO traffic leaks. If we start leaking it might very well be something other than DNS. BUT you are also correct at the same time. I'm mostly talking about desktop here! We are probably not going to be able to do very flexible client side things for mobile since the mobile OSes don't allow us complete control over the firewall and DNS settings in the same way as desktop. So yes, it might very well be that the best/only solution for mobile is something server side.

They also have a "AI-Driven Thread Detection" option there

This is IMHO just BS 😅

Why? I do not want to keep track and manually block the massive amount of domains that (example) Facebook has. That's why I can subscribe to "No-Facebook" list, and the list will do the work for me

We are talking about two different features here! The "custom" in the issue title to me means that a user can block any domain they want, not predefined lists set up by us. You can have a custom list where you block example.com and ietf.com or whatever. Social media DNS blocklists is something we might deploy server side actually. Maybe not something Facebook specific, rather all social media?

Of course, additionally, I might block a specific domain

So if we do it server side, then that means we need custom configs per VPN tunnel anyway. We need to see that your tunnel specifically should block Facebook + example.com, which might be unique to only you.

[ghost]

The "custom" in the issue title to me means that a user can block any domain they want, not predefined lists set up by us.

Correct :)

So, do you think this could be implemented in future versions of the iOS app?

[askew07]

@faern Really nice discussion here. My last comment:

So yes, it might very well be that the best/only solution for mobile is something server side.

So, if Mullvad engineers acknowledge this, you might quickly find out that —In order to have a strong/fine-grained implementation in both mobile and desktop— you will have to have two implementations: 1) client-side for mobile (as you said), 2) server-side for desktop.

In other words, you will need a TON of man-power to implement both :). IMO, you guys could reach a point on which you will say "You know what?, let's do it server-side for both mobile and desktop, in a single shoot" (which is what I would do).

Just brainstorming here!

[faern]

So, do you think this could be implemented in future versions of the iOS app?

Some variation of it, yes. I really hope so. But it's too early to say anything about exactly how it will work or when it will be available. But having users submit their use cases really helps us understand the problem we are trying to solve, so thanks for that.

[lordcyb3r]

I would like to seethe ability to import dns blocklists similar to how pihole does it (and they auto update on an interval). would be a nice way to take that functionality on the go as pihole is only in the home. No auto updates is also fine (manual updates) but it would be nice to at least allow a txt file of domains to be loaded instead of manually inputting each domain.

[ghost]

I'd like to second this request. Importing blocklists could be good but ESPECIALLY being able to block specific dns request (by (sub)domain or IP) would be a HUGE improvement in order to block telemetry/call-backs from apps. This is the one reason I can't use the iOS app for now; cannot do without Adguard's dns rules/filtering.

[ghost]

Hi @faern, following up on this, is there any progress? any calendar for this to be implemented?

[ghost]

Coud the app include a dns filter? As said up, woud be great to block telemetry, social media and otehrs.

[ghost]

Is this moving? or even considered at this point? I mean OP wrote in Jan and blocking individual requests (with some regex work maybe) should not be too difficult to implement. the IOS privacy report is pretty useful to spot domains that apps call to and it'd be gud to be able to block all that.

[faern]

Hello! We still want to eventually add some sort of domain filtering built into the app. But no work has been put into this since last time I wrote. We have bigger fish to catch. But once we have integrated a DNS server into the app on more platforms we will consider it again! Thank you for your patience.

[user234683]

@faern I wanted to chime in with a different, important usage for this functionality:

If I login to my workplace email, it will not only block logins from outside the country, but also lock the account. So if I accidentally leave the VPN on, it creates a big headache. This could be easily solved if I could tell Mullvad to never connect to certain domains when the VPN is on. I only need this for desktop, so should be much simpler to implement

[faern]

@user234683 Sounds like what you want is split-tunneling. Which is available on all platforms except iOS and macOS. With split tunneling you can make your work email application communicate outside the tunnel.

[user234683]

@user234683 Sounds like what you want is split-tunneling. Which is available on all platforms except iOS and macOS. With split tunneling you can make your work email application communicate outside the tunnel.

I looked at it, but that only does it based on application. The email is a webmail, and the same problem can happen with online accounts such as ebay, so I need it to be based on domain

[faern]

Our recommendation around that is in general to use two browsers. One excluded from the tunnel and one included

[metametapod]

Seconding this request. I'm interested in this specifically for allowing crash and error-reporting services. Reported a similar to issue to iVPN, right now only workaround for iOS is to use a service like NextDNS but would be preferable to do it all client-side. ivpn/ios-app#439

[buggmagnet]

Hello,

Thank you everyone for your involvement and for all the discussions.
We will discuss this with the team and update this ticket accordingly.

Regarding DNS, the first issue we want to focus on is letting users use a local DNS server which still requires quite some work on our behalf.

This is not a perfect solution, but hopefully, it will let you have more options in how you want to handle DNS queries.

Thank you for all the support !