Домены
Domains is a service for owners of websites, online stores, applications, and internal systems that need dependable infrastructure without undocumented changes or dependence on one contractor. DitWork lets customers compare specialists by relevant experience, diagnostic quality, security planning, documentation, and post-change support. A useful estimate requires the current architecture and a measurable target, not a vague request to configure everything.
In the Domains category, customers can order domain registration in the customer account, transfer between registrars, A, AAAA, CNAME, MX, and TXT configuration, subdomains for websites, APIs, and email, SPF, DKIM, and DMARC setup, HTTPS and DNS validation and DNS-zone migration with minimal downtime. Separate the mandatory result, optional improvements, and ongoing support. A one-time migration, continuous monitoring, and round-the-clock incident response are different services with different responsibility, so they should be scoped and priced separately.
Tasks you can order
- domain registration in the customer account
- transfer between registrars
- A, AAAA, CNAME, MX, and TXT configuration
- subdomains for websites, APIs, and email
- SPF, DKIM, and DMARC setup
- HTTPS and DNS validation
- DNS-zone migration with minimal downtime
Deliverables by stage
| Stage | Deliverable | Verification |
|---|---|---|
| Audit | Current-state and risk map | Services, access, and dependencies are documented |
| Preparation | Backup and change plan | A verifiable rollback path exists |
| Implementation | Configured infrastructure | Critical scenarios work |
| Handover | Documentation and owner access | The result does not depend on the contractor account |
What to include in the brief
The brief should include exact domain name and intended use, current registrar and DNS provider, websites, mail systems, and external services, existing zone file or record export, required subdomains and traffic destinations, acceptable cutover window and owner contact and renewal rules. Add anonymized error examples, a service map, and an available owner contact for the cutover window. Never publish passwords, private keys, tokens, recovery codes, customer data, or closed configuration in the public task. Access should be provided only after choosing a specialist and limited to the work being performed.
- exact domain name and intended use
- current registrar and DNS provider
- websites, mail systems, and external services
- existing zone file or record export
- required subdomains and traffic destinations
- acceptable cutover window
- owner contact and renewal rules
What to check before work starts
Before changes begin, review who controls the registrar account, which nameservers serve the zone, whether records conflict or are obsolete, how email and sender authentication are configured, whether CDN, proxy, or load balancing is used, whether transfer lock and two-factor protection are enabled and when registration expires and who receives notices. Without an inventory, a specialist can fix one visible symptom while breaking a dependent service. The audit should distinguish infrastructure failure from an application bug, plan limitation, external API issue, or incorrect DNS record. When the cause is unknown, order diagnosis and a written report before paying for an undefined collection of actions.
- who controls the registrar account
- which nameservers serve the zone
- whether records conflict or are obsolete
- how email and sender authentication are configured
- whether CDN, proxy, or load balancing is used
- whether transfer lock and two-factor protection are enabled
- when registration expires and who receives notices
How the work is performed
A safe workflow includes inventory every DNS record, prepare the new zone and reduce cutover risk, create missing records, verify website, API, and email on test endpoints, change nameservers or individual records, observe propagation and service health and hand over a zone export and owner instructions. Every critical change needs a backup and a clear reversal method. Verification must cover more than the visual home page. Test real user journeys, background processes, notifications, logs, resource limits, and behavior after restart.
- inventory every DNS record
- prepare the new zone and reduce cutover risk
- create missing records
- verify website, API, and email on test endpoints
- change nameservers or individual records
- observe propagation and service health
- hand over a zone export and owner instructions
Technical and security requirements
Technical requirements should include separate records for production and testing, no conflicting A and CNAME records on one hostname, correct MX priorities, one coordinated SPF policy without unnecessary includes, DKIM keys for actual senders, DMARC introduced with a safe staged policy and DNSSEC only when the registrar and DNS provider chain is coordinated. Shared passwords, permanent root sessions, secrets in chat, and disabling protection for a quick launch create long-term risk. Permissions should match each role, while the project owner must retain an independent recovery path that does not require the former contractor.
- separate records for production and testing
- no conflicting A and CNAME records on one hostname
- correct MX priorities
- one coordinated SPF policy without unnecessary includes
- DKIM keys for actual senders
- DMARC introduced with a safe staged policy
- DNSSEC only when the registrar and DNS provider chain is coordinated
What the specialist should deliver
After completion, request owner access to the registrar and DNS, an export of the current DNS zone, a record inventory with purpose for each hostname, external services and verification TXT records, renewal and account-recovery instructions, change log and cutover date and monitoring recommendations for domain and certificate expiration. Documentation is not ceremonial. It makes the result repeatable so another specialist can find configuration, verify operation, identify dangerous actions, restore the system, and understand who owns each account. Configuration exports and instructions should be stored with customer-controlled recovery materials.
- owner access to the registrar and DNS
- an export of the current DNS zone
- a record inventory with purpose for each hostname
- external services and verification TXT records
- renewal and account-recovery instructions
- change log and cutover date
- monitoring recommendations for domain and certificate expiration
What affects the price
The price of Domains depends on number of domains and zones, subdomains and external services, complexity of the mail setup, need for a no-downtime migration, use of CDN, DNSSEC, and multiple environments, recovery of lost access and cutover urgency and post-change observation. Compare proposals against the same scope. A low estimate may omit diagnosis, backup, testing, related-service fixes, observation after cutover, and documentation.
- number of domains and zones
- subdomains and external services
- complexity of the mail setup
- need for a no-downtime migration
- use of CDN, DNSSEC, and multiple environments
- recovery of lost access
- cutover urgency and post-change observation
How to choose a specialist
When choosing a Domains specialist, ask for a description of a similar project without exposing another customer data. A reliable contractor asks about dependencies, access, backups, maintenance windows, monitoring, and acceptance criteria. They do not promise perfect security or zero downtime without reviewing the architecture, and they explain the remaining risks in advance.
How to accept the result
Before acceptance, verify the domain is registered to the customer, registrar and DNS access does not depend on the contractor, the site works on the main and required subdomains, mail records match actual senders, there are no accidental wildcard records or stale addresses, renewal is enabled or documented and the owner has saved the zone export and recovery codes. Judge the result through agreed scenarios and logs rather than a control-panel screenshot. Save check commands, change date, before-and-after values, contacts, and a repeatable response plan for a future incident.
- the domain is registered to the customer
- registrar and DNS access does not depend on the contractor
- the site works on the main and required subdomains
- mail records match actual senders
- there are no accidental wildcard records or stale addresses
- renewal is enabled or documented
- the owner has saved the zone export and recovery codes
Domain work should end with customer ownership, not dependence on a specialist personal account. Before changing nameservers, the complete zone must be inventoried, including analytics, service verification, email, and third-party platform records. A website may remain visible while email, APIs, payment verification, or certificate issuance silently fails. A technical specialist configures infrastructure but does not determine trademark rights or resolve domain disputes.
Access, responsibility, and service boundaries
In a Domains task, the customer is responsible for lawful data use, provider payments, ownership of domains and accounts, business-risk approval, and protection of shared secrets. The specialist is responsible for the agreed configuration scope, minimum permissions, change records, and warnings about discovered limitations. Application development, legal review, round-the-clock on-call service, and license purchases are included only when explicitly agreed.
How to post a task on DitWork
To order Domains on DitWork, post the current architecture, goal, service inventory, symptoms, deadline, and allowed change window. State whether the task is a one-time setup, migration, audit, or ongoing maintenance. Compare proposals by plan quality, access security, verification scope, documentation, and the ability to recover after a mistake.
