DNS Providers

When you connect a DNS provider to your SpinupWP account, SpinupWP can manage your sites’ DNS records for you. Instead of logging in to your DNS provider to add an A record every time you create a site or add a domain, SpinupWP creates the records automatically.

SpinupWP currently supports the following DNS providers:

• Cloudflare
• Amazon Route 53

What DNS Providers Do

Once a site is configured with a DNS provider, SpinupWP will:

• Create an A record pointing your domain to your server’s IP address when you create or clone a site.
• Keep records in sync as you add or remove additional domains or change the primary domain.
• Remove A records when you delete the site, if you choose to.
• Validate your SSL certificate via DNS instead of HTTP. SpinupWP uses your DNS provider’s API to add a temporary TXT record, which Let’s Encrypt checks to confirm you own the domain.
• Issue a wildcard certificate that covers your primary domain and its subdomains (e.g. turnipjuice.media and *.turnipjuice.media). A wildcard covers one level of subdomain, so blog.turnipjuice.media is covered but shop.blog.turnipjuice.media isn’t.

DNS validation also means your domain doesn’t have to point to your server before HTTPS can be enabled. It also isn’t affected by Cloudflare’s Always Use HTTPS setting, a common cause of failed HTTP validation.

Step 1: Create Credentials With Your DNS Provider

SpinupWP needs API credentials that can read your zones and edit DNS records. We recommend creating credentials dedicated to SpinupWP with only the permissions listed below.

SpinupWP uses the most specific zone each domain belongs to. If a subdomain has its own zone, such as a Route 53 hosted zone for dev.turnipjuice.media, records for dev.turnipjuice.media and anything beneath it go in that zone. Otherwise, they go in the root domain’s zone, e.g. turnipjuice.media. Route 53 private hosted zones are ignored.

Cloudflare

SpinupWP authenticates with Cloudflare using an API token.

1. Sign in to the Cloudflare dashboard and go to My Profile > API Tokens.
2. Click Create Token.
3. Find the Edit zone DNS template and click Use template.
4. Under Permissions, make sure the token has Zone > DNS > Edit.
5. Under Zone Resources, choose Include > All zones, or Include > Specific zone to limit the token to the domains you’ll host on SpinupWP. If you limit the token to specific zones, every domain you add to a site using this provider, including additional domains, must be in one of those zones.
6. Click Continue to summary, then Create Token.
7. Copy the token. Cloudflare only shows it once.

Alternatively, you can create an Account API token under Manage account > Account API tokens with the same Zone > DNS > Edit permission. Account API tokens belong to the Cloudflare account rather than a user, so they keep working if the person who created the token leaves the account. Creating one requires the Super Administrator role or API Token Provisioning permission.

Amazon Route 53

SpinupWP authenticates with Route 53 using an IAM user’s access key.

First, create a policy:

1. Sign in to the AWS Management Console and go to IAM > Policies.
2. Click Create policy and switch to the JSON editor.
3. Replace the contents with the following policy:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "route53:ListHostedZones",
           "route53:ListHostedZonesByName",
           "route53:GetChange"
         ],
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": [
           "route53:ListResourceRecordSets",
           "route53:ChangeResourceRecordSets"
         ],
         "Resource": "arn:aws:route53:::hostedzone/*"
       }
     ]
   }
   

   To restrict SpinupWP to specific hosted zones, replace hostedzone/* with one or more hosted zone ARNs, for example arn:aws:route53:::hostedzone/Z0123456789ABCDEFGHIJ. Include any subdomain zones your sites use.

1. Click Next, give the policy a name such as spinupwp-dns, and click Create policy.

Next, create a user and attach the policy:

1. Go to IAM > Users and click Create user.
2. Enter a name such as spinupwp-dns and click Next. The user doesn’t need console access.
3. Choose Attach policies directly, search for the policy you just created, select it, and click Next, then Create user.
4. Open the new user, go to the Security credentials tab, and click Create access key.
5. Choose Application running outside AWS, click Next, then Create access key.
6. Copy the Access key ID and Secret access key. AWS only shows the secret once.

Writing Your Own Policy

If you’d rather write your own policy, it needs all of the following permissions. Leaving any of them out will cause DNS record or certificate tasks to fail.

ListHostedZones and ListHostedZonesByName don’t support resource-level restrictions, so they must use . The hosted zone permissions can be limited to specific hosted zone ARNs, for example arn:aws:route53:::hostedzone/Z0123456789ABCDEFGHIJ, and GetChange can be limited to arn:aws:route53:::change/.

To limit SpinupWP to the record types it manages, you can add a ForAllValues:StringEquals condition on route53:ChangeResourceRecordSetsRecordTypes with the values A and TXT.

Step 2: Add the DNS Provider to SpinupWP

Only users with the Account Admin or Owner role can add, edit, or delete DNS providers.

1. In SpinupWP, go to Account Settings > DNS Providers.
2. Click Add DNS Provider.
3. Select the DNS Provider (Cloudflare or Amazon Route 53).
4. Enter a Name to help you recognize this provider later, e.g. “Hellfish Media Cloudflare”.
5. Enter your credentials:
   • Cloudflare: paste the API Token.
   • Amazon Route 53: paste the Access Key ID and Secret Access Key.
6. Click Add DNS Provider.

DNS providers are saved to your account and can be used by any site in your account. Once a provider has been added, any user who can create sites can select it.

Step 3: Create a Site With a DNS Provider

When creating a new site, you’ll find a Create DNS Record option on the first step. This option is shown once your account has a DNS provider, or if your role allows you to add one. If you don’t see it, ask an Account Admin or the account Owner to add a DNS provider.

1. Enter your site’s domain.
2. Check Create DNS Record.
3. Select a DNS Provider from the dropdown.
4. Continue through the rest of the wizard as usual.

SpinupWP will create an A record for your domain pointing to the server’s IP address, then enable HTTPS automatically with a DNS-validated wildcard certificate. Since HTTPS is enabled automatically, SpinupWP skips creating a temporary subdomain. You can enable it later from your site’s Domains page if needed.

If an A record already exists for the domain, SpinupWP will replace it so that it points to the new server, and the site’s event log notes what it pointed to before. On Route 53, this includes alias records (for example, a domain pointing to CloudFront). If the domain has several A records, such as in a round-robin setup, they’re replaced with a single record. Double-check that you aren’t pointing a live site’s domain at a new server before it’s ready.

SpinupWP only manages A records. AAAA records are left as they are, so if the domain has one pointing elsewhere, visitors using IPv6 will still reach the old address. If the domain has a CNAME record, SpinupWP can’t add the A record, so remove the CNAME first.

Records created on Cloudflare are DNS only (not proxied). If you want to use Cloudflare’s proxy, you can turn it on in the Cloudflare dashboard once the site is up. When SpinupWP replaces an existing Cloudflare record, it only changes the IP address, so the record keeps its existing proxy setting.

What If I Don’t Use a DNS Provider?

You can still create sites without a DNS provider. In that case:

• If your domain already points to the server, SpinupWP detects this and enables HTTPS automatically using HTTP validation.
• If it doesn’t, the site is set up with a temporary SpinupWP subdomain and you can enable HTTPS once you’ve updated your DNS.

If Something Goes Wrong

If SpinupWP can’t create the DNS record, for example because the credentials are invalid or the token doesn’t have access to the domain’s zone, the site is still created, but the DNS step will fail. The alert shown once the site is ready will tell you whether the DNS record, the SSL certificate, or both need attention, and includes a Retry button you can use once you’ve fixed the problem.

Enabling HTTPS With DNS Validation

You can switch an existing site to DNS validation from the site’s HTTPS tab:

1. Choose SpinupWP will issue and manage a free certificate and set the Domain Validation Method to DNS.
2. Select a DNS Provider.
3. Save your changes.

SpinupWP will issue a certificate covering your primary domain, a wildcard for its subdomains, and each of your additional domains. Certbot handles the TXT records needed for validation, creating them through your DNS provider’s API and removing them afterwards. Renewals happen automatically the same way.

Let’s Encrypt validates every domain on the certificate, so the primary domain and all additional domains must be in zones your DNS provider can access. If any of them can’t be validated, the certificate isn’t issued and the site keeps its previous HTTPS settings.

Attaching a DNS provider here also turns on automatic A record management for the site going forward. SpinupWP doesn’t create A records for the site’s existing domains at this point. Records are only created or removed when you change the site’s domains later.

Switching a site back to HTTP validation or to a custom certificate removes its DNS provider, so SpinupWP will stop managing DNS records for it. HTTP validation doesn’t support wildcard domains, so you’ll need to remove any wildcard domains from the site before you can switch to it.

Managing Domains

When a site uses a DNS provider, saving changes on the site’s Domains tab also updates your DNS:

• An A record is created for each domain you add. As with site creation, an existing A record for that domain is replaced.
• The A record is deleted for each domain you remove, if it points to the site’s server.
• When you change the primary domain, an A record is created for the new domain and the old domain’s record is removed.

Changes that don’t add, remove, or rename a domain, such as editing a domain redirect, don’t touch your DNS.

Every domain on the site must be in a zone your DNS provider can access. Adding a direct subdomain of the primary domain, such as blog.turnipjuice.media, doesn’t need a new certificate because the wildcard already covers it. Adding any other domain, such as anotherdomain.com or blog.anotherdomain.com, will generate a new certificate.

Wildcard Domains

Sites that use DNS validation can also have wildcard additional domains, such as .anotherdomain.com. The wildcard is added to the site’s certificate, and Nginx serves the site for any subdomain that matches it. Adding .turnipjuice.media when turnipjuice.media is the primary domain doesn’t need a new certificate, since it’s already covered.

SpinupWP doesn’t create A records for wildcard domains, so add a wildcard A record (e.g. *.anotherdomain.com) at your DNS provider if you need one.

Deleting a Site

When you delete a site that uses a DNS provider, the delete modal includes a DNS A records checkbox. Leave it checked to remove the A records for the site’s primary and additional domains.

SpinupWP only removes records that point to that site’s server. If a domain also has an A record pointing somewhere else, that record is left untouched.

The same option is available when deleting several sites at once from the sites list: check Also delete each site’s DNS A records.

Cloning and Moving Sites

When cloning a site, the clone doesn’t inherit the original site’s DNS provider. The clone wizard has its own Create DNS Record option, so you choose whether and how DNS is managed for the new site. This avoids accidentally creating or removing records in the original site’s zone.

When moving a site, the moved site starts without a DNS provider. This gives you a chance to test the site on the new server before switching DNS over.

Editing or Deleting a DNS Provider

You can manage your DNS providers under Account Settings > DNS Providers. The Used By column shows how many sites use each provider.

To update credentials, for example after rotating an API token, click the edit icon next to the provider. Leave the secret blank to keep the current value. The service type can’t be changed once a provider is created.

Deleting a DNS provider does not delete any DNS records at your provider. Sites that used it will no longer be able to manage DNS records automatically or use DNS validation for their SSL certificates.

Certificate renewals for those sites will fall back to HTTP validation, so their domains must point to the server, and the renewed certificate will no longer include the wildcard. Sites with wildcard domains can’t be renewed this way, and their renewals will fail. Before deleting a DNS provider, attach a different provider to those sites, or remove any wildcard domains and switch them to HTTP validation.