IPv6 BGP Routing Issue - au.download.windowsupdate.com routed via AS6453 (Tata/Qwilt) instead of Akamai

Hello Comcast Network Team,

I am a residential Xfinity customer in the Atlanta, GA area (Chamblee/Stone Mountain area based on tracert hops) experiencing a persistent IPv6 routing issue that is causing Windows Update downloads to fail.

The Problem:
When resolving au.download.windowsupdate.com over IPv6 using Comcast's DNS servers (2001:558:feed::1 / 2001:558:feed::2), the hostname resolves to a Qwilt IPv6 address (2607:1640:75::153) and routes through AS6453 (Tata Communications), resulting in a highly suboptimal 21-hop path: Atlanta → Miami → Dallas → Ashburn, with timeouts at hops 19 and 20.

IPv6 Tracert (BAD - via Comcast DNS):
Destination: edge.ds-c7110-microsoft.global.dns.qwilted-cds.cqloud.com [2607:1640:75::153]
21 hops - routes Atlanta → Miami → Dallas → Ashburn
Timeouts at hops 19 and 20
Result: Zero bytes downloaded after 4+ hours and 121 connection attempts

IPv4 Tracert (GOOD - via Akamai):
Destination: a767.dspw65.akamai.net [23.218.145.111]
16 hops - routes directly through Akamai's Atlanta infrastructure (atl04)
Clean path, consistent ~13ms latency
Result: Downloads work correctly

Workaround Applied:
Switching IPv6 DNS to Google's servers (2001:4860:4860::8888) resolves the hostname to Akamai's IPv6 range instead of Qwilt, and the routing immediately improves to 13 clean hops.

Root Cause:
Comcast's IPv6 DNS servers appear to be returning Qwilt IPv6 addresses for Microsoft's CDN hostnames, while the actual BGP routing path from Comcast Atlanta to Qwilt's infrastructure is extremely poor - routing through Miami and Dallas before reaching a server that should be reachable locally in Atlanta.

Request:
Please investigate the BGP routing between AS7922 (Comcast) and AS6453 (Tata/Qwilt) from the Atlanta region, and review whether Comcast's DNS servers should be returning Qwilt IPv6 addresses for au.download.windowsupdate.com given the poor routing path.

Thank you for looking into this.