DNS access control for an MSP: technicians, AI agents and customers

You manage DNS for a few dozen customers. Technicians come and go, a customer wants to edit their own records, a script renews certificates, and someone has started to point an AI agent at the zones to clean up old entries. Six months later an auditor asks who can change the DNS of customer X, and the honest answer is "whoever has the registrar password". This article shows a setup where that question has a short, provable answer.

1 Why shared DNS access goes wrong

DNS is small but powerful: one changed A, MX or TXT record can redirect traffic, break mail or pass a domain-validation check. The usual shortcuts all remove accountability:

• One shared login for the provider account. Nobody can tell who made a change, and removing a person means changing a password everyone uses.
• One all-powerful API token pasted into scripts, CI variables and chat tools. It works from anywhere and on every zone, so a leak is a full compromise.
• Customers sent to the MSP by e-mail for every record change, because there is no safe way to let them do it themselves.

Access-control and change-management requirements, for example those in ISO/IEC 27001 and similar frameworks, ask for the opposite: named users, least privilege, a record of changes and a regular review of who has access.

2 An example setup

The numbers below are an illustration, not a recommendation for your size. Take a regional MSP that hosts DNS for about forty customer zones:

That is ten people with accounts, so the team size limit of your plan matters. Check the current limits on the pricing page before you plan the roles.

3 People: roles and zone scope

PrimeDNS roles are fixed, so they are easy to explain to an auditor:

DNS Manager, DNS Editor, DNS Viewer and Monitoring can be limited to a single zone. A technician or a customer administrator invited with a zone limit sees only that zone, and a request for another zone's records, DNSSEC settings, views or exports is refused. The invited person needs their own PrimeDNS account; after accepting the invitation they switch between their account and yours without a second password.

4 Automation: one key per job

An API key should be able to do exactly one job. PrimeDNS keys carry scopes such as dns:read and dns:write, and two restrictions you can add when the key is created:

• allowed_zones: the zones the key may touch. Records, DNSSEC, exports and the audit entries it can see are limited to them.
• allowed_ips: addresses or CIDR ranges the key may be used from. A request from anywhere else is answered with 403 IP_NOT_ALLOWED.

curl -X POST https://api.primedns.net/v1/account/api-keys \
  -H "Authorization: Bearer $SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ticket-bot customer-a",
    "scopes": ["dns:read", "dns:write"],
    "allowed_zones": ["customer-a.example"],
    "allowed_ips": ["203.0.113.10", "198.51.100.0/24"]
  }'

You do not need the API for this. In the panel, open API Keys, and in Create new API key fill in the optional Restrictions (addresses and zones) together with an expiry date and a daily spend limit. Edit on a key changes them later without replacing the key; narrowing a key needs nothing more, widening it asks for your 2FA code if you use 2FA.

Typical keys for the example setup:

Keys can be revoked at any time and can be given an expiry date. API key management itself needs a signed-in session, so an automation key cannot create or widen other keys.

5 Evidence: what the audit trail must show

Do not assume your current DNS panel can give you this. DNS editors that come as an add-on to web hosting, mail hosting or domain registration are built to edit a record, not to account for it, and in many of them there is no per-change history, no named users beyond the account login and no export. Check yours before the audit does: ask who changed a record last week and see whether the panel can answer.

An access review and a change-control audit ask the same practical questions: who changed this, from where, when, and what was it before. A useful DNS audit log answers all of them without anyone's memory:

• Who: the user name of the person, or the key used, so a technician and a script are told apart.
• What: zone, record name and type, and the old and new value.
• When and where from: a UTC timestamp and the client address.
• How: panel, API or dynamic DNS update.

PrimeDNS records record changes made one by one, in bulk, through a zone import, by certificate validation and by dynamic DNS updates (the last one only when the address actually changed). The log can be filtered by zone and action and exported as CSV for a reviewer or a SIEM. The full log is visible to the account owner and Admins; a key limited to zones sees only the entries of those zones. See the audit log guide.

Which control a given log or role satisfies is for your own assessment. For ISO/IEC 27001:2022 these topics are usually looked at under the controls for access control, access rights, privileged access, logging and change management in Annex A. A tool supplies the data; certification applies to your organisation and its processes, not to a product.

6 A quarterly access review in fifteen minutes

1. Open Team and list members. Remove everyone who has left or changed customers, and check that each remaining role is the smallest one that works.
2. List API keys. Revoke those that were last used long ago or whose owner is gone; check that each live key has the scopes, zones and addresses it needs.
3. Export the audit log for the quarter as CSV. Look for changes outside business hours, from unexpected addresses, or made by keys you did not expect.
4. Check that customer administrators still work for the customer and still need write access.
5. Keep the exported file and a note of what you removed. That is your evidence for the next audit.

7 How PrimeDNS handles this

Roles, zone scope, restricted keys and the audit log work from the panel and the API; team size and key counts depend on your plan. Start with the guides for teams and roles and the audit log, and keep the API reference at hand for key restrictions.