6

Known issues with iOS/macOS system Encrypted DNS (DoH) support

A number of known bugs have been found in the new iOS 14 and macOS 11 Encrypted DNS support. This page summarizes those bugs with current status of resolution and workaround when available.

macOS & iOS: VPN Conflict

When a VPN is connected, the Encrypted DNS profile is ignored in favor of the DNS server advertised by the VPN with no option to change this behavior. The DNS profile is still shown as active in the OS settings, which is confusing for the user.

We believe that Encrypted DNS should be part of the traffic going through the VPN as it is the case on other platforms. If you agree, please submit your feedback to Apple using Feedback Assistant.

Status: reported, probably won't fix

macOS: Chrome ignores Encrypted DNS in some cases

In some (still unidentified) cases, Chrome & Chromium ignore the system configured Encrypted DNS profile and use the system's legacy UDP DNS instead. We can't reproduce this issue consistently, we are seeking for more data to qualify the issue.

Status: investigating, please report if you reproduce

iOS: Safari UX bug with blocked domains

Since iOS 14, when a URL with a blocked domain is clicked or entered into the location bar, Safari does not show an error, the action is just ignored. This only happens when the domain is blocked with a 0.0.0.0 IP (NextDNS default).

Chrome on iOS shows an error properly.

Status: reported
Workaround: enable the Block Page feature

macOS: Content Filter extension conflict

When an application using the content filter extension like Little Snitch is active, the system Encrypted DNS profile is ignored.

Status: not reported

iOS: Disabled after VPN disconnect

In some (still unidentified) cases, the configured encrypted DNS does not reconnect once an IKEv2 VPN is disconnected. The default system DNS is used instead.

A system reboot or removing the VPN profile is required to solve the issue.

Status: investigating, please report if you reproduce 

14 replies

null
    • QA/QC
    • Stephane
    • 3 yrs ago
    • Reported - view

    Comments:

    VPN Conflict - enabled but marked "Not working" in macOS 11.2.3, though still confusing.

    It is also the case with Kaspersky Internet Security, some settings can even inject httpS traffic.

    FYI Kaspersky and LittleSnitch works fine together... that makes a lot of filters before reaching out and both breaks the encrypted DNSR.

    Some VPNs allow to use other DNSR, this can help partially the problem.

    Chrome always use 8.8.8.8 etc when it can not reach other DNSR.

    POC, use a fake/invalid DNSR and it will uses its own after a ~30 sec.

    • Gage_Randall
    • 3 yrs ago
    • Reported - view

    I’m not sure if this helps but on iOS/iPadOS I utilize DNS Cloak as my VPN Configuration and any VPN I use under the Personal VPN Category as well (i.e. NordVPN). I find this combo works well for me to get my encrypted DNS Lookups in addition to being able to browse the web in an encrypted fashion as well. It’s the only way I’ve been able to get both to function instead of using the new DNS Profile or the NextDNS iOS App.

    Mac I have no issues and I am able to use the NextDNS App in conjunction with NordVPN.

    • iamtheanon
    • 3 yrs ago
    • Reported - view

    Just a suggestion to anyone on MacOS, simply run the NextDNS CLI instead of the official app or the encrypted DNS. As far I have tested the Profile is the one creating the issues. While that will/may be resolved in the future it is better to use the CLI since it offers the same or better functionality than the Profile since you can customize everything more. 

    Instructions are here: https://github.com/nextdns/nextdns/wiki/MacOS

    I have installed via brew which works perfectly system wide on my M1 Mac. 

    • Berkay
    • 3 yrs ago
    • Reported - view
    • orange_quill
    • 3 yrs ago
    • Reported - view
    iOS: Disabled after VPN disconnect
    In some (still unidentified) cases, the configured encrypted DNS does not reconnect once an IKEv2 VPN is disconnected. The default system DNS is used instead.
    A system reboot or removing the VPN profile is required to solve the issue.

     I can also reproduce this on iOS 14.6 and iOS 15 Beta 3. But, it’s not necessary to reboot the device.

    Quickly connecting and disconnecting the VPN through Settings will solve this issue.

    • Michiel
    • 3 yrs ago
    • Reported - view

    on ios15, the nextdns app has no option to exclude wifi-networks. In the previous version it was possible...

      • mlapida
      • 3 yrs ago
      • Reported - view

      Michiel I’m having the same issue.

    • Chris_Leidich
    • 3 yrs ago
    • Reported - view

    I can reliably reproduce the Chromium bypass bug on my Mac system. I can also reproduce the IKEv2 issue that bypasses the DNS profile after the VPN is activated. 

    • ray_toth
    • 3 yrs ago
    • Reported - view

    cant make a post in network speed fourm no buitton to post new topic or replying here so posting here im slow in desplaines il here info https://nextdns.io/diag/91aa7df0-58b4-11ec-ba7b-05650c85028b

    • edward_a
    • 2 yrs ago
    • Reported - view

    What can be done to make sure DNS takes priority over VPN on iOS? 

    • fuchsia_bear
    • 1 yr ago
    • Reported - view

    Facing this exact issue, except it happens after a disconnect from a Wireguard tunnel, not an IKEv2. Even a iPhone reboot does not fix this.

     

    When VPN is up, I am well using NextDNS (because I added the IPv6 in the VPN config, since iOS ignores the VPN profile, see known issue 1!).

    iOS 16.4.1, VPN is Mullvad 2023.2

    let me know if you need more info!

    • Henry_Matter
    • 8 mths ago
    • Reported - view

    I'm having the Chrome issue on Mac OS 14.4.1 - How do I report this as requested?

    Thanks

    • MajorTom
    • 6 mths ago
    • Reported - view

    Give the original age of the article itself, I wonder if the team behind the service has plans to a) report the things that weren't reported and b) stress the already reported items again (and again...)