Apple Services after not available after some time. Only renewing the internet connection will solve it.
pictosun opened this issue · comments
Platform
macOS
Protocol
DNS-over-HTTPS
Do you use AdGuard app?
No I don't
Your configuration
- macOS/iOS (newest system update)
- using .mobileconfig Profiles on macOS/iOS (and also tried AdGuard Pro App with AdGuard DNS as native profile)
- tried DoT/DoH with .mobileconfig and DoQ (with a 3rd party app and without .mobileconfig)
- block Apple private relay function is 'not' used (and I do have apple services on my whitelist)
Traceroute to AdGuard DNS
./. doesn't matter
Issue Details
- While using iOS/macOS devices after several amount of time (especially when changing networks from mobile to WIFI and so on) it does happen that Apple services like App Store, Apple Music do not work anymore.
- Even force quitting the apps don't bring back connection to the services
- when putting the devices into flight mode and back online the services do work again
Expected Behavior
It should work all the time
Actual Behavior
When using AdGuard DNS (with some blocklists) the problem exists and reappears often.
Screenshots
No response
Additional Information
When using some other DNS services like NextDNS, ControlD etc. (nearly same blocklists enabled) the issue is not existent
It looks like it's something correlated to AdGuard DNS service at all?
Hello there!
Please clarify the following information:
- Do you use third-party software like a VPN?
- Which blocklists are enabled?
- What DNS server are you connected to?
Do you use third-party software like a VPN?
- No 3rd party tools
Which blocklists are enabled?
- HaGeZi Pro & TIF, DynDNS, DNS/VPN/TOR/Proxy Bypass and Gamling | Smart-TV Blocklist for AdGuard Home (by Dandelion Sprout)
What DNS server are you connected to?
- dns2-dp-fra-5
To start, the easiest test is to try to disable all third-party filters except AdGuard DNS and check if the issue persists.
In turn, we'll investigate the situation on our side.
Will try to look at it with iOS 17.5 and macOS 14.5 installed. Maybe it's a Apple bug which has been resolved?!
@Chinaski1 I can give you the update, that the issue just appeared again when changing WAN networks.
I also checked the query logs and cannot see any block within this time and/or domains... So the blocklists shouldn't be the issue and it looks like it is something else.
Changing DNS profile to some other provider solves the issue. Going back to AdGuard DNS after that also works.
EDIT:
Found out, that those issues also have on my Teamviewer App (logged out and said no service possible) after changing the WAN network. So definitively not an Apple only thing.
Just do give you an update over here... When changing to an other DNS service (Contr...D, Ne...DNS) I do not have those issues (using nearly the same blocklists) and I think it's not related to blocklists itself, as there is nothing showing up within blocked queries.
So something must be different within AdGuard DNS?
Could it maybe something correlated to this: #227
At this stage it is difficult to say what may be causing the issue. It is not reproduced on our side, we are looking into it.
I use AdGuard DNS via mobileconfig on 10 Apple devices, including iPhones, iPads, Macbooks and Apple TV and do not have this problem and cannot reproduce it.
Thanks for your feedback. Really a strange behavior. For me I can more or less reproduce it on several devices with several kind of blocklists (don’t think the lists are the issue).
What I (maybe) found out is, that it is eventually related to changing WAN networks with IPv4/IPv6 changing.
At home I do have dual stack, at work IPv4 and mobile it depends on.
Don’t know if this is maybe the case and has something to do with my issues.
As it happended to several macOS/iOS versions I don’t think that this is the case. Especially while hagezi says that everything is fine for his devices.
Don’t know how can look into more details to report it over here to find the reason why this is happening (and also only happening when using AdGuard DNS - with NextDNS and ControlD and other DNS services I don’t have those issues?!).
As I said, I will try to narrow it down so that finding the reason is easier?!
Thanks for your product and help over here.
Try unblocking this domain "mesu.apple.com"
This domain must be unblocked for the Apple TV App to work on Apple devices, but it might require other Apple services.
Try unblocking this domain "mesu.apple.com"
mesu.apple.com is always unblocked
As mentioned above I don't think it's an issue with any blocking list at all, as it does happen regardless of entries in any list.
So it must be something else. I think it has to do with some kind of network change (IPv4/IPv6) and maybe AdGuards way (the other players like NextDNS and ControlD,... don't do this) to check other resolvers (Google, Cloudflare) when getting a SERVFAIL response.
Or they're still doing something different within their implementation.
When trying out AdGuard Home on a VPS it also doesn't happen.
And as mentioned above it's quite hard to find out what's causing the issue.
I've been experiencing this for the last few weeks as well when accessing the Apple App Store, it will refuse to connect intermittently.
Many other Apple services seem to be playing up as well.
When trying out AdGuard Home on a VPS it also doesn't happen.
Are you also using AdGuard DNS (unfiltered) as upstream, if not you should test whether the problem also occurs when using it. If the problem occurs, have a look at the log and check whether one of the corresponding domains returns SERVFAIL as a result.
https://unfiltered.adguard-dns.com/dns-query
Are you also using AdGuard DNS (unfiltered) as upstream, if not you should test whether the problem also occurs when using it.
Thanks for your feedback. I will give it a try.
But what about Bootstrap DNS and Private reverse DNS Servers? At the moment they're running with my Unbound resolver on the VPS.
Do I also need to change them to test it?
No, only the upstream DNS.
I've been experiencing this for the last few weeks as well when accessing the Apple App Store, it will refuse to connect intermittently.
In which scenarios for you? When changing WAN networks (home WIFI to some other networks), or don't you know?
I've been experiencing this for the last few weeks as well when accessing the Apple App Store, it will refuse to connect intermittently.
In which scenarios for you? When changing WAN networks (home WIFI to some other networks), or don't you know?
Both wifi and mobile, with different providers.
DNS is setup with a configuration profile, so I can rule out AdGuard for iOS, or any other DNS app.
Are you also using AdGuard DNS (unfiltered) as upstream, if not you should test whether the problem also occurs when using it.
The problem does not occur when using it this way. But I'll keep testing it.
I assume that you also use your AdGuard Home VPS via mobileconfig to at least use a similar test scenario?
Yes - same devices. Made a mobileconfig (same protocol DoH) and same blocking-lists (but I don't think it's because of the blocking lists as mentioned above).
Just to give a short update. Changed back (after no issues when using AGH on VPS with AdGuard Servers as Upstream) to AdGuard DNS.io mobileconfig and the issue came back immediately.
So the issue is definitively somehow within adguard-dns.io implementation.
@pictosun Are you using a mobileconfig in which the home network WLAN is excluded, i.e. your local DNS is used when you are in the home network?
You could test whether the problem also occurs with a self-generated mobileconfig, you can use the following generator: https://dns.notjakob.com/tool.html
I would test an unsigned mobileconfig.
Are you using a mobileconfig in which the home network WLAN is excluded, i.e. your local DNS is used when you are in the home network?
No - I didn't exclude it. Scenario at home:
- Router: DoT profile adguard-dns.io (because of Router only supporting DoT)
- Devices: DoH mobileconfig profile (with exclusions)
At work:
- Router: no profile at all
- Devices: using same profiles as above
It is happening at work and at home when changing networks. So I don't think it's because of network exclusions or not (and other providers do work - no matter of exclusions or not)
Or did I understand you wrong?
Strange, try a self-generated mobielconfig, just to rule out that this is the cause. For whatever reason.
What steps are you taking to reproduce the problem?
What steps are you taking to reproduce the problem?
Normal behavior during the day. Leaving the house (and then checking Apples App Store for connection). Coming back home and so on.
Today morning I changed mobileconfig back to adguard-dns.io and after leaving the house and coming back the store was not available (no internet connection).
When using AGH via VPS and mobileconfig those issues are not there (same with NextDNS, ControlD and others). Only adguard-dns.io with the issue.
Crazy, I can't reproduce the problem. I use a generated mobileconfig from AdGuard DNS where only the fritz.box domain is excluded.
Does the problem also occur when you switch from Home to Mobile and back to Home (WLAN off/on), or only when you switch from Home to Mobile to Work and then back to Mobile/Home?
Does the problem also occur when you switch from Home to Mobile and back to Home (WLAN off/on)
Yes. Most of the time I'm in home office so I can reproduce it quite often.
I also do use the generated mobileconfig from AdGuard. fritz.box domain is not excluded in my case. But don't know if this is the issue?!
only the
fritz.boxdomain is excluded.
How did you exclude it? Via dashboard > Access settings > Disallowed domains ? Or in any other way?
I don't think that's causing your problem.
When you create a mobilconfig, there is a link to a profile constructor. You can exclude e.g. local domains so that the local queries are not made via AdGuard DNS, but directly via the assigned default DNS. If fritz.box is excluded, *.fritz.box is resolved via the FritzBox, if the clients have been assigned the FritzBox as DNS server via DHCP.
I don't think that's causing your problem.
Thanks. Will test it and give feedback. I also don't think that this is causing the issues.
@hagezi
After some testing I can say, that excluding fritz.box doesn't solve the issue.
Today I also recognized, that it also appears when coming out of flight mode). Maybe because disabling flight mode causes a short connection to LTE/5G and after that jumps to WIFI.
So to reproduce it:
- toggle flight mode (getting mobile network and wifi)
- go to iOS App Store > no connection
- disable wifi > App Store does work
- enable wifi again > App Store still works
no blocks within query log or somewhere else.
Really annoying issue!
@pictosun I have carried out the steps to reproduce the problem several times and cannot reproduce it.
That really is a strange thing. Don't know what else I can do to troubleshoot and/or to find out, what's going on there?
After some testing I can say, that excluding fritz.box doesn't solve the issue.
Today I also recognized, that it also appears when coming out of flight mode). Maybe because disabling flight mode causes a short connection to LTE/5G and after that jumps to WIFI.
So to reproduce it:
toggle flight mode (getting mobile network and wifi)
go to iOS App Store > no connection
disable wifi > App Store does work
enable wifi again > App Store still works
no blocks within query log or somewhere else.
Really annoying issue!
These steps reproduce this issue for me also.
Thanks for your feedback. So I'm not alone. Don't know what to do now.
Maybe the developers will give a hint how to check something else or maybe there is somewhere a bug from AdGuard DNS itself?!
Also found out, that there is no update over here since a longer time concerning the code...
Today I found out, that the issue also exists, when using my WIFI-only iPad within my local WIFI network (and not changing the network). Just had it lying around and then I searched for updates within the iPad OS App Store and it says no connection.
I'm using the same Server (profile) within AdGuard DNS settings. So I checked again the logs and found, that I had a block from 'ca.iadsdk.apple.com' from a list (Hagezi) several time ago.
During the 'outage' of the App Store service (Apple Music was working), I tried it several times (and did not disable/enable WIFI > as this would solve the issue).
I checked the settings within the Server (profile) and changed my TTL from 3600 to zero.
And after this change the iPad OS App Store started directly.
I checked again the logs and got one more block this time. It was quite close to the other one but little bit different 'tr.iadsdk.apple.com'.
But even when blocking this request it works.
So maybe it must be something with setting up TTL and having requests to some domain and during the TTL blocking time apple changing the subdomain of the already blocked domain?
Scenario:
- App Store says no Internet connection
- logs say: ca.iadsdk.apple.com > blocked (a few minutes ago)
- changing TTL from 3600 to 0
- App Store works
- logs say: tr.iadsdk.apple.com > blocked
- but system still working
@hagezi Hope this is now a better scenario to find out what's going on there?!
I setup a TTL of 3600 for my mobile devices AND also a TTL of 3600 for my router (fritz.box DoT profile).
Router and devices nearly have the same lists.
And SORRY for saying that it doesn't show up within my blocking lists (but I never thought, that those iadsdk... domains can have an issue and I also didn't see them because of the TTL and having them little bit more down within my query lists.
@emeritaacuity0u can you check, if you also have setup a TTL for your servers/profiles?
And maybe you can troubleshoot the way I did?
I also use a block TTL of 3600, I cannot reproduce the problems with it. I can't imagine that this is the cause either.
Ok - you're using the TTL in both variants? For your router and your clients? Or only within one Server (profile)?
This is my setup. There's no other modifications.
@emeritaacuity0u Did you try to set TTL to 0?
As @hagezi said, the TTL was not the point. The issues are still there and happening again and again.
So as my iPad only has WIFI access I can say:
- changing TTL doesn't help
- blocklist also seems not to be the point
- mobile network vs. WIFI jumping through WANs is also not the point (iPad is WIFI only)
I'm a bit loss what it could be else if not some kind of implementation from AdGuard DNS itself (doesn't happen with other providers as already mentioned)
Maybe someone else has an idea how to troubleshoot this issue?
I can't think of anything else at the moment. If you have blocked Private Relay, you could try to see if the problem still occurs when PR is not blocked.
No - private relay is not blocked and I do have additional whitelisting of those domains.
I unticked the block private relay thing within AdGuardDNS and these are the additional whitelist rules:
- doh.dns.apple.com
- mask.icloud.com
- mask-api.icloud.com
- mask-h2.icloud.com
- doh.dns.apple.com.v.aaplimg.com
Today it already happened two times with my MacBook which is within my home WIFI only.
But it looks like it is more and more Apple App Store only. Sometimes it also happens with Apple Music (very rare). But must of the time it is the App Store on all devices.
I'm at the end of my tether too. I absolutely can't reproduce it, no-one in my immediate and extended family can. On none of the Apple devices and these are some that use AdGuard DNS via mobileconfig.
Have you looked at the result of the requested domains in the log when this happens? Does an IP come back, NXDOMAIN, SERVFAIL or do the requests perhaps not end up at the DNS at all?
As we can see that also @emeritaacuity0u has those issues I'm not alone at all.
Maybe some developers like @Chinaski1 can jump in and help? Are you working on AdGuard DNS and maybe have looked into those issues? Will we see some changes coming with a new release in future?
@hagezi Concerning '*/cf/tr.iadsdk.apple.com' I do get a blocked result with NOERROR as answers for A,AAAA,HTTPS (it's always 3 requests for apple devices)
For 'mask.icloud.com' I do get unblocked and also NOERROR as answers.
I also installed LitteSnitch and tried it via DoQ profile on macOS (LS does use DNS Proxy network extension) and it happens even there.
So it's not the DoH mobileconfig alone...
Test the following on the iPad: Do not use the Fritzbox as the system DNS, but Cloudflare 1.1.1.1, for example, and continue to use the AdGuard DNS mobileconfig as the encrypted DNS.
See if this also occurs with a public DNS, which is then used as a bootstrap for the steering.
Apart from that, I can't really think of anything else you could try.
Test the following on the iPad: Do not use the Fritzbox as the system DNS, but Cloudflare 1.1.1.1, for example, and continue to use the AdGuard DNS mobileconfig as the encrypted DNS.
I don't get exactly what you're talking about...
If I setup a mobileconfig it does use the DNS over the mobileconfig.
You mean leaving the mobileconfig enabled and change WIFI network DNS config from automatic to 1.1.1.1 for example? Or what do you mean?
Yes, exactly that. The "WiFi DNS" is used as a bootstrap DNS to resolve the DNS domain from the mobileconfig.
@hagezi It looks like the test does work. When setting for example 1.1.1.1 as DNS within network settings the issue is gone (at least so far).
So now it's getting interesting why this does happen and what's the cause?
Next, use 1.1.1.1 as upstream in the FritzBox and the FritzBox as ‘WiFi DNS’ as before.
I changed the DNS of fritz.box to 1.1.1.1 (one.one.one.one DoT within) and on all my devices back to standard (away from 1.1.1.1 back to automatic) and the error just came back on my iPhone in this case. (iPad is doing well - but I just started testing).
@pictosun
Hello there!
We're monitoring the situation but unfortunately we can't reproduce the issue on our end.
We're monitoring the situation but unfortunately we can't reproduce the issue on our end.
Thanks for your feedback. What I can say for sure is, that it's not the mobileconfig itself because it also happens on systems with dnsproxy installed and also when using DoQ instead of DoH.
And it also looks like it is not some blocklist itself. Must be something different.
Would be nice to get some feedback from @emeritaacuity0u as he is also having those issues.
I don't have anything more to add at this stage.
When using any AdGuard DNS server, my iOS App Store has connection issues intermittently. When I use another companies DNS server, it works.
@emeritaacuity0u which Blocklists do you use?
AdGuard DNS filter.
The issue isn't happening with ControlD, or NextDNS for me.
So it's definitively not the filter list at all. We do use completely different lists.
@Chinaski1 Maybe any advice what we both can do to troubleshoot more? What about the SERVFAIL fallback to CF and Google - could this maybe causing the issue for users?
Could it be maybe something with EDNS (ECS ) implementation. When changing WAN networks (IPv4/IPv6) and maybe jumping to another EDNS (ECS) that the requests to some service (Apple App Store etc.) are somehow corrupted and you don't get correct responses?
Just an idea.
Let's try at least narrow it down to either filtering issues or the DNS server issues.
Please try using AdGuard DNS Unfiltered configuration (unfiltered.adguard-dns.com), if the issue can be reproduced with it then the culprit is filtering (filter list, access settings, etc, there are many things that change the normal DNS resolution).
If it's reproduced with AdGuard DNS Unfiltered, then we'll be looking from that side.
And one more thing. I guess we're at a point when to troubleshoot we need to look at the device logs.
Hi @ameshkov
I will try it. You mean generally using unfiltered.... as DNS mobileconfig for the devices and the router?
What about device logs? Which logs do you mean in general so that I can investigate.
AdGuard DNS filter.
The issue isn't happening with ControlD, or NextDNS for me.
@emeritaacuity0u Can you see any changes? For me it looks like it is getting a bit better (not that often blocked like it was a week or two ago).
With ControlD, NextDNS it still 'never' happens at all.
Just a short update. Today it started to get really bad again. As it is not always the same I do believe that it is definitely something ad AdGuard side, what is bringing up those issues.
@ameshkov What could it be, that the last days it was quite ok and with this (morning) it started to behave really bad and I'm getting more issues than the days before?!
I will try it. You mean generally using unfiltered.... as DNS mobileconfig for the devices and the router?
The same way you setup the normal DNS.
What about device logs? Which logs do you mean in general so that I can investigate.
If it's a macOS device there's a "Console.app" that has all the device logs. It should have the necessary info.
If it's a macOS device there's a "Console.app" that has all the device logs. It should have the necessary info.
@ameshkov Today I had those issues on my macOS machine and started console.
Did some filtering of all the entries and could find, that there are some issues before the connection got working again. Don't know if any of those correlate to the issue but here are some:
- mash.hash does have some kind of issues and so on (CNAME) and answers like
mDNSCoreReceiveCacheCheck: rescuing RR with new TTL 15and somemDNSCoreReceiveNoUnicastAnswers: Removing expired record<mask.hash: ...> - an a lot of
AMSURLRequest: [...] Failed to fetch client ID domains from bag. Defaulting to not including analytics cookies. error = { Error domain=AMSErrorDomain, code=204 | URL = https://amp-api.apps.apple.com/v1/catalog/de/apps?REDACTEDbefore it will start running again - when it starts working again I get:
AMSURLSession: [....] Task finished loading for URL request <AMSURLRequest: ....> { URL: https://amp-api.apps.apple.com/v1/catalog/de/apps?REDACTED } activating connection: mach=false listener=false peer=true name=com.apple.ak.anisette.xpc.peerfailed to do a bootstrap look-up: xpc_error=ServerDataCacheService Finished running background update for ... ["deny-list"] failed
Hope some of the messages can help to troubleshoot.
Unfortunately I only have very limited knowledge, but I would still like to make a guess...:
Could it be that it is because macOS performs/expects a certain caching here and if you open the App Store, for example, and the same server does not respond as stored in the caching (due to the dynamic change of the AdGuard DNS servers), that problems then occur as described? See #790
@pictosun I think it's an iOS steering problem, you've tested it yourself. If you use 1.1.1.1 as the system-wide default DNS in iOS instead of your router (FritzBox) and also use the AdGuard DNS mobileconfig, the problem does not occur according to your statement.
Which FritzOS version are you using? The version prior to Fritz!OS 7.59 had problems with DNSSEC in combination with DoT.
You should test the following again. Use the FritzBox as system DNS as usual. In the FritzBox you use 1.1.1.1 as legacy Internet DNS not via DoT!
As I said, we operate countless Apple devices here in our immediate and wider circle of family and friends with AdGuard DNS and nobody has these problems.
@hagezi Thanks for your feedback. Will give it a try. It does happen for iOS and macOS and 'only' when using AdGuard DNS (not with NextDNS and ControlD).
As far as I understand your explanation the issue also should occur when using any other provider, or am I wrong?
And the other thing is, that it also happens when on the go via mobile network (and no fritz.box - hopefully - at provider side).
@emeritaacuity0u Do you have a fritz.box within your network scenario when the issue occurs?
7590AX on FRITZ!OS 7.81.
I wont be able to try it out anytime soon.
As the issue happens both on and off the home network though, the router is not my single point of failure.
Thanks for your feedback.
So it must be something else what is causing those issues.
@hagezi After some reading I tried another approach... I read somewhere, that errors can occur, when using a DoT profile with a number at the 'beginning' of the URL. So I tried to make a new profile (mobileconfig) starting with a letter. And will check, if this will work better? Don't know if this is true (I can't really imagine) - but I will give it a try.
Another point is maybe what I asked within #792 - and forgive me if I'm wrong with this. I'm not an expert - I try to help with my means as best I can.
And will check, if this will work better? Don't know if this is true (I can't really imagine) - but I will give it a try.
Doesn't help. The issue occurred again and again.
So sad to see. Today I made some research and found out, that @emeritaacuity0u and myself are not alone. But they're not reporting it to Github.
Don't know, if they do switch to another provider or just ignore the issues.
Of course I'm now trying to click Apples App Store more often, than before. But it really is annoying to see all those outages while using AdGuard DNS.
And as I already said before it must be something on AdGuards end, as it really never happens with any other DNS provider (ControlD, NextDNS, native provider, Cloudflare, dnsforge and many others).
It really looks like AdGuard is doing something different in some way but I don't know what and why this makes it so unreliable (at my side).
And as I already said before it must be something on AdGuards end, as it really never happens with any other DNS provider (ControlD, NextDNS, native provider, Cloudflare, dnsforge and many others).
Do you set them all up using a DNS profile?
In general, is it true that the problem only happens when you set up AdGuard DNS using a .mobileconfig file?
If and only if this is true, we may try specifying the IP addresses in the mobileconfig file. You can create such a file yourself, just replace xxxxxxx with your device ID in the content below.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>DNSSettings</key>
<dict>
<key>DNSProtocol</key>
<string>HTTPS</string>
<key>ServerURL</key>
<string>https://d.adguard-dns.com/dns-query/xxxxxxx</string>
<key>ServerAddresses</key>
<array>
<string>94.140.14.49</string>
<string>94.140.14.59</string>
</array>
</dict>
<key>PayloadDescription</key>
<string>Configures device to use AdGuard DNS</string>
<key>PayloadDisplayName</key>
<string>AdGuard DNS Personal</string>
<key>PayloadIdentifier</key>
<string>com.apple.dnsSettings.managed.64a1d190-a00a-4d81-92e8-33a37b255df6</string>
<key>PayloadType</key>
<string>com.apple.dnsSettings.managed</string>
<key>PayloadUUID</key>
<string>29bbe037-a2d0-4d10-a2c5-3111fb99f9a4</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</array>
<key>PayloadDescription</key>
<string>Configures device to use AdGuard DNS</string>
<key>PayloadDisplayName</key>
<string>AdGuard DNS Personal</string>
<key>PayloadIdentifier</key>
<string>15ca3ab0-91dc-43ef-ab02-4a3cbe64385d</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>38cc616a-3d9b-4aba-a501-ee31dfd82a08</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
Do you set them all up using a DNS profile?
In general, is it true that the problem only happens when you set up AdGuard DNS using a
.mobileconfigfile?
@ameshkov Thanks for your feedback.
In earlier times I also tested DoQ and DoT for macOS (with Little Snitch 6 and it's new DNS proxy integration) but cannot remember if it also happens there or not as the macOS systems don't move that often to other WAN networks.
Concerning the mobileconfig:
- yes I do use mobileconfigs the last weeks and I cannot say if it also happens any other way as it's mobileconfig-only for me.
But when checking your .mobileconfig created from the dashboard it looks like I found a few small bugs.
- See the screenshots. It looks like there are some wrong characters within mobileconfig-creation.
Don't know if this is causing the (or any) issues?
Overall it looks like a bug which should be corrected in general.
@ameshkov Concerning the bugs within mobileconfigs should I open a separate bug issue or is it ok, when leaving it over here as you will solve the issue internally?
What do you use to view the internals of a signed mobileconfig?
I don't think a mobileconfig with the highlighted errors can be installed in general as it won't be a valid XML. Could it be that the viewer that you're using is distorting them somehow?
What do you use to view the internals of a signed mobileconfig?
I'm using some kind of editors (CotEditor, BBEdit and so on). The important part of those files is always readable.
If I open it with CotEditor in this case it shows:
So different but also not regular character set.
And as I already opened/edited and worked with many .mobileconfigs and never have seen such inconsistencies within this part of this configs I thought, that this could be a bug at all.
My point is that with the errors that the editor shows macOS/iOS wouldn't be able to import the file so most likely the problem is with the editor.
I didn't edit the files. I was just looking at them to find maybe in error because of the issues I do have....
Isn't it strange that nearly all of those entries are correct, and only 2-3 are wrong. So I thought there is something wrong within automatic .mobileconfig creation at all.
I am saying that the editor fails to read the signed content properly.
Anyways, have you tried a mobileconfig with server addresses specified? Does it help?
Anyways, have you tried a mobileconfig with server addresses specified? Does it help?
Cannot say for sure. I'm still testing. One config with IPs and the other one with hostnames - both are running at the moment. The problem doesn't exist all the time - looks like it sometimes happens more often than other times...
So it's not that easy to find out what's the issue at all.
Just to give a feedback, that it also happens on systems using DoQ and DNSproxy (like LittleSnitch is offering). So it's not a mobileconfig issue at all.
Happened a few minutes ago again... After a special amount of time it starts working again and the first entries within the logs are requests to CDNs (but that's normal I think because of Apple using CDNs for their App Store).
But maybe that's something to put in consideration when finding out the issue?!
And another short update... Next device is also having issues. I think it could be something correlated to #795 as I'm seeing huge spikes there when checking TCPPing, DNS probes etc.
And the next device is getting those errors... At the moment a lot of issues.
@emeritaacuity0u Any update(s) from your side?
No, I do not have time to test.
Well we tried every indirect way to figure out what's happening and I guess at this point the only thing that can answer this question is the device logs exported from console app + the exact time when the issue happened + a detailed explanation of what was happening at that time (how did you understand that something is wrong and what happened next).
Today a lot of issues appeared again.
As mentioned a few posts earlier it could really be something because of the errors within automatic .mobileconfig configuration profiles when downloading them via dashboard.
See the error message within console.
@ameshkov Enclosed some more details to my latest post. It really looks like the issue is coming from your side (somehow).
-
NESMDNSSettingsSession[d.adguard-dns.com DoH:REDACTED]: Removing a connection for client Network[REDACTED]
-
NESMDNSSettingsSession[d.adguard-dns.com DoH:REDACTED]: Removing a connection for client VPN[REDACTED]
-
AMSTreatmentStore: [REDACTED] Failed to fetch areas (error: { Error domain=NSCocoaErrorDomain, code=260)
-
TCP Conn [23:REDACTED] using empty proxy configuration
-
activating connection: mach=false listener=false peer=false name=(anonymous)
-
in_progress parent-flow (satisfied (Path is satisfied), interface: en5, ipv4, ipv6, dns)
-
nw_protocol_boringssl_signal_connected
-
nw_endpoint_resolver_update [C5.1.1 Hostname#REDACTED:443 in_progress resolver (satisfied (Path is satisfied), interface: en5, ipv4, ipv6, dns)] Adding endpoint handler for IPv6#REDACTED.443
A couple of lines without other details don't help much, sorry.
We need three things to troubleshoot, not having one of three makes troubleshooting impossible.
- Issue description (what happened, what error have you seen in the UI)
- Exact time of the issue
- Logs exported from console app (hand-picked lines are not enough since we don't know what we're looking for yet). I understand that sharing the whole log file might be too much, but can you at least export a 2-3 minutes period that corresponds to the time when you experienced the issue?
Thanks for your feedback.
The point is, because of privacy reasons I cannot send you those logs as it's too much private information inside.
What's happening all the time is that I cannot connect to Apple services when using your DNS services within my setup. (see screenshot).
When reconnecting to the network(s) it does work again (don't know if it's a caching issue or something else?).
And it does only happen when using AdGuard DNS services....
Left is Apple Music, right is Apple App Store
I have an idea:
I think I will try now a .mobileconfig using the same DoH setup as your generated .mobileconfig one and doublecheck if it is working without any issues... (will use one generated by https://dns.notjakob.com)
But overall I don't think it will solve the issues as I already tried it via DNSproxy and LittleSnitch DNS configurations.
But let's see if I see any difference.
I don't know if this is mentioned in this thread before, but this issue affects every platform, the AdGuard dns profile is installed to (iOS, iPadOS, macOS & visionOS). On my end, even though I excluded my WiFi SSID, this bug still affects me!
Note: I have always had my router set to the public AdGuard dns (ipv4 & 6), it isn't affected by this bug.
@Wrestor Did you install the .mobileconfig from AdGuard DNS Dashboard or created one by yourself? Does the issue happen all the time at your side (even if it is difficult to control it all the time).
@pictosun I'm using the Default Server configured via "Method No2: Configure AdGuard DNS manually" > iOS > open profile constructor. DoH & entered my wifi ssid to disable it on my network, as i am already using my router configured with their dns(Default server as well).
@Wrestor Thanks for the feedback.
Is it possible for you to try out some stuff.
For me I'm testing an self created mobileconfig and since yesterday it does work well without any issues (but it's only a small amount of time).
You can create them for yourself via the entry above from @ameshkov or for example via this one https://imazing.com/profile-editor or https://dns.notjakob.com
Will test a bit longer and when everything is doing will it looks like the AdGuard DNS dashboard profile creator does have some issues (but at the moment it's to early to say).
Maybe you can also jump and test so that I'm not alone here.
Short update from my side. Those manually created mobileconfigs don't help. The issue is still there.
Looks like I have to change the provider as it's happening all the time for every client within my family. 😢
Unfortunately I've had to do the same. The issue isn't isolated to the mobile config's and happens when you use the AdGuard for iOS app with either native or AdGuard DNS implementation.
I've used DoT, DoH2, and DoH3 with AdGuard Personal DNS with the same outcome.
So let's hope someone somehow finds out what those issues are... @emeritaacuity0u @Wrestor are you still 'on board' or already jumped to another provider?
@hagezi and/or @ameshkov Could it be also be some weird setting within iCloud Private Relay, Hiding IP Addresses from Trackers, Prevent use advanced tracking and fingerprinting protection or something else?
I've seen within your knowledge base at the website, that you describe a few settings there, but as far as I know @hagezi is using some of the settings?
Gerd, how did you manage those settings in detail?
- iCloud Private Relay on/off?
- separate network settings for hiding IP Addresses on/off?
- advanced tracking and fingerprinting protection within Safari on/off?
- Settings within Safari and mail concerning hiding IP addresses from trackers on/off?
And overall en- or disabled the setting "Block access to iCloud Private Relay" within AdGuard-DNS Dashboard?
Maybe that's the reason of all those issues?
I am not entirely sure if iCloud Private Relay is used by iTunes app tbh. Do you have it enabled?
No - I don't have it enabled, but there many other settings which could also be some kind of influencing iTunes and especially Mac/iOS App Store where the issue occurs...
Maybe @hagezi can jump in an say how he has configured all those settings as mentioned above. So it's easier to troubleshoot from my side as there are too many combinations to test.
You have written that you have disabled these options, so it cannot be the cause of your problem. For me, it also makes no sense to play the combination lottery with these options.
Just do the test that has already been requested here, take the unfiltered AdGuard DNS as mobileconfig and see if the problem also occurs with it, see #777 (comment)
Furthermore, according to one of your statements, it works if you use Cloudflare 1.1.1.1 as the system DNS instead of your router, for example, and at the same time a mobileconfig that uses an AdGuard DNS profile. The steering (the resolution of the dns name from the mobileconfig) then takes place via the Cloudflare DNS and not via your router and the upstream DNS configured there. You could then search further in this area, but everything has already been said.
We're going round in circles here ...