--- name: muumuu-domain-dns-record-change description: "Plan and carry out one DNS record change (create, update or delete) on a MuuMuu Domain domain the way a careful operator does: read the current records first, write down the before state, change one record at a time with explicit approval, then re-read and compare. Use when the user asks to add, change, point, repoint, remove or fix a DNS record, such as an A, CNAME, MX or TXT record, or to move a site, mail or verification setup to new values." --- # Change a DNS record on one domain A DNS change is live for everyone who resolves the name, and the old value may be cached for a long time. The job is to make exactly the change the user asked for, leave everything else as it was, and be able to show the before and after. Do not batch unrelated edits into one approval. This skill covers changes to records. It does not cover buying a domain or changing which nameservers a domain uses; those are separate jobs. ## 1. Pin down the domain and the exact change Confirm with the user, in one short message: - The domain (fully qualified name, e.g. `myapp.com`) and that it is the one in the account. - The record host (the subdomain, or the apex/root), the record type, and the exact new value. - For a delete, the exact record to remove. Never remove by type alone when several records of that type exist. If the user says "fix the mail", "point it to the new server" or similar, translate that into a list of specific record changes and show it back to them before reading anything. Ask about any value that looks wrong for its type (an A record that is not an IPv4 address, a CNAME at the apex, a second CNAME on a host that already has one). ## 2. Read the current state before any write Use `list-me-dns-records-by-fqdn` for the host, or `list-me-dns-records` for the whole domain if you need the context around it. Copy the current records into your notes exactly as returned: type, host, value, and any priority or TTL field. Then check: - **Is the target record there?** If you are updating, it must exist. If it does not, you are creating, and you should say so. - **Are there records that depend on it?** An MX change affects mail, a TXT change can break domain verification or SPF, and a CNAME on a host that other records point to changes those too. Name the risk in one line. - **Is there a conflicting record?** A CNAME cannot sit alongside other record types on the same host, so adding one can fail or force removals. - **Is the list complete?** If results are paged, read every page before deciding that a record is absent. A "not found" from a partial list is a common false alarm. If the target record already has the value the user wants, stop and report that nothing needs to change. ## 3. Write the plan and get approval per write Show the plan as a before-and-after table, one row per change: ``` # Action Host Type Before After 1 update www A 203.0.113.9 203.0.113.5 ``` Then say which tool will be used for each row (`create-me-dns-record`, `update-me-dns-record` or `delete-me-dns-record`) and ask for the user's explicit yes before running any of them. Each of these tools changes the live zone, so wait for the user's explicit yes before each call. Approval for row 1 does not cover row 2. If a change fails, stop, report it, and ask again before trying a different approach. Use the record identifier returned in step 2 for update and delete. Do not guess identifiers. ## 4. Apply one change at a time and check each result After each approved write, re-read the record with `list-me-dns-records-by-fqdn`. Confirm the new value and that nothing else on the host changed. If the result differs from what you wrote, report that and stop; do not retry blindly. Keep track of the order. When several changes depend on each other (a new TXT record must exist before a verification step, for example), do the dependency first and say so in the plan. ## 5. Explain propagation honestly A change in the account is not a change on the internet. Resolvers cache records for the old TTL, and the MuuMuu Domain documentation says a change can take up to 72 hours to take effect. Tell the user this, and say that until then some users will still see the old value. Recommend keeping the old target running during that window if the change moves a live service. ## Common patterns and traps - **Changing an A record on an apex domain that also has MX, TXT (SPF) or NS-related records:** only the A row changes. Re-read the others to confirm they were untouched. - **Moving a host to a new CNAME target while an A record still exists on it:** the CNAME will conflict. Remove the A record in its own approved step first, then add the CNAME. - **Deleting "the TXT record" when there are several (SPF, domain verification, DKIM):** delete only the one whose value matches what the user named. Show the value in the approval request. - **Changing an MX record:** priority is part of the record. Keep the existing priority unless the user asked for a new one, and check it in the re-read. - **Verification records that must stay:** a TXT record used to verify a third-party service may need to remain for the service to keep working. Ask before removing one. - **Typos in the host:** `www` and `www.myapp.com` may both be accepted as input. Compare against the names returned by the list, not against what the user typed. - **Mistaking the TTL for a propagation delay:** the TTL controls caching. A low TTL does not make the change instant. Do not promise speed. - **Silent scope growth:** the user asks for one record and you notice three others that look wrong. Report them as observations; do not change them without a separate approval. ## Output ``` Domain: Read at: