Web & DNS

White-label DNS: nameservers and hosting under your own domain

DNS is usually invisible to customers — until a change goes wrong. For IT providers, a professionally operated DNS structure under their own identity is also a factor in brand consistency and trust.

Domains and DNS zones are among the most persistent parts of a customer environment. Web servers, mail platforms and applications may change — the domain and its delegation often remain in place for many years.

Even so, many IT providers rely on nameservers from a third-party host. Technically, that can work. In the customer experience, however, it creates a break: the proposal, support and consulting come from the IT partner, while WHOIS, nameservers or the management portal point to another brand.

Why DNS should be part of the IT provider’s brand

Own nameservers such as ns1.yourcompany.ch and ns2.yourcompany.ch create a consistent technical presence. They signal that the IT provider deliberately manages the domain infrastructure rather than simply passing on a generic end-customer account.

The benefit is not merely visual:

  • Customers receive consistent information in documentation and during provider changes.
  • The technical platform can change in the background without rebranding every customer delegation.
  • Support and responsibility remain clearly with the IT provider.
  • Web hosting, DNS and other services can be presented as the provider’s own portfolio.

How white-label nameservers are designed technically

The visible nameserver names are created under a domain of the IT provider. Behind them are the authoritative DNS services of the platform operator. Depending on the domain and registry, so-called glue records or host objects may need to be registered with the registrar, especially when the nameservers are within the same domain.

A typical setup looks like this:

  • ns1.yourcompany.ch
  • ns2.yourcompany.ch

It is important that nameservers do not merely have different names but are operated sensibly across separate systems or locations. Two names pointing to the same server create visual redundancy, not technical redundancy.

DNSSEC improves security but requires disciplined processes

DNSSEC signs DNS zones cryptographically. Resolvers can then verify that answers are authentic and have not been altered in transit. The chain of trust extends from the zone through the nameserver to the parent registry.

Operationally, this means:

  • Keys and signatures need to be managed correctly.
  • The DS record at the registrar must match the active signature.
  • During migrations, the chain of trust must not be broken accidentally.
  • Errors can make a domain unresolvable even though DNS responses are still being served.
Practical rule:

DNSSEC should not be treated as a simple switch. Activation, registrar data and any nameserver changes belong in a documented process.

Migrate DNS zones without unnecessary interruption

A safe migration starts before the actual nameserver change. A typical process is:

  1. Capture the existing zone completely and verify it against production services.
  2. Reduce TTL values in good time if a controlled cutover is planned.
  3. Create the zone on the new platform and verify it independently.
  4. Check special records such as SPF, DKIM, DMARC, Autodiscover and verification records.
  5. Change the nameservers at the registrar.
  6. Monitor both the old and new platforms during the transition.
  7. Update the DNSSEC delegation to match the migration strategy.

Especially for mail services, completeness matters more than speed. A missing MX or DKIM record can have greater consequences than a short delay in the cutover.

Permissions, approvals and traceability

DNS changes can affect websites, email, VPN and cloud services at the same time. Not every user should therefore have unrestricted change permissions.

A suitable operating model defines:

  • Who may create and delete zones
  • Who may change critical records
  • How changes are documented or approved
  • How accidental changes are rolled back
  • How credentials and two-factor authentication are handled

What a white-label DNS platform should provide

Beyond branding, technical criteria are decisive: authoritative nameservers at separate locations, DNSSEC support, backups or zone export, clear customer separation, traceable permissions and reachable technical support.

For small IT providers, it is also important that the platform works beyond a single customer. Standards for naming, delegation and documentation turn individual zones into an operable hosting offering.

Partnership

Offer cloud services under your own brand.

Discuss your use case directly with the people who operate the platform.