Your domain is business infrastructure: choosing a provider you can trust
Security

Your domain is business infrastructure: choosing a provider you can trust

Worktechlabs editorial team 01 October 2026 7 min read
Your domain is business infrastructure: choosing a provider you can trust

Your company can have a well-built website, a patched application and a reliable cloud platform, yet still lose control of where customers arrive. If someone changes the domain's configuration without permission, visitors may reach a different server while your own application continues running normally. The domain account deserves the same attention as the systems that process your orders.

This article examines that business risk without attributing an incident to a particular supplier. An unexpected destination alone does not establish whether an attacker stole a password, compromised an API token, abused account recovery or changed something in the hosting platform. The useful purchasing question is broader: what evidence shows that a provider can protect, detect and recover changes to this critical asset?

Understand what you are actually buying

The registrar maintains your domain registration. The DNS provider publishes the records that direct services to their destinations. The hosting provider runs the website or application. One company may perform all three roles, or they may be distributed across suppliers. The NCSC's guidance on managing public domain names explains these responsibilities and their security implications.

For a hypothetical distributor, the same domain may support the public website, customer portal, email and integrations used by staff. A hosting backup cannot, by itself, reverse an unauthorised change at the registrar. Write down which supplier controls each layer and which account can change it. That simple map turns an unclear emergency into a set of responsibilities someone can act on.

Accreditation and certification answer different questions

For generic extensions such as .com, verify the underlying registrar in the ICANN accredited registrar list. A reseller can legitimately sell through an accredited registrar; ask who that registrar is and how escalation works. Country-code domains follow their registry's arrangements, so do not assume the same accreditation model applies everywhere.

ISO/IEC 27001 concerns an information security management system. When a supplier claims certification, request the current certificate, its issuer, validity and scope. Establish whether the service and operating entity you are contracting with fall within that scope. A badge on a landing page is a starting point for verification, not the completed review.

Neither accreditation nor certification promises that an incident cannot happen. Their value is evidence and accountability alongside practical controls. A serious evaluation should connect a supplier's claims to the actual account you will operate, the services included in your plan and the people available when something goes wrong.

Examine everyday access before discussing advanced features

Ask the supplier to demonstrate separate administrator accounts, strong multifactor authentication and the recovery process. Prefer phishing-resistant methods where supported. Establish how former staff lose access and how a second authorised person can act if the primary administrator is unavailable. A recovery route that bypasses all the normal checks can undermine an otherwise strong login.

Treat automation credentials separately. Find out whether tokens can be limited to a zone and task, when they expire and how they are revoked. An integration that renews a certificate rarely needs unrestricted access to every customer domain. The ICANN registration-account protection guide is a useful reference for assessing account control and recovery.

In the distributor example, marketing might need to manage campaign content but have no reason to change nameservers. Finance may handle renewal payments without editing DNS. Write down those differences before accepting a shared administrator login as the normal operating model.

Ask exactly what a domain lock protects

An ordinary transfer lock and a registry-level protection service are not interchangeable. The first commonly prevents transfers to another registrar; it should not be assumed to stop every DNS edit. Registry lock offerings can add verification for sensitive changes, but their availability and coverage depend on the extension and provider. Review the specific service rather than relying on its name.

Use the NCSC advisory on DNS hijacking to frame questions about additional protection. Ask which changes are blocked, who can request an unlock and how that request is authenticated. Then consider the operational consequence: if an urgent migration is needed at a weekend, who is available to complete the authorised process?

The right control balances resistance to unauthorised changes with a workable recovery path. An undocumented lock that only one absent employee understands can create its own continuity problem. Practise the procedure on an appropriate test domain before relying on it for the main brand.

DNSSEC is useful within a wider control system

DNSSEC adds cryptographic validation to DNS responses. It does not make a stolen administrator account harmless, and it is not a substitute for protecting the systems that publish authorised records. If a compromised control plane can change and legitimately sign the data, validation alone does not establish that the business approved the change.

Ask who manages signing, key changes and the relationship with the parent registry. A DNS migration must coordinate those settings; simply moving records and hoping validation follows can cause failures. Require a tested migration plan, including how the team detects validation errors and restores the agreed configuration.

For the business owner, the decision is practical: use controls that the operating team can maintain and explain. Buying a feature without assigning its operation leaves an important part of the protection unfinished.

Measure support by the emergency you might actually face

Before signing, describe a concrete scenario: the website resolves to an unfamiliar server and the usual administrator cannot log in. Ask which contact channel remains available, what evidence proves control of the domain and who can freeze changes. Request an incident reference and a written explanation of escalation responsibilities.

Distinguish a promise to acknowledge a ticket from a commitment to investigate or restore service. Check the support hours for your purchased plan, rather than those advertised for a different enterprise package. Store the necessary contact details and ownership records somewhere accessible if the affected domain's email stops working.

A small annual saving is difficult to assess without considering the work an interruption creates. In our distributor scenario, staff may need to reassure customers, check outstanding enquiries and confirm that payment instructions remain valid. These are operational costs even when no customer data was taken.

Monitor changes and rehearse a controlled recovery

Maintain an approved record of important DNS settings and arrange alerts for changes to critical destinations. Assign someone to investigate them. Monitoring that sends every alert to an unattended mailbox offers little operational benefit. Review renewal arrangements as well: expiry and malicious changes are different causes of disruption that need different responses.

If something unexpected happens, preserve the observed records, timing and available audit history before changing everything. Recover account control with the provider, revoke affected access and restore a verified configuration. Include web, mail and other relevant records in the review. Cache lifetimes mean different users may see the correction at different times; one successful browser check is not complete evidence of recovery.

Ask for a follow-up report distinguishing confirmed facts, likely causes and open questions. The country associated with a destination server does not identify the attacker. Base customer communications on established impact rather than guesses about who was responsible.

Turn supplier quality into an accountable business decision

Compare providers using the same short evidence sheet: registration arrangements, verified certification scope, account controls, available locks, change visibility, recovery procedures and support terms. Record any gap, the person accepting it and the action needed to close it. This is more useful than choosing the most impressive collection of security logos.

Worktechlabs can help map the dependencies between your domain, hosting, applications and integrations, and define a practical support and continuity plan. Our guide to disaster recovery rehearsals explains how to prove that business work can resume. A quality provider matters most when its controls and your own operating procedures work together.

Official sources and further reading

DomainsDNSSecurityBusiness continuity
Worktechlabs

Written by

Worktechlabs editorial team

About the team and our articles

Want to discuss this with the team?

We are happy to talk through how this applies to your own system.

Get in touch

Let's talk

What would you like to improve in your business?

Discuss your project 020 3883 2194

We use cookies

Necessary cookies keep the site working. With your permission we also use analytics cookies. Google receives basic measurement signals without analytics cookies before you accept or if you reject. You can change your cookie choice at any time. See our cookie policy.

Privacy settings

Cookie preferences

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.