Baza de cunoștințe

Folosiți propriul cont Azure DNS pentru a gestiona DNS-ul domeniilor dumneavoastră

Creați un principal de serviciu Azure cu rolul DNS Zone Contributor pe grupul de resurse al zonelor dvs. și conectați-l, astfel încât DNS-ul domeniilor dvs. să fie administrat din propria dvs. subscripție Azure.

What connecting it does for you

Connecting your own Azure account lets a domain's DNS be served from your account instead of ours. You keep the zone, the bill and the vendor dashboard; we create and update the records your sites and mailboxes need, so you do not copy them by hand.

Before you start

An Azure subscription and a resource group that holds — or will hold — your DNS zones.

1. Create the key at Azure

Azure calls this a service principal. In the Microsoft Entra admin center open Entra ID → App registrations → New registration, give it a name and Register it. On the app's overview page copy the Application (client) ID and the Directory (tenant) ID. Then open Certificates & secrets → Client secrets → New client secret, choose a duration and Add it — copy the secret's value straight away, Azure shows it once.

In the Azure portal, open the resource group you want us to use, then Access control (IAM) → Add → Add role assignment. Choose the DNS Zone Contributor role, assign it to User, group, or service principal, search for the app by name, and Review + assign. Note the resource group's name and the Subscription ID it belongs to (search Subscriptions in the portal).

2. Connect it here

Open Integrations in your dashboard and choose Connect an account. Pick Your own DNS as the group and Azure DNS as the account, fill in Client ID, Client secret, Tenant ID, Subscription ID and Resource group, and press Connect account.

We test what you paste before anything is saved. A key that does not work is never stored, and the answer says what was wrong with it. A key that works is kept encrypted in our secrets vault — never in our database — and is never shown again, not even to you.

What happens next

  • On any domain, open its DNS tab and choose this account as where the domain's
  • DNS is served from. We create the zone there if it does not exist and write the records the domain's sites and mail need.

  • When something on our side changes what a record must say — you move a site, switch CDN or
  • add a mailbox — we update the record on your account.

  • To finish the move, your domain's nameservers must point at Azure. If the domain is
  • registered with us, or at a registrar you have connected, we set them for you; otherwise the domain's page shows the nameservers to set.

  • When you connect, we check that the key can list your zones, read records and change records.
  • The checklist beside the connection shows which of those we could confirm.

If it does not connect

Azure refused the service principal. Either the client secret has expired, or the app no longer has DNS Zone Contributor on the resource group. The messages look alike, so check the role assignment before creating a new secret.

A zone is missing. It lives in a different resource group. Assign the role on that group too, or connect it as a second account.

It says the key was rejected. Almost always one of three things: a space or a line break copied with it, a key that has expired, or a key that was revoked or regenerated after you copied it. Create a fresh one and paste it again.

It connects, but something later fails. The key authenticates but lacks a permission the action needs. Create a new key with the permissions listed above, then disconnect the old connection and connect the new key.

Disconnecting

Open Integrations, find the account and press Disconnect. That deletes the stored key at once. Anything that was using it stops at its next action, and the screens that depended on it say so rather than failing quietly.

Disconnecting does not undo what was already done — records, deployments or settings we changed on your account stay as they are. If you think the key itself may have leaked, also revoke it at the vendor; disconnecting removes our copy, not theirs.

Cele mai recente de pe blog

Ce am scris despre găzduire, SEO și rularea site-urilor la scară largă.

SEO și link building de la nivelul de găzduire: O perspectivă a operatorului pentru 2026

Cum influențează găzduirea indexarea și autoritatea linkurilor în 2026: menținerea paginilor indexate, evaluarea domeniilor vechi înainte de a construi pe ele, crearea de linkuri fără urme și o perspectivă sinceră despre ce poate și ce nu poate face infrastructura pentru SEO.

Citește postarea

Cum să faci ca WordPress să fie rapid și sigur: O listă de verificare pentru performanță și module

O listă de verificare practică pentru un WordPress rapid și sigur: cache la nivel de server, un cache de obiecte per site, puținele pluginuri care merită folosite, menținerea stivei la zi și paginile WooCommerce pe care nu trebuie să le pui niciodată în cache.

Citește postarea

Cum să alegi o găzduire web administrată în 2026: Ghidul cumpărătorului

Ce separă cu adevărat găzduirea administrată de calitate de un server ieftin cu un panou de control — migrări, copii de rezervă, izolare, caching real și scalare corectă — și cum să o evaluezi înainte de a te angaja.

Citește postarea

Citiți blogul

Încă blochezi?

Asistența este inclusă în fiecare plan, biroul este deschis 24 ore pe zi și ne puteți scrie în oricare dintre cele 58 limbi ale noastre — vă răspundem în limba dumneavoastră.

Contactați asistența tehnică Toate articolele