research
Auditing who can change a public DNS record
A method for mapping every person, role, and token that can alter a public DNS record, and for testing whether the recorded change trail matches policy.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
A public DNS record can redirect customers, break email, or hand a domain to someone else. Most companies believe the change is controlled because the registrar account has a strong password, yet the real authority is spread across registrar roles, DNS host users, and API tokens. This audit maps every path that can change a record and tests whether the trail matches the policy. The output names the people and systems that could alter public traffic.
Question and scope
This audit asks who can change a public DNS record, through which path, and whether the recorded changes match the approved process. The unit is one path that grants change authority, and the population is every domain and subdomain the company uses for public services. The result describes that estate and that period, not the intentions of the domain owner. Freeze the domain list and the review date before collecting access data.
Include the registrar, the DNS hosting provider, and any service that manages records through an integration. Exclude internal-only zones unless they use the same authority path. Record the business service behind each domain so a finding can be ranked by impact. A domain used only for a redirect matters less than the one that carries customer login and email. Record the hosting provider's support contact as part of the escalation path.
Map the zones and registrars
List every public zone, the registrar that holds it, and the nameservers that answer for it. Confirm the registrar from a public lookup as well as from the account record, because a domain can be transferred without the team noticing. Record the expiry date and the auto-renew setting. A domain that expires is a change of control even when nobody intended it. Record the registry lock status where the registrar offers one.
Identify the DNS host separately from the registrar, since many companies use different providers for each. Note the account owner and the support route for both. Record any zone that is managed by a vendor or a marketing agency. A vendor-managed zone is still the company's public identity and should appear in the audit.
Identify every change path
For each provider, list the ways a record can be changed: the web console, an API token, a command-line tool, a deployment pipeline, or a support request. Include the paths that bypass the normal approval, such as a provider support agent acting on an email. Record the authentication method for each path. A path without multi-factor authentication is a finding even when only one person uses it. A support request that changes a record on an email is an approval path, not an exception.
Check for integrations that can write records, such as a load balancer, a content delivery network, or a certificate automation tool. Record the service account and the scope of its token. Note whether the token can change all zones or only one. Broad tokens are convenient and dangerous, so the scope belongs in the register.
Review role and credential holders
Export the users and roles from the registrar and the DNS host. Map each role to the actions it can perform, especially record creation, deletion, and nameserver changes. Identify every account with administrative rights and confirm it belongs to a current employee. Remove accounts that cannot be tied to a person, including generic logins and former vendor accounts. Check the role list for accounts that belong to a group rather than a person.
Record who holds the recovery email and phone number for each account. A recovery mailbox that a departed employee still controls is a path back into the domain. Confirm that the recovery contact is monitored and that multi-factor authentication protects it. The recovery path is often weaker than the primary login.
Test the change trail
Review the provider's audit log for the last ninety days and list every record change with the actor, the time, and the source address. Compare the changes with approved tickets or change records. Investigate any change that has no matching approval. A trail that cannot identify the actor is a control gap regardless of whether the change was benign.
Check whether logging is enabled for the DNS host and how long records are retained. Confirm that the log is stored somewhere other than the account being audited. Test whether an alert is sent for a nameserver change or a record deletion. A log nobody reads is useful only after an incident.
Classify the findings
Group the findings into excessive access, shared or orphaned credentials, missing multi-factor authentication, unmonitored change paths, and incomplete logging. Rank each group by the service it can affect and the difficulty of detecting a misuse. A single shared login that can change the customer login domain belongs at the top. A stale redirect zone with no active use can wait. Rank by the service behind the record, not by the number of users with access.
Record the evidence for each finding and the person who can fix it. Distinguish a policy exception from a control failure, because the remedies differ. An approved marketing agency with scoped access is an exception, while an unapproved API token with full zone access is a failure. The classification should make the next action obvious.
Estimate the exposure
Describe what an attacker could do with each finding, such as redirect the login page, intercept password reset email, or obtain a certificate for a subdomain. Avoid inventing a probability or a financial loss figure. Report the number of domains and users affected by the finding. That count is evidence, while a risk score is an opinion.
Check whether the affected domain has a certificate transparency record or a mail authentication policy that would limit misuse. Note the existing controls rather than assuming none exist. The estimate should help the owner rank the work, not replace the owner's judgment. State the limits of the review in the same section.
Report to the owner
Lead with the number of zones reviewed, the number of people and tokens with change authority, and the highest-impact gap. Show one example of an unapproved change or an orphaned account. Put the full access map in an appendix. The owner should see the decision before the detail. Use a table that names the domain, the path, and the missing control.
Ask for specific decisions such as removing an orphaned account, scoping an API token, or enabling multi-factor authentication for the registrar. Name the owner and the review date. If a vendor needs access, define the scope and the expiry. A decision that changes the access path is worth more than a longer report.
Limits and next use
The audit reflects the access visible from the provider accounts the company can open. It may miss a reseller account, a legacy provider, or a token held by a former contractor. It also cannot prove that a reviewed change was the only change made. State those limits so the result is read as a point-in-time map rather than a guarantee.
Repeat the review after any registrar or DNS host change and at least every six months. Compare the access map with the previous version and investigate every new path. If the same shared account keeps returning, the onboarding process for DNS access needs repair. The register is working when the paths are known before a change is needed.
Set the review cadence
Assign the DNS inventory to one owner and the access review to a second person where possible. Keep the domain list, the provider contacts, and the access map in one controlled document. Record the review date and the decisions beside the findings. A document that two people can find is more resilient than a personal notebook. Keep the access map in the same place as the domain renewal calendar.
Review the list whenever a domain is added, retired, or transferred. Confirm that the registrar and DNS host accounts still have a current recovery contact. Report the number of administrative accounts and open findings to the IT manager. The cadence should keep the estate small enough to reason about.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the recovery, software inventory, service desk, DNS, and endpoint protection controls discussed here. The GAO data reliability guidance supports the sampling and verification approach used in these methods. Apply your own policies, contracts, and system documentation when adapting the method.
Compare this study with the endpoint encryption coverage study and the public DNS change authority audit before combining them into one review cycle. If the measurement work is recurring and your technical owner can define the scope, review the service areas and contact ITVirtualAssistant to discuss a limited pilot.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the auditing who can change a public dns record data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to auditing who can change a public dns record, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Log window | 90 days | Study protocol |
| Finding groups | 5 | Study protocol |
| Review interval | 6 months | Study protocol |
Sources
- NIST SP 800-81-2, Secure Domain Name System Deployment GuideDNS deployment, operational roles, and change control guidance.
- NIST Cybersecurity Framework 2.0Asset, identity, and protective technology outcomes for public services.
- CISA Cross-Sector Cybersecurity Performance GoalsAccount and access management goals for administrative systems.
- NIST SP 800-53 Rev. 5Access enforcement, audit logging, and configuration change controls.
- GAO Assessing Data ReliabilityEvidence and verification checks for access records.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review