Remove dangling Episerver/Optimizely DXP CNAMEs under info.altinn.no

[bengtfredh]

Summary

Four CNAME records under info.altinn.no still point into the Optimizely/Episerver DXP namespace. All four targets are NXDOMAIN — they are leftovers from the migration away from Episerver DXP.

cms12.info.altinn.no.  IN CNAME  cms12.info.altinn.no.dxcloud.episerver.net.   → NXDOMAIN
inte.info.altinn.no.   IN CNAME  inte.info.altinn.no.dxcloud.episerver.net.    → NXDOMAIN
prep.info.altinn.no.   IN CNAME  prep.info.altinn.no.dxcloud.episerver.net.    → NXDOMAIN
prod.info.altinn.no.   IN CNAME  prod.info.altinn.no.dxcloud.episerver.net.    → NXDOMAIN

The live site has moved: info.altinn.no → info.altinn.info (Cloudflare), and info.tt02.altinn.no → info.tt02.altinn.info. Both resolve normally. Nothing appears to depend on the four records above.

Risk

This is a dangling CNAME pointing into a third-party SaaS namespace — the same class of exposure as #3907, but the takeover mechanism is different. Instead of racing for a released cloud IP, an attacker would need to get Optimizely to provision the exact hostname <name>.info.altinn.no.dxcloud.episerver.net under their own DXP tenant. Whether that is possible depends entirely on Optimizely's hostname allocation policy, which I cannot verify from outside.

What I can confirm:

• dxcloud.episerver.net exists and is live; only the four specific hostnames are gone.
• The namespace is not wildcarded (a random probe returns NXDOMAIN), so these are individually provisioned names rather than catch-all.

So: unproven, not zero. Some SaaS platforms allow a customer to claim an arbitrary hostname under their subdomain namespace without proving control of the parent domain, which is exactly what makes this pattern exploitable. Confidence here is materially lower than in #3907, where the takeover was already realised and observed.

Regardless of takeover feasibility, these are dead records for a decommissioned platform and should be removed on hygiene grounds alone.

Actions

• Confirm with the info.altinn.no owners that the Episerver DXP migration is complete and nothing depends on these four hostnames
• Delete the four CNAME records from the altinn.no Cloudflare zone
• If Optimizely DXP is still used anywhere, ask them whether hostnames under dxcloud.episerver.net can be claimed by another tenant — that answer determines whether this was a live exposure or only untidy
• Check other Digdir-managed zones for the same pattern

Context

Found while sweeping all 44 CNAME records in the altinn.no zone after the A/AAAA cleanup in #3907. Two other CNAME groups that looked broken were verified healthy and are not issues: the _acme-challenge.* → *.acme.altinn.cloud delegations (NXDOMAIN at rest is the correct behaviour for DNS-01) and the Azure Communication Services DKIM chain.