Runbook: moving Huawei Cloud DNS and CDN to STACKIT

DNS records, assessed

Left: two of the four record sets of the demo, a CNAME and an MX record. Right: an excerpt of assessment.json for the CNAME, values exactly as the run wrote them.

resource "huaweicloud_dns_recordset" "www" {
  zone_id = "ff8080828e5d0b3e018e6a1b2c3d4e5f"
  name    = "www.example.com."
  type    = "CNAME"
  ttl     = 300
  records = ["example.com."]
}

resource "huaweicloud_dns_recordset" "mail" {
  zone_id = "ff8080828e5d0b3e018e6a1b2c3d4e5f"
  name    = "example.com."
  type    = "MX"
  ttl     = 3600
  records = ["10 mail.example.com."]
}

{
  "id": "huaweicloud_dns_recordset.www",
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT DNS"
    },
    "reason": "A DNS record set becomes a record in a STACKIT DNS zone. Line-based resolution of the source needs review."
  }
}

• Line resolution needs a look

  The run's reason says line-based resolution of the source needs review. On Huawei Cloud DNS a record set sits on a resolution line: the Default line answers every visitor, while region, ISP and custom lines return different answers by the visitor's location, carrier network or IP range. STACKIT import formats carry name, TTL, type, content and comment, with no field for a resolution line, so a record that answers differently per line is flattened or split by hand.

• The zone is not in the source

  The demo points at its zone by a literal ID. Nothing in the run creates the STACKIT zone, so step 2 below does.

• Five settings per record

  name, records, ttl, type and zone_id are listed for your team as settings left to you.

The records of the demo and how STACKIT DNS takes them

Record-type rules from the STACKIT DNS record types reference. The values and TTLs are those of the demo input; the run did not change any of them.

The CDN domain, assessed

The demo has one CDN domain with an HTTPS setting and an origin host, and one public-read bucket. The run maps the domain to a STACKIT CDN distribution.

resource "huaweicloud_cdn_domain" "static" {
  name         = "static.example.com"
  type         = "web"
  service_area = "outside_mainland_china"

  sources {
    origin      = "origin.example.com"
    origin_type = "domain"
    active      = 1
  }

  configs {
    https_settings {
      https_enabled = true
    }
  }
}

{
  "id": "huaweicloud_cdn_domain.static",
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT CDN"
    },
    "reason": "A CDN domain becomes a STACKIT CDN distribution. Cache rules and certificates are rewritten, and the origin moves with the workload."
  }
}

• Rewritten, not copied

  The run states that cache rules and certificates are rewritten, and the origin moves with the workload. Rebuild them as STACKIT distribution settings.

• A bucket is a data decision

  The OBS bucket is RECONFIGURE and is listed as DECISION_REQUIRED for data movement. Its acl, bucket name and storage class are listed as settings left to you; decide whether the assets stay public or sit behind the CDN.

• Everything in wave 1

  All six units have no dependency, so the run offers no order of its own. The order below is runbook practice.

The runbook: step, owner and check, rollback

Steps 1, 5 and 9 and the delegation change in step 7 are general practice. STACKIT specifics (import types, formats, skipDnsCheck, managed certificate, TTL advice, CNAME rollback) come from the STACKIT pages under sources. The run assigns the DNS records to a cutover package owned by the Network Architect, the CDN domain to a platform package, also owned by the Network Architect, and the bucket to a data package owned by the Storage Architect.

What the run says about the cutover

The cutover facts of this estate, verbatim from the run's migration plan. C1 to C3 report no evidence and C4 no open decision. That is a statement about what the scan found, not about what you need to do: the four records still need their values set by you.

### C1 · DNS record sets whose value transforms

No evidence: the draft re-binds the value of no DNS record set to an address it generates.

4 more DNS record unit(s) are in the source and the draft re-binds no value of them (no transformation evidence): `huaweicloud_dns_recordset.apex`, `huaweicloud_dns_recordset.mail`, `huaweicloud_dns_recordset.spf`, `huaweicloud_dns_recordset.www`. What their values become at cutover is not evidenced.

### C2 · Public address re-binding

No evidence: the draft re-binds no public address that a record names.

### C3 · Certificate and host switch

No evidence: the source declares no certificate unit, and the scan holds no fact about a certificate or host name switch.

### C4 · Open cutover decisions (cutover dimension of the workload readiness)

None: no unit reads a cutover decision or a missing endpoint binding.

Traps this runbook closes

• The origin firewall

  If the origin sits behind an allow list, STACKIT CDN edge addresses must be allowed, and they change as the network grows. STACKIT recommends syncing them automatically, for example with a daily job.

• Cookies

  Check whether cookies bypass the cache and whether response cookies must be stripped. STACKIT CDN has a flag for stripping Set-Cookie headers.

• Public projects only

  CDN distributions are only available in public STACKIT projects, and the CDN service is enabled once per project.

• Records outside Terraform

  Records created in the console never appear in the run. The inventory in step 1 is how you find them.

Questions about DNS and CDN cutover

Sources

• STACKIT Docs: DNS record types
• STACKIT Docs: import a zone into STACKIT DNS
• STACKIT Docs: CDN features and options
• STACKIT Docs: migrating and onboarding to CDN
• STACKIT Docs: create a CDN distribution
• Huawei Cloud DNS: Configuring region lines