I did start an earlier topic relating to the Product Maintenance task failing to complete (the first symptom of this issue) but that topic has broadened into a discussion of other Norton issues so has lost focus. Also I now have a better understanding of the problem so a fresh topic is appropriate.
I know from an issue some years ago (also DNS related) that some Norton background tasks need to access the stats.norton.com server. Since May 10th my ISP's DNS server regularly fails to resolve stats.norton.com. The ISP has diagnosed an issue with refreshing its cached DNS records from the authoritative nameservers if those nameservers are accessed via IPv6.
Full details as follows:
- The Norton domain stats.norton.com is now hosted by Microsoft Azure cloud services. Access to the Azure hosts is managed by Azure’s Traffic Manager system. Therefore, the DNS record for stats.norton.com is now an alias (CNAME) that points to stats.norton.com.trafficmanager.net.
- Stats.norton.com.trafficmanager.net is a further CNAME that resolves to one of two end-points, either mue1-bit-ipv6-pip.eastus.cloudapp.azure.com, with an IP address of 52.188.144.172, or muw1-bit-ipv6-pip.westus.cloudapp.azure.com, with an IP address of 13.64.142.149.
- To ensure effective traffic management between the two endpoints, the CNAME record for stats.norton.com.trafficmanager.net has a short Time-to-Live (TTL), requiring downstream DNS servers to regularly refresh their cached copy of the record by reference to the trafficmanager.net nameservers.
Using the Powershell command Resolve-dnsname, this screenshot shows the correct resolution of stats.norton.com. The lookup is fully resolved to the westus Azure server and the authority section is that for Microsoft Azure host:
However, the DNS lookup often fails to fully resolve, resulting in this response. Stats.norton.com.trafficmanager.net is not resolved and the authority section is for trafficmanager.net, not the Azure endpoint.
The failure is due to the downstream DNS server failing to correctly refresh its stats.norton.com.trafficmanager.net record from a trafficmanager.net nameserver if accessed via IPv6. Trafficmanager.net publishes 4 nameservers, as per:
Resolving those names reveals that each nameserver has an IPv4 and an IPv6 address, as per this example of tm2.edgedns-tm.info:
Attempting to resolve stats.norton.com.trafficmanager.net via the IPv4 address works correctly but fails via the IPv6 address, as shown in this screenshot of attempts with the addresses for nameserver tm2.edgedns-tm.info:
Via IPv4, the correct Answer section is returned. Via IPv6, only the Authority section is returned. The same problem is seen with any of the four nameservers.
This incorrect response seems to be echoed if downstream DNS servers are accessed via IPv6 when querying stats.norton.com.trafficmanager.net. For example, if the Google public DNS is queried via IPv4 address 8.8.8.8 the correct response is returned but, if queried via IPv6 address 2001:4860:4860::8888 then, once again, only the Authority section is returned, as per:
Not all DNS providers are impacted by this issue, both Google DNS and Cloudflare DNS consistently resolve stats.norton.com OK if queried via their IPv4 addresses. Perhaps the explanation is that they always default to refreshing their cached records via IPv4 and ignore IPv6 nameserver addresses. My current workaround is to set my router to use Google DNS instead of my ISP DNS. Previously I bypassed DNS with a mapping for stats.norton.com in my Windows hosts file.
After feedback from my ISP, I have raised a support case with Norton support. The most recent update is that the case has now been escalated from "L2" to "L3", but the first level call agents were not able to give me any further details of the investigation. Ultimately, I would think Norton need to raise this with Microsoft as the issue would appear to be with the Azure Traffic Manager nameservers.
If a Norton forum moderator is monitoring this topic, I'd be grateful if they could pursue it with Norton support to obtain more details.