0
votes

During a Complete Resource Group deployment, the expectation is Resources will be deleted if they are not specified in the Template.

However in my case (deploying a RSG with a DNS Zone with CNAMEs), if the CNAMEs are specified via a copy/copyIndex iterator, the ones that are missing after the projection from the array parameter are not deleted.

I've got a basic template that should reproduce this issue.

  1. Add CNAME records to the parameters file.
  2. Deploy the Template (Complete) & verify the CNAMEs were created.
  3. Remove 1 or more CNAME records from the parameters file.
  4. Deploy the Template (Complete) & observe the removed CNAME Resources are not deleted.

I can't find any documentation that explains this behavioral caveat, so I'm not sure if this is a bug or expected behavior?


Edit / Follow-Up:

If I take a 'heavy-handed' approach of nuking the whole DNS Zone, then immediately re-deploying it with the new template, will this cause blips in DNS service, assuming there are no issues re-deploying and this operation takes place in under the TTL of the affected resources?

While this sounds reasonable, my gut tells me this will always be a race condition that cannot be guaranteed. ie: - If 'a client' TTL expires immediately after I nuke the Zone, the DNS lookup will fail until the redeployment occurs and the record takes effect in Azure DNS.

But this raises questions:

  • If I delete the Zone, does Azure DNS still cache for the TTL?
    Edit: The answer appears to be 'not really' based on content here:
    • Changes to existing DNS records can take a little longer, but should still be reflected on the Azure DNS name servers within 60 seconds

  • If I re-deploy the current version before nuking it, can I effectively reset that Azure DNS cache, if it exists?
    • Edit: Based on ^^^, this gives me <= (60 sec - TimeToRegisterInAzureDNS).
1

1 Answers

1
votes

This is because the child resources are not actually resources, even though they are authored that way in the template. The "mode" of deployment is handled at the platform layer by ARM and the only resource in the graph is the dnszone.

You might argue that the RP should then update the properties to remove the other cname (which would be independent of the deployment mode) from the dnszone resource... because if it doesn't the only recourse is to delete the entire record which may not be ideal. Different RPs handle this different ways in ARM (unfortunately)... if you have a strong opinion about the behavior, you can open a uservoice request...

That help?