Ich umgehe das Problem mittlerweile mit Geräteprofilen. Einfach mit Apple Configurator ein wifi-Profil für alle relevanten Netzwerke für iPhones und iPads erstellen und dort hinterlegen.
Anhang anzeigen 10466
Kann es sein, dass selbst die Profile nichts (mehr) nützen?
Habe hier iOS 26.4.2, FritzBox 6591 Cable@FritzOS 8.21. iOS-Profil wie angegeben und bekomme dennoch ab und an die captive.apple.com-Seite zu sehen.
Allerdings macht hier nicht die Fritz das DNS, sondern ein PiHole 6.4.2.
PiHole explodiert förmlich, wenn man an einem iPhone das WLAN anschaltet. Aber nur zwei Anfragen werden geblockt:
_dns.resolver.arpa ; das hat irgendwas mit "DNS over HTTPS" zu tuen und könnte eine DNS-Auflösung an PiHole vorbei erlauben, daher wurde dies wohl in 2025 implementiert, dass dies geblockt wird.
Quelle
Die zweite geblockte Anfrage ist app-measurement.com (ist wohl ein Tracker, der in verschiedenen Apps drin steckt).
Interessant ist, dass trotz CaptiveBaypass = true das iPhone regelmässig Anfragen nach captive.apple.com (HTTPS, AAAA, A) versendete, die vom PiHole auch alle beantwortet wurden. Die Antworten kamen dabei nicht aus dem Cache, sondern aus einem Formward, waren also "ganz frisch". Allerdings dauerten sie mit >20ms etwas länger. Und die Antwort war keine IP, sondern ein CNAME. Mal ins Terminal:
Code:
nslookup captive.apple.com
Server: 192.168.178.235
Address: 192.168.178.235#53
Non-authoritative answer:
captive.apple.com canonical name = captive.g.aaplimg.com.
Name: captive.g.aaplimg.com
Address: 17.253.57.199
Name: captive.g.aaplimg.com
Address: 17.253.57.205
Und ja, es folgte dann noch eine Anfrage nach captive.g.aaplimg.com, allerdings nur nach dem HTTPS-Record. Einen solchen gibt es aber für diese Domain nicht
quelle, nur AAAA oder A. Also hat der PiHole mit NODATA geantwortet (aus einem 2min-Cache). iOS hat aber nach der HTTPS-Abfrage gleich aufgegeben und nicht, wie bei der vorherigen captive.apple.com noch die AAAA und A hinterhergeschoben.
Könnte hierin die Crux begraben sein?