Time.android.com
Luz Tonks
What does the first option mean? It sure sounds like NTP, but there is no interface to pick a NTP server. Some wifi routers provide a NTP server address with their DHCP replies, but I don't think mine does, and in any case a mobile device can't rely on that, right?
Strangely on my phone, also Android 12, the Automatic Date & Time widget is just a binary switch, on or off (though the phone definitely has GPS). I think "on" here means the mobile network. But how come this interface differs between two devices with the same Android release?
By default Android uses to my knowledge the server time.android.com (see here) but different manufacturer may change this in their devices so the default NTP server in Samsung or other devices may be different.
I would love to a possibillity to rewrite a domain. In a professional term its NATing. I am missing the feature to change a domain to another. For example: If my mobile is requesting the page for time.android.com, I would like to redirect it to someOtherNTP.com. I want this to have a single source of time and to minimize differences between time.android.com, time.windows.com, time.apple.com etc... Because PiHole is a DNS-Server, its not needed to have a port based NATing. A redirection, based on my manual redirection-Entrys would be create.
The time provider stated "never configure fixed ip-addresses". So, do i need to tell him already an IP or is the ip-param optional? it is just an example... I think, I will cover much more with this in the future.
This is correct for external NTP sources, the IP might change, this is not under your control.
If you're using internal NTP sources (for example, you're pi is configured to be an NTP source), this becomes only a problem if your pi's IP address changes, which, under normal circumstances, it never does.
That is really bad, because I just have a FQDN of the other time-provider. And brings me back to my feature-request. I would like to have the possibillity to change a domain to another. In this case, rewrite time.android.com and time.windows.com to AnOtherPublicNTP.com.
someOtherNTP.com has to know that it will be addressed as time.android.com and respond in the proper way. This might be functional for something like NTP that doesn't care what FQDN it is but for any other service it will fail hard.
The common example is to try to redirect google.com to bing.com. Problem is that your browser is going to request and get back an IP for bing.com. bing.com has no idea who google.com is and will respond with an HTTP error. Even if you could find some way of correcting that error you'd then end up with TLS issues since impersonation is near impossible unless you start to mess with certificates.
Ive got the chance to play with a coporate compatible FireWall. And changing one FQDN to another (on ports based) was in the category of "NAT". I know. NATing is normally for changing many private IPs to one public IP...
Because every request would be for google.com and sent to the IP address of the server that handles bing.com. Your browser isn't going to change every URL from to or _asset to _asset. The webserver at is going to tell you that it has no idea who or what _asset is.
Since you mention that AdGuard has the feature, try it. Try to rewrite the domains and see what actually happens. Without a proxy to rewrite the html and URLs, it won't work. And with TLS involved you'd have to create a new TLS certificate and Certificate Authority that lets you impersonate domains. That means MITM and is a really dangerous thing to do.
Because every request would be for google.com and sent to the IP address of the server that handles bing.com . Your browser isn't going to change every URL from to or _asset to _asset . The webserver at is going to tell you that it has no idea who or what _asset is.
You're confusing TCP/IP OSI layers. Your step 8 doesn't exist. The browser doesn't send to an IP address. And again, even if it did, it's not going to take /index.html and convert tags from FQDN to FQDN. And even if it could it's not going to accept the certificate that signed the traffic as one FQDN to be valid for a completely different FQDN.
Again, dig shows it is a simple CNAME, but the redirection works, there is actually an IP in the reply. The NTP tools shows correct results, the pihole query log shows a query for pfsense.localdomain.
In conclusion, the AGH feature works for some protocols, like NTP, but is useless to redirect HTTPS trafic. Looks like the AGH CNAME implementation doesn't have the requirement, the redirect domain needs to be defined on the local system, dnsmasq does...
Ah, thanks for the tip. Did not know about this function. I checked all my Android apps and the setting is disabled. What I realized further is the access to connectivitycheck.gstatic.com and time.android.com after starting WiFi with activated Android Support.
I have made a try and unfortunately it does not work like that. I changed the settings in the container (also http and https server) and after a restart of the container they are still there, but still the same behavior.
4a15465005