Fusion 360 not syncing – possible DNSSEC issue (api.aps.usa.autodesk.com)

[motte-adf3]

Hi,

Fusion 360 currently does not sync files properly for me.

After some troubleshooting, I suspect a DNS/DNSSEC-related issue with api.aps.usa.autodesk.com.

Observations:

• Fusion 360 sync fails

• Local DNS resolver (Pi-hole + Unbound with DNSSEC) shows errors like:

  • DNSSEC indeterminate

  • BOGUS / SERVFAIL on some queries

• DNSViz reports DNSSEC issues for this domain https://dnsviz.net/d/api.aps.usa.autodesk.com/dnssec/

Question:

Is anyone else seeing sync issues with Fusion 360, possibly related to DNSSEC validation or Autodesk API endpoints?

Thanks.

[RajkumarIlanchelian]

@motte-adf3 On screen/in product what are the errors you are seeing? Any images you can post can help. 

[motte-adf3]

Hi,

Here are the screenshots. When I temporarily disable DNSSEC, Fusion immediately switches back to online mode.

[RajkumarIlanchelian]

@motte-adf3 Could Fusion be added to the allow list? 

[motte-adf3]

It is not blocked. It is the DNSSEC validation that fail.

[motte-adf3]

It can also be seen here that the issue is related to DNSSEC: https://dnssec-debugger.verisignlabs.com/api.aps.usa.autodesk.com

[Jordi.hutjens]

This is still happening. In order for Fusion to work currently one has to disable DNSSEC or else Fusion won't come online.

[mshek85]

Can confirm that I have the same problem with connectivity related to DNSSEC. 

Issue: Fusion 360 fails to connect / goes offline

Root cause: DNSSEC validation failure

Domain:
api.aps.usa.autodesk.com

Observed behavior:
- DNSSEC status: BOGUS
- Resolver: OpenDNS (208.67.222.222)
- Pi-hole logs show DNSSEC indeterminate
- Disabling DNSSEC resolves the issue immediately

Impact:
- Fusion 360 cannot reach backend APIs
- Appears offline / fails to start

Notes:
- Issue reproduces consistently with DNSSEC-enabled resolvers
- Works with DNSSEC disabled or different resolvers (e.g. Cloudflare)

[le.bryan.065]

I have the same issue with the most recent update to F360.

Running Pihole with DNSSEC enabled and get a BOGUS response on the same domain api.aps.usa.autodesk.

Currently workaround is to (reluctantly) disable DNSSEC or use an alternate DNS server when using F360...

[imelman2]

I am very thankful to have found this thread. I banged my head with tech support chat for a couple of days over this. Today I disabled DNSSEC on my asuswrt router and it is working. I hope Autodesk figures this out soon so I can renable DNSSEC!

[w00h.accounts]

I can confirm the issue still persists 10 days in.

Easily reproducible by enabling/disabling DNSSEC for the network, as others have correctly stated.

[matt7V7S2]

For those with a Pi-hole, you can also leave DNSSEC enabled, and just add Local DNS records for api.aps.autodesk.com (and api.aps.usa.autodesk.com ... not sure if this is just for folks in the US) to 34.8.107.155.  I haven't had it fail since I've done that, but if they switch up or retire that IP, it'll start failing again.

[daniel_vetterWSL9Y]

I experienced the same issue and was able to resolve it.

In my setup, Pi-hole FTL was configured with DNSSEC enabled while Unbound was also performing DNSSEC validation. Disabling DNSSEC in FTL while keeping DNSSEC enabled in Unbound resolved the problem immediately.

DNS resolution for api.aps.usa.autodesk.com then worked correctly and Fusion started working again.

Local DNS overrides are, in my opinion, not a good long-term workaround because the IP addresses behind Autodesk's infrastructure may change over time.

Direct queries to Unbound returned NOERROR, including DNSSEC-enabled queries, while queries through Pi-hole FTL returned SERVFAIL with DNSSEC Indeterminate. This suggests that the issue may be related to FTL's DNSSEC validation rather than Unbound itself.

Problematic result via Pi-hole FTL:

> dig api.aps.usa.autodesk.com

Expected failure:

> status: SERVFAIL

> EDE: 5 (DNSSEC Indeterminate)

Direct query against Unbound:

> dig @127.0.0.1 -p 5335 +dnssec api.aps.usa.autodesk.com

Expected result:

> status: NOERROR

Verify that Unbound is still performing DNSSEC validation:

> dig @127.0.0.1 -p 5335 dnssec-failed.org

Expected result:

> status: SERVFAIL

Workaround:

> pihole-FTL --config dns.dnssec false

> systemctl restart pihole-FTL

Verify:

> pihole-FTL --config dns.dnssec

Expected result:

> false

In my setup, DNSSEC validation remains active in Unbound, so disabling DNSSEC in Pi-hole FTL does not appear to reduce DNSSEC protection. It merely removes the second validation layer performed by FTL.

[w00h.accounts]

So what I'm getting is that you didn't disable DNSSEC in unbound for api.aps.usa.autodesk.com but just made unbound your preferred route of DNSSEC requests (which returned a valid result then), right? 
I'm no expert on networking by far, so please educate me if I'm wrong, but how would the results at https://dnssec-debugger.verisignlabs.com/api.aps.usa.autodesk.com   in any way align with your theory that Pi-Hole's FTL is the culprit? My first guess would be that your Unbound still responds with a valid response but it does so because it has it cached, not because it's actually valid anymore. Have you tried flushing the Unbound cache on the affected domains and then re-querying it?

[daniel_vetterWSL9Y]

That's a fair point. The Verisign DNSSEC debugger certainly suggests that something about the Autodesk DNS setup is not entirely clean.

However, after flushing both Unbound and FTL caches multiple times, Unbound still returned NOERROR for api.aps.usa.autodesk.com while continuing to return SERVFAIL for dnssec-failed.org. This suggests that Unbound still considered the Autodesk response valid after DNSSEC validation.

Therefore I don't think my observations are sufficient to conclude whether the root cause is an Autodesk DNSSEC issue, a Pi-hole FTL DNSSEC issue, or an interoperability issue between the two. I can only say that disabling DNSSEC in FTL while keeping DNSSEC enabled in Unbound resolved the problem in my setup.

[dominik_zarczynski]

Please try out the first solution from this article: Autodesk Fusion is stuck in offline or maintenance mode
I mean: Reset or Renew or Reconfigure DNS

[daniel_vetterWSL9Y]

Thank you for the suggestion.

However, I do not think it is relevant to the issue discussed in this thread. The problem being discussed here occurs in a Pi-hole + Unbound environment and specifically concerns DNSSEC validation for api.aps.usa.autodesk.com.

The article's recommendation to change or override the DNS servers on the Windows client may be useful as a troubleshooting step, but it effectively bypasses the Pi-hole/Unbound setup that is at the core of this discussion. If the solution is to point the client directly to a public resolver, then the actual DNSSEC issue within the local resolver chain remains unresolved.

In other words, changing the DNS servers on the client may avoid the problem, but it does not explain or address the underlying behaviour that several users in this thread are observing.

[motte-adf3]

Hey Fusion team, couldn’t you just properly validate DNSSEC for api.aps.usa.autodesk.com as well and the issue would be solved, right?

[imelman2]

IDK I suspect @daniel_vetterWSL9Y is on to something regarding an interoperability issue. For example, using the fusion network test, with DNSSEC enabled (on my asuswrt router with Diversion script), api.aps.autodesk.com fails. Everything else checks out OK. Turning DNSSEC off then everything works. Now, if you lookup on verisign some of those URL's that worked with DNSSEC enabled, they show up with pretty much the same "red X's" as the api.aps url. For example signin.autodesk.com:

https://dnssec-debugger.verisignlabs.com/signin.autodesk.com

I'm not by any means a networking expert, but basic logical deduction tells me the "unclean" status of the api.aps url on verisign is not 100% the smoking gun here. It may well be related, but if it was the absolute cause then the other links probably would have also failed the networking test. Perhaps this should also be mentioned to the maintainer's of the 'ad blocking' scripts we are all using as well?

[bentwookie]

With the caveat that I'm no DNS expert, much less a DNSSEC expert, I spent some time trying to understand why Fusion would go on and off line.

I had Claude write up some scripts to delv a few Autodesk endpoints, both with DNSSEC validation and without. For a stretch, both would return fine, but then storms of DNSSEC failures would occur for a few minutes while the non-validated calls kept on trucking. During these times Fusion would report an outage. Then it'd all return to normal for a while.

While tsharking the forward communication from my network's bind I saw SERVFAIL's for the DS record queries from 8.8.8.8 that aligned with outage times in Fusion. The other records from 8.8.8.8 came down fine.

Claude had a lot to say about the overall setup it saw under autodesk.com. I don't have the experience to say if it's right or wrong. It found it odd that aps.usa.autodesk.com lives as an unsigned island under the signed autodesk.com (which other have noticed). It felt that would mean checking the parent's chain to prove the child was specifically unsigned. It thought the TTLs for many of the records involved could lead to an awful lot of DS record fetching and if that went sideways some percentage of the time, we had more opportunities for failure. 

Anywhoo, I took 8.8.8.8 out of my forwards list and I haven't seen an outage since. 1.1.1.1 remains and seems fine. 

Again, my understanding of DNS is not unlike a caveman's understanding of rain. If put my chicken bones on the stone slab and if I say the right words, the crops grow. If they don't, it's demons. 

My DNS crops are growing strangely and I suspect demons.