feature: keeping system DNS unchanged or use custom DNS

[codl]

hi, I have a local DNS resolver for caching reasons and I want to keep using it when I enable mullvad, but the daemon changes resolv.conf without asking and even monitors it and reverts it every time it is changed. I couldn't find a way to disable this

could an option be added to disable this behaviour?

[faern]

We have plans on adding a feature to make the app set a custom DNS resolver. But I'm unsure we want to disable its DNS setting/monitoring completely. The app is fully responsible for the system security and our job is to try to protect the privacy of the people using it. Leaking DNS is terrible for privacy, so it's not something we want to make it too easy for users to do.

[codl]

being able to set a custom DNS would fix my problem either way

[akej74]

Hi, I'm using a Raspberry Pi with Pi-Hole as a DNS server to filter out ad-related lookups. I have my router configured to set the IP of the RPi as DNS on my network over DHCP, but when starting the Mullvad client, the DNS is changed to e.g. 10.11.0.1.

An option to configure the DNS manually would be very much appreciated!

Side note/question: Is using the Mullvad DNS at 193.138.219.228 as safe as using the one available on each VPN server (e.g. 10.11.0.1)?

[faern]

@akej74 Yes, the public DNS on that IP is still supported. As explained in our DNS leak guide (under Other users) all requests to it will actually be hijacked and redirected to the DNS resolver running on each VPN server when you are connected to Mullvad. So in practice, using 193.138.219.228 as your DNS through the tunnel effectively becomes equivalent to using the DNS available at the VPN server you are connected to.
https://mullvad.net/en/guides/dns-leaks/

[akej74]

Hi, just a quick question on the topic of adding a custom DNS setting in the Mullvad app, is this something that is on the roadmap? If not, I need to rely on the OpenVPN app, but I would prefer the Mullvad app.

[faern]

It is on the roadmap. But I don't have a time frame for it currently. It's not part of what we are working on at the moment.

[cedws]

I've just spent 5 minutes or so trying to figure out why I couldn't reach any websites. Of course, I eventually checked the resolv.conf and realised that the Mullvad client must have changed it.

I'm alright with Mullvad changing it, but there needs to be some kind of notice to users that if the VPN is unexpectedly killed, the resolv.conf won't be changed back. In fact, why can't the original DNS configuration be stored somewhere, and have mullvad-daemon change it back when the VPN is not active?

[faern]

mullvad-daemon does restore the DNS when it's instructed to disconnect. What is it that you mean is unexpectedly killed? mullvad-daemon or OpenVPN? If OpenVPN dies unexpectedly then mullvad-daemon will directly try to start it again. Killing OpenVPN will not make the Mullvad VPN become disconnected, it will just make it retry connecting. For mullvad-daemon to stop trying and restore your system settings to use the internet unencrypted, you need to instruct Mullvad VPN to disconnect.

If you mean that mullvad-daemon is unexpectedly killed and that does not restore your settings then I say it depends a lot on the circumstances and your platform etc.

EDIT: @c-edw If you believe what you are experiencing to be a bug, then please file an issue on that. This issue is about something else, so let's keep them separate.

[cedws]

My laptop battery died while I was connected. I guess it could be considered a bug - it depends on whether the client is supposed to restore the DNS settings in this case.

[faern]

@c-edw It should indeed have restored the DNS automatically on reboot. We have four different ways of managing DNS depending on what services are available on your distro etc. If you can reproduce the problem it would be awesome if you could send a problem report to our support through the app.

[Rouzax]

+1 for me.
Because it overrides my local DNS server I loose all connectivity to the other servers in my local domain which results in me being unable to logon (AD Domain), unable to access file shares, etc.
I understand why you would want to to do this but in my use case it makes the service useless.

I would very much like the ability to set the DNS on the VPN adapter to Mullvad but please make it optional to change all DNS server addresses on all network cards.

[aalhitennf]

+1

Really needed feature for pi-hole users.

[Rouzax]

You can work around this by installing OpenVPN and creating connection files through Mullvad.

[sfreyux]

+1
I'm a Pi-Hole user and I'd love to be able to use it together with the (awesome) Mullvad app.
Until then, I guess I'll work around this by using OpenVPN.

[jelbo]

This is how I set up my OpenVPN client configuration to use a custom, local DNS server (Pi-hole):

#block-outside-dns
pull-filter ignore "dhcp-option DNS"
dhcp-option DNS <local dns ip>

[fooness]

This is how I set up my OpenVPN client configuration to use a custom, local DNS server (Pi-hole):

#block-outside-dns
pull-filter ignore "dhcp-option DNS"
dhcp-option DNS <local dns ip>

Anyone knows if the same works for OpenVPN Connect on iOS? Where local dns ip means local network and not localhost. (I want to use my PiHole DNS server when at home.)

Download the .ovpn files from Mullvad’s config page, open in editor, add these two lines, securely send the files to iOS device … tried it, cannot really confirm if it works … but seems it doesn’t.

[DjCrays]

+1, would love if this is also possible in Wireguard and not only OpenVPN

[juliangaal]

+1, this feature would be killer for PiHole users!

[sheevy]

+2 if Mullvad could provide ads blocking DNS on their side insead of relying on Pi-Hole

[semente]

Would be great if it supported DNS-over-TLS, but I guess it must be implemented on Wireguard first.

[semente]

I've just figure out how to use DNS-over-TLS on a Wireguard connection:

(It may not apply to Mullvad apps, only official Wireguard software for GNU/Linux and Android)

On GNU/Linux system you must install and setup unbound or stubby software with the DNS-over-TLS service of your choice (e.g NextDNS.io), then set your /etc/resolv.conf to 127.0.0.1 and remove the DNS option from your Wireguard configuration (or just set it to DNS = 127.0.0.1)

On Android 9 or later, use the Wireguard official app to connect to Mullvad. Set the the DNS option of the desired VPN configuration to blank. It will make it use Android system's DNS. Go to Settings > Network > Advanced > Private DNS and set it to the DNS-over-TLS service of your choice.

I would suggest Mullvad developers to provide an option to "Use system DNS" on their apps. Thanks

[tobias-kuendig]

Having the client prepend a nameserver 127.0.0.1 to /etc/resolv.conf would already help to prevent killing many automated development environments that run a local DNS resolver and would also provide a "hook" for more advanced user to use for their custom DNS needs.

Correct me if I'm worong but adding localhost as a DNS sever usually should not leak any DNS to the outside world.

[FilipoMoake]

Option to personalize DNS resolver is definitely something missing in Mullvad VPN, particularly if you you want to use DNS including ADBlocking.
I actually use Mullvad for the Wireguard compatibility and the hope of the DNS resolver option, but if this option is not implemented soon, sure that i will swap to another VPN provider, sorry to say that.
Is it something so hard to implement ?
Thanks in advance for understanding, and thanks for the great job you've already done.
In the hope you'll solve that soon ...

[techwoes]

+1 for this option in order to allow pi-hole or other custom ad blocker. thanks for the hard work mullvad team

[juliangaal]

If you're using wireguard, shouldn't it be as easy as setting DNS in the client config to a custom server? They are normally in /etc/wireguard/*.conf, at least if you setup wireguard yourself. Not sure about where the mullvad app places the configs

[Mattrazol]

@faern what about querying the first and if it doesn't find the domain or it fails than fallback on the secondary (if set) and in case if is not set use the default one from Mullvad?

[p1r473]

+1 here, cant use Mulvad while using Pihole

Are you using wireguard with mullvad @p1r473 ? I think there may be a way to get to use both

I cant connect to Mullvad while Pihole enabled.
I got an error about DNS System Preference couldn't be changed.

Support said I am required to use the Windows DNS Caching service, which I don't want, else I need to use OpenVPN
Sad, because I wanted to use the Mullvad windows app and not have to use DNS Caching service.

[vr]

what about the "leave my dns unchanged" option ? my /etc/resolv.conf has immutable flag as purpose and i don't want any application to touch it, having to remove that to set again 127.0.0.1 as custom dns is not enough for me.

[sylv-io]

Is there a way to use systemd-resolved stub listener on 127.0.0.53 ?
I would like to be able to resolve hosts on my private network, using a custom dns server.

[faern]

🎉 Yesterday we released app version 2021.1 for Windows, macOS and Linux. That version supports custom (local) DNS 🎉

https://mullvad.net/en/blog/2021/2/11/long-awaited-feature-introduced-desktop-app-20211/

This means that you can now go to Settings -> Advanced and set up custom DNS resolver IPs. However, since our VPN servers still hijack all DNS requests going through them only local resolvers are possible. This means you can use 127.0.0.53 for a resolver running on your system (<- this is not supported) or use something like 10.0.0.1 for your router or something.

The same functionality will come for Android in the next release. We have no ETA for when that is. But expect it in a few weeks maybe.

That means most of the functionality in this feature request has now been implemented. I hope it will work well for all of you!

[fooness]

Slightly off-topic, but also somewhat related: Might there be any problems when using Mullvad’s DNS server (IP via: https://mullvad.net/en/help/dns-leaks/) as the upstream DNS of my raspberry pi (with pihole) to prevent DNS leaks? Are there more/alternate Mullvad DNS server IPs in case of downtime or lots of traffic?

[faern]

If you just use our public DNS server as your DNS resolver and don't have a VPN tunnel or anything, then your ISP or anyone else between you and our server will see your requests. Normal DNS is not encrypted. And if you do have a VPN tunnel on the other hand it's a different deal.

We have also just now released our own DoH and DoT solutions (still in beta). You can try that out if you are interested: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls/

For other inquiries about DNS and usage of our infrastructure please contact [email protected] instead as this is not app related.

[TheOriginalCoda]

I have lost hours pissing about with DNS today - when my server is connected to Mullvad all DNS lookups fail. I cant run incoming connections to my public IP either when mullvad is running, all attempts at setting up port forwarding on my account page fail whether using wireguard or openvn - this all works when mullvad is disconnected! Not only that but often a 'mullvad status' request says 'connection blocked... too many clients' which is bananas, and searching for help on the web is fruitless - it finally brought me here to find out that I cant use my local DNS I have set up already, and the new custom-dns settings in the linux client do not work. I've cancelled my recurring payment and will look for something else. Its a shame, I've been happy for years with mullvad but havent tried anything 'outside of the box' until now.

[faern]

@TheOriginalCoda You can set a custom DNS is the app. I'm not sure what part of it / why it does not work for you. However, if the local resolver is on localhost you would need some extra firewall trickery to allow it to reach the internet, since our app would be blocking anything from going outside the tunnel. And any DNS inside the tunnel is currently captured by our relay servers. You can't for example reach 1.1.1.1 inside the tunnel, because the relay would hijack the request. This latter problem is something outside of the control of the app. But the restriction will be lifted very soon. Then custom DNS can go through the tunnel!

As for incoming connections. Yes, our app blocks that as by design. When enabled nothing outside the tunnel is allowed. However, you can manually add firewall rules with higher priority than the rules our app add, and then allow whatever it is you want to allow there. See this comment for some inspiration: #2097 (comment)

[p1r473]

Can you please make this not require dnscache Windows service?

[dhaavi]

I'm not part of Mullvad, but wanted to add my .2c:

At some point with Windows 10 the dnscache Windows service became a required service. This is very poorly documented.
A hint for this is that you cannot turn it off anymore via the service manager, but have to manually edit the registry.

The dependance on dnscache goes so far that even Powershell commands require it to be running and just silently fail if it's not.
We ourselves built a firewall that required it to be turned off, which created huge problems. For example, Docker for Windows won't run with the new backend anymore.

My .2c as a developer from another project: It just does not make sense anymore to turn off dnscache. I feel that at this point, turning it off can be seen as a modified operating system.

[p1r473]

I personally dislike dnscache as I run my own DSN server, and during a troubleshooting or whitelisting issue, I have to disable the dnscache so I am getting proper nslookups, unhindered by the cache

[dhaavi]

In that case I would recommend to leave dnscache enabled and use the amazing tool dig. Here is an install guide. This bypasses the Windows dnscache and does lookups directly.

Just be careful when using it while having Mullvad enabled, as - afaik - they catch astray dns queries and redirect them to themselves.

[p1r473]

Thanks, good idea.!

[faern]

We have stopped hijacking astray DNS requests if you use our app and have a WireGuard tunnel. Any WireGuard key uploaded by the app in the last few weeks has DNS hijacking disabled. This is to allow our custom DNS feature to work as expected. But it also means you can query whichever DNS server you want in the tunnel via dig :)

[ph00lt0]

@faern any plans to allow localhost with custom port on android as custom DNS? I didn't want to open a new issue yet, because I feel this is related. It would be great to be able to use Nebulo (in non-vpn mode) to be able to filter network activity with block lists and afterwards route it to DOH. Allowing blocklists within mullvad would also do, but not sure if that is on the table.

[faern]

@ph00lt0 I can add to our research to check if we can support custom ports on Android easily or not. But this is nothing we currently have in our backlog or a timeline for.

I'm not sure exactly what it is that you want to block. But just so you know: We support ad and tracker blocking via DNS on all our relays already. You can use it on Android by setting a custom DNS. Read this blog post for the details: https://mullvad.net/en/blog/2021/5/27/how-set-ad-blocking-our-app/

[ph00lt0]

@faern thank you.

I am aware that you offer ad- and tracker blocking already, but I would like to be in control over what I block, mainly to block more things, that might break some functionalities which I do not need and known malware lists.
My idea is to forward the DNS first to Nebulo, add my own blocklists there and then forward the dns request to mullvad's DOH. A native option to select blocklists and blocked domains in mullvad would be awesome, but I thought, I keep it simple ;)

[faern]

Very similar issue: #3173

[mietzen]

We have stopped hijacking astray DNS requests if you use our app and have a WireGuard tunnel. Any WireGuard key uploaded by the app in the last few weeks has DNS hijacking disabled. This is to allow our custom DNS feature to work as expected. But it also means you can query whichever DNS server you want in the tunnel via dig :)

$ nslookup google.de
Server:		10.64.0.1
Address:	10.64.0.1#53

Non-authoritative answer:
Name:	google.de
Address: 142.250.179.195

$ nslookup google.de 1.1.1.1
;; connection timed out; no servers could be reached

@faern am I doing something wrong?

[pinkisemils]

@faern am I doing something wrong?

You'll have to enable 1.1.1.1 as a custom resolver in the app still. Otherwise the firewall will drop DNS traffic.

[MahouShoujoMivutilde]

Is there a way to use default system dns for local domains (like .local or .test etc) and mullvad (10.64.0.1) for others, on linux (latest arch, systemd-resolved)?

I found that I can sort of make it work with dnsmasq

config

# /etc/dnsmasq.conf
server=/test/10.0.0.1

# private mullvad
server=10.64.0.1

listen-address=127.0.0.1

proxy-dnssec
no-hosts
no-resolv

no-negcache
cache-size=10000

min-cache-ttl=300
max-cache-ttl=86400

and setting custom dns server in the app to 127.0.0.1 and 10.0.0.1. But that's defeats the purpose, since now both of them will be used for everything.

If I add 127.0.0.1 alone - it doesn't work since

> drill @10.64.0.1 google.com
Error: error sending query: Error creating socket

So apparently default firewall rules block even mullvad's own dns.

I tried to set custom dns to 127.0.0.1 and add a custom firewall rule inspired by Split tunneling with Linux (advanced).

nft rule

table inet excludeTraffic {
  chain excludeDns {
    type filter hook output priority -10; policy accept;
    ip daddr 10.0.0.1 udp dport 53 ct mark set 0x00000f41 meta mark set 0x6d6f6c65;
    ip daddr 10.0.0.1 tcp dport 53 ct mark set 0x00000f41 meta mark set 0x6d6f6c65;

    ip daddr 10.64.0.1 udp dport 53 ct mark set 0x00000f41;
    ip daddr 10.64.0.1 tcp dport 53 ct mark set 0x00000f41;
  }
}

This allows 10.0.0.1 to work, but 10.64.0.1 still gives the error above.

I think this happens because table inet mullvad has

chain output

chain output {
    type filter hook output priority filter; policy drop;
    oif "lo" accept

# In iptables this would just accept and exit immediately from the chain,
# but apparently that's not how nft works, so idk how to to do it here.
    ct mark 0x00000f41 accept 
....
    oif != "wg-mullvad" udp dport 53 ip daddr 127.0.0.1 accept
    oif != "wg-mullvad" tcp dport 53 ip daddr 127.0.0.1 accept

# HERE I think is the problem: reject all dport 53 first and
    udp dport 53 reject
    tcp dport 53 reject with tcp reset

# only then accept wg-mullvad output
    oif "wg-mullvad" accept
...
}

Which is weird - shouldn't it just accept everything that goes out to wg-mullvad? I don't see a way how that can lead to dns leaks. (Since it will go inside a tunnel anyway).

Any ideas?

I want to use the app because it's convenient and has mullvad-exclude, but the firewall makes it very difficult to do.

[pinkisemils]

You can setup exclusion rules for your local resolver address and apply said rules on boot. All you have to do match your DNS traffic and assign an exclusion mark. There's a handy guide for this on our website. If you exclude your local DNS traffic, systemd-resolve will be able to reach your local resolver. You should be able to configure systemd-resolve to only use that resolver for your local domains too. But do keep in mind that if you do this, our app won't be able to ensure that DNS traffic won't ever leak - then you're relying on systemd-resolve to not leak.

[MahouShoujoMivutilde]

Yes, I've seen this guide, even linked it myself in the original comment.

Anyway, I've managed to solve this.

So, the problem:

1. When custom dns is enabled even default mullvad's internal dns 10.64.0.1 is blocked by the firewall because table inet mullvad chain output has ... dport 53 reject before oif "wg-mullvad" accept.

So any dns traffic not going to the custom dns is blocked.

2. It is easy to make something bypass the tunnel altogether (like I did with 10.0.0.1 above) - just set mark and meta mark.

But it is surprisingly hard to bypass the dns filter for traffic that will go inside the tunnel (like 10.64.0.1).

Seeing ct mark 0x00000f41 accept at the start of table inet mullvad chain output I've expected that setting the said mark (without meta mark) would be enough, but it isn't.

Ct mark here is not enough, only inserting accept for 10.64.0.1 dns in the mullvad's output chain will actually work.

What I did:

1. Just disable custom dns and apply this nft rule:

table inet excludeTraffic {
  chain excludeDns {
    type filter hook output priority -10; policy accept;
    ip daddr 10.0.0.1 udp dport 53 ct mark set 0x00000f41 meta mark set 0x6d6f6c65;
    ip daddr 10.0.0.1 tcp dport 53 ct mark set 0x00000f41 meta mark set 0x6d6f6c65;
  }
}

That way 10.64.0.1 is allowed by default and you don't need to try to insert appropriate accept rule in to existing table inet mullvad chain output.

2. Dnsmasq config:

Warning: obsolite and sometimes(?) dns leaks

2. Dnsmasq config is the same as above, I haven't figured how force systemd-resolved to use 10.0.0.1 only for my .test and 10.64.0.1 for others.

3. In /etc/systemd/resolved.conf

[Resolve]
DNS=127.0.0.1
DNSStubListener=no

To force it to use dnsmasq globally.

5 Jul 2022: I checked it in on https://mullvad.net/en/check, dns didn't leak before, but now apparently it does. Wtf? Anyway, see below:

Kind of clunky, would prefer if all of the dns traffic going through the tunnel would be just accepted, but this works.

UPD 5 Jul 2022

I found out how to achieve the above with systemd-resolve exclusively. Inspired by this.

Here it is:

1. nftables rule is the same.

My local domain is .test, real network interface is enp7s0.

2. Configs

/etc/systemd/network/20-wired.network

[Match]
Name=en*

[Network]
DHCP=ipv4
Domains=.test ~test

/etc/systemd/resolved.conf

[Resolve]
DNS=10.64.0.1
FallbackDNS=
DNSStubListener=no

(Note that while I don't see dns leaks, it doesn't explicitly block everything non .test to 10.0.0.1)

Results

~ via 🐍 v3.10.5
❯ resolvectl query google.com
google.com: 2a00:1450:4002:403::200e           -- link: wg-mullvad
            142.250.180.174                    -- link: wg-mullvad

-- Information acquired via protocol DNS in 93.1ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

~ via 🐍 v3.10.5
❯ drill google.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32628
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;; google.com.	IN	A

;; ANSWER SECTION:
google.com.	12	IN	A	142.250.180.174

;; AUTHORITY SECTION:
google.com.	70119	IN	NS	ns3.google.com.
google.com.	70119	IN	NS	ns2.google.com.
google.com.	70119	IN	NS	ns4.google.com.
google.com.	70119	IN	NS	ns1.google.com.

;; ADDITIONAL SECTION:

;; Query time: 91 msec
;; SERVER: 10.64.0.1
;; WHEN: Tue Jul  5 15:55:40 2022
;; MSG SIZE  rcvd: 116

~ via 🐍 v3.10.5
❯ resolvectl query pi.test
pi.test: 10.0.0.1                              -- link: enp7s0

-- Information acquired via protocol DNS in 1.5ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

~ via 🐍 v3.10.5
❯ resolvectl query skylake.test
skylake.test: 10.0.0.6

-- Information acquired via protocol DNS in 1.2ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: yes
-- Data from: synthetic

~ via 🐍 v3.10.5
❯ resolvectl status
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 10.64.0.1
       DNS Servers: 10.64.0.1

Link 2 (enp7s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.0.1
       DNS Servers: 10.0.0.1
        DNS Domain: ~test

Link 4 (wg-mullvad)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

[Zephilinox]

this might help resolve issues using mullavad with portmaster which also enforces a DNS

safing/portmaster#313
safing/portmaster#445

[mietzen]

We have stopped hijacking astray DNS requests if you use our app and have a WireGuard tunnel. Any WireGuard key uploaded by the app in the last few weeks has DNS hijacking disabled. This is to allow our custom DNS feature to work as expected. But it also means you can query whichever DNS server you want in the tunnel via dig :)

$ nslookup google.de
Server:		10.64.0.1
Address:	10.64.0.1#53

Non-authoritative answer:
Name:	google.de
Address: 142.250.179.195

$ nslookup google.de 1.1.1.1
;; connection timed out; no servers could be reached

@faern am I doing something wrong?

This solved my Problem:
curl -sSL https://api.mullvad.net/app/v1/wireguard-keys -H "Content-Type: application/json" -H "Authorization: Token YOURMULLVADACCOUNTNUMBER" -d '{"pubkey":"YOURPUBLICKEY"}'

https://schnerring.net/blog/use-custom-dns-servers-with-mullvad-and-any-wireguard-client/

With the API call above I got a "non DNS hijacking IP" and could finally use unbound + Mullvad Wireguard on my router.

[schnerring]

https://schnerring.net/blog/use-custom-dns-servers-with-mullvad-and-any-wireguard-client/

Author of that blog post here 👋

I'm currently seeing DNS timeouts when using Mullvad servers provided by 31173 . So far I tested ch{5,6,7,8,9}-wireguard, de-fra-wg-004, gb13-wireguard, nl-ams-wg-002, and se-sto-wg-001 all with the same results. The behavior is the same whether I use custom DNS servers or not. The Swiss DataPacket, M247, and PrivateLayer servers that I tested work as expected.

1. I tweeted @mullvadvpn
2. One of my readers reported the same issue in the comments of that blog post. He also says:

But recently on every 3rd or 4th try I’ll get a hijacking IP again / unbound can’t reach the dns root servers.

3. Testing these servers with the official Mullvad VPN App + Custom DNS Servers returns the same issues
4. Testing this on another residential connection to rule out any ISP issues returns the same issues

Regarding (2): has the API endpoint to request non-DNS-hijacked IPs changed away from https://api.mullvad.net/app/v1/wireguard-keys?

[dlon]

@schnerring We do not use that endpoint anymore. You should probably disable DNS hijacking when creating a device, not when rotating the key owned by that device.

Untested, but this should work:

access_token=$(curl -X 'POST' 'https://api.mullvad.net/auth/v1/token' \
    -H 'accept: application/json' -H 'content-type: application/json' \
    -d '{ "account_number": "SOME_ACCOUNT_NUMBER" }' | jq -r .access_token \
)

# create a new device, and set hijack_dns to false
curl -X POST https://api.mullvad.net/accounts/v1/devices \
    -H 'content-type: application/json' -H "Authorization: Bearer $access_token" \
    -d '{"pubkey":"PUBKEY HERE","hijack_dns":false}'

# rotate key
curl -X PUT https://api.mullvad.net/accounts/v1/devices/{DEVICE ID HERE}/pubkey \                                                                   
    -H 'content-type: application/json' -H "Authorization: Bearer $access_token" \
    -d '{"pubkey":"NEW PUBKEY HERE"}'