![]() > iOS 16 ignores trusted CA certificates -> Bug (imho)Īs the AGH is only used internally it is way to complicated to install a public accepted certificate. No HTTPS or TLS requests and therefore no issue Sadly the AGH admin interface is bound to this.įeature request: Untie DNS encryption (via 443) from admin UI encryption. Seems that I cannot use DNS encryption anymore. ![]() Nevertheless the client trusts the CA root cert. That's correct because it is a cert signed by internal CA. OK, the client complains about a certificate. Then some log entries I do not understandĩ 21:15:12.578650 828#146 /AdguardTeam/dnsproxy/proxy.(*Proxy).ServeHTTP(): Incoming HTTPS request on /dns-query?dns?dns=AAABAAABAAAAAAABCWt3ZWxsa2>ĩ 21:15:12.578748 828#146 net/http.StatusText(): Cannot parse DNS request fromĩ 21:15:19.562349 828#240 /AdguardTeam/dnsproxy/proxy.(*Proxy).handleTCPConnection(): handling tcp: started handling tls request from 172.20.xx.xx:5>ĩ 21:15:19.580554 828#240 handling tcp: reading msg: reading len: remote error: tls: bad certificateĩ 21:15:19.585798 828#241 /AdguardTeam/dnsproxy/proxy.(*Proxy).handleTCPConnection(): handling tcp: started handling tls request from [fd77:xxxx:xxxx.>ĩ 21:15:19.599970 828#241 handling tcp: reading msg: reading len: remote error: tls: bad certificate I created a detailed log and this is what I found so far. So far, not good, because I want to know the root cause of the issue. In my config I have encryption activated with an internal cert, which was not a problem in the past. My workaround is that I have a plain port 53 IPv4 dns on another machine and that seems to solve the issue for now. Let me know if you need further information like configs.ĪGH accepts connections on IPv4/6, but connections seem to be partially broken at the moment for iOS16. #2: I configured manual DNS settings on iOS only to use my AdGuard Home IPv6 DNS server. #1: I set up another DNSv4 server and configured it via DHCP to be used for my devices. Here some workarounds that helped me (hopefully temporarily) to come around this issue. The issue does not exist for devices running iOS 15.6.1 or iPadOS 15.7! ![]() This can also be reliably reproduced by turning wifi off and on again. (Don't know why iOS prefers IPv4 DNS over IPv6) via safari or another app).Īfter a lot of investigation I found, that this issue is likely related to IPv4. When I wake up a device it takes up to 20 seconds until it gets a response for a DNS request (i.e. Since then I am facing the issue that AdGuard Home does not work properly together with the new iOS. Last week I updated two iPhones (X and 12 Pro) to iOS 16. So first of all thank you for this great product. I am running AdGuard Home in a Proxmox Container (on Debian Bullseye) since a long time without any issues. GitHub releases or script from README Setup Linux, Other (please mention the version in the description) CPU architecture I want to report a bug and not ask a question I have searched other issues and found no duplicates Just let your local nameserver do its job.I have checked the Wiki and Discussions and found no answer But why would you do that? You are handing the owner of that single server all your privacy relevant information on a silver platter. You can run your own but then force it by configuration not to do all that, but instead forward all your request to a single configured upstream nameserver or "forwarder". This is at the same time the best protection of your privacy available, because no single entity will ever receive all of your lookup information. If you run your own it simply works like this. ![]() Or you can use 8.8.8.8 - then Google does that on your behalf all the while learning about what domains you lookup. Then your ISP's nameserver does precisely that. If you don't run your own nameserver, your simple router can tell your client systems the address of the nameserver(s) provided by your ISP. ![]() This is what recursive nameservers do every single time. Lastly it will ask this server for " and get 81.171.2.181. Now a lot of additional queries take place starting at the top again, because it needs to learn about either "nl", or "be", or "eu" - all not in the cache, either. It picks one of them at random and asks it for the nameservers for the "org" zone. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |