DNS/nameserver issue when resolving stats.norton.com

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: 

  1. 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.
  2. 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.
  3. 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:

Screenshot 2024-07-05 191425.pngHowever, 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.

Screenshot mail2.pngThe 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:

Screenshot 2024-07-05 175858.pngResolving those names reveals that each nameserver has an IPv4 and an IPv6 address, as per this example of tm2.edgedns-tm.info:

Screenshot 2024-07-05 180445.pngAttempting 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:

Screenshot Mail5.pngVia 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:

Screenshot Mail6.pngNot 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.

Following on from my initial post, firstly apologies for the formatting errors in that post, with the text not properly separated from the screenshot images.  By the time the images were released from moderation, it was too late for me to edit the post to correct the format.

However, I now have further test results that confirm the issue of the trafficmanager.net nameservers not returning the correct response if queried via IPv6.   These tests were done using the NSLOOKUP command with the -debug switch.  Test results are shown in text form as the the responses are too lengthy to be captured in a screenshot.

1.   Look up stats.norton.com.trafficmanager.net from nameserver tm2.edgedns-tm.info via its IPv4 address 13.107.206.240:

PS C:\WINDOWS\system32> Nslookup -debug stats.norton.com.trafficmanager.net 13.107.206.240
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        240.206.107.13.in-addr.arpa, type = PTR, class = IN

------------
Server:  UnKnown
Address:  13.107.206.240

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net.home, type = A, class = IN

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net.home, type = AAAA, class = IN

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net, type = A, class = IN
    ANSWERS:
    ->  stats.norton.com.trafficmanager.net
        canonical name = muw1-bit-ipv6-pip.westus.cloudapp.azure.com
        ttl = 30 (30 secs)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net, type = AAAA, class = IN
    ANSWERS:
    ->  stats.norton.com.trafficmanager.net
        canonical name = muw1-bit-ipv6-pip.westus.cloudapp.azure.com
        ttl = 30 (30 secs)

------------
Name:    stats.norton.com.trafficmanager.net

In the final two parts of the response, both questions get the Answer record correctly resolving stats.norton.com.trafficmanager.net to the canonical name (CNAME) muw1-bit-ipv6-pip.westus.cloudapp.azure.com.

2.  Look up stats.norton.com.trafficmanager.net from nameserver tm2.edgedns-tm.info via its IPv6 address 2620:1ec:bda:f00::f0:

PS C:\WINDOWS\system32> Nslookup -debug stats.norton.com.trafficmanager.net 2620:1ec:bda:f00::f0
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        0.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.0.a.d.b.0.c.e.1.0.0.2.6.2.ip6.arpa, type = PTR, class = IN

------------
Server:  UnKnown
Address:  2620:1ec:bda:f00::f0

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net.home, type = A, class = IN

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = REFUSED
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net.home, type = AAAA, class = IN

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net, type = A, class = IN
    AUTHORITY RECORDS:
    ->  trafficmanager.net
        ttl = 30 (30 secs)
        primary name server = tm1.dns-tm.com
        responsible mail addr = hostmaster.trafficmanager.net
        serial  = 2003080800
        refresh = 900 (15 mins)
        retry   = 300 (5 mins)
        expire  = 2419200 (28 days)
        default TTL = 30 (30 secs)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        stats.norton.com.trafficmanager.net, type = AAAA, class = IN
    AUTHORITY RECORDS:
    ->  trafficmanager.net
        ttl = 30 (30 secs)
        primary name server = tm1.dns-tm.com
        responsible mail addr = hostmaster.trafficmanager.net
        serial  = 2003080800
        refresh = 900 (15 mins)
        retry   = 300 (5 mins)
        expire  = 2419200 (28 days)
        default TTL = 30 (30 secs)

------------
Name:    stats.norton.com.trafficmanager.net

In this response, the final two questions receive Authority records rather than Answer records, as confirmed by the record counts in the response headers.

Some research into the interaction between DNS resolvers and authoritative nameservers indicates that this form of response is appropriate when the nameserver does not have an Answer record to resolve the question, so supplies the Authority record instead so that the DNS resolver has a record to cache and set the Time-to-Live which determines the wait before the DNS resolver next needs to refresh its cache.

However, that is not true in this instance as nameserver tm2.edgedns-tm.info does have an Answer record as it is able to supply it if queried via IPv4.

This is a further indication that Azure Traffic Manager has an issue with IPv6 access to its nameservers.   As a customer of Azure cloud hosting, it would seem that Norton need to pursue this with Microsoft Azure support.