dnsimple / dnsimple-services Goto Github PK

Services can now be categorized. I am proposing the following categories to be documented and applied to existing services:

• Blogging (tumblr, ...)
• Email (mailgun, ...)
• Hosting (shopify, ...)
• Infrastructure (cloudflare, ....)
• Marketing (kickoff labs, ...)
• Support (tenderapp, ...)

Anything you'd like to add/remove?

New logo here: https://www.atmail.com/

Update google branding for google apps

See http://www.jimdo.com/

See https://help.format.com/en/articles/2645459-connecting-a-custom-domain, the user needs to enter a value for mysite when creating the CNAME with the value mysite.format.com. Their documentation also point to the use of a URL to redirect the naked domain to the "www" subdomain.

https://divshot.com/

These logos need to be refreshed:

• Jimdo #112
• Atmail #112
• Fastly #112
• Github pages #113
• Divio #113
• Launchrock #113
• Weebly #117
• Kickoff labs #117
• Heroku #114
• Amazon web services #114
• Cloudflare #116
• Gigalixir #117
• Fastmail #116
• Mailgun #116
• Rackspace #118
• Supadupa #118
• Tumblr #118

It looks like Google apps has changed a bit since we added the service configuration.

Specifically:

• docs is no longer supported

  

• sites is no longer supported, unless you enable the feature

  

• jabber is not even mentioned anymore.

I suggest to remove jabber, docs and sites. Any objection @aetrion/dnsimple ?

The Squarespace configuration needs to be updated based on https://support.squarespace.com/hc/en-us/articles/205812378.

The changes are:

• Allow the user to enter a verification code. Create a CNAME record with this code pointing to verify.squarespace.com
• Update the www record to point to ext-cust.squarespace.com
• Four new A records on the root domain pointing to the following IP addresses:

198.185.159.144
198.185.159.145
198.49.23.144
198.49.23.145

I quickly checked if we could use an ALIAS record instead of the 4 IP addresses, but couldn't find a clear answer.

Based on http://kb.weebly.com/domain-registrar.html, update the records for this configuration

A customer contacted us alerting of a change in MX records for the Google Suite.

We currently have these:

• aspmx.l.google.com
• alt1.aspmx.l.google.com
• alt2.aspmx.l.google.com
• alt3.aspmx.l.google.com
• alt4.aspmx.l.google.com

Note that this list is not incorrect, but if an outage occurs on the aspmx.l.google.com cluster, email would stop working. We should consider adding xxx.googlemail.com. as well.

According to https://university.webflow.com/article/connecting-a-custom-domain#update-the-dns the user needs to provide values from Webflow for 2 A records and 1 CNAME record. This no longer matches the configuration of our one-click service.

It would be nice to have conditional records in the config.json. This way there is no need for almost duplicate services, like the two for Droplr in PR #5.

If a certain field is filled then use specific records, else use other specific records (domain/subdomain services). Records without a condition are always included.

"records": [
  {
    "condition": {"subdomain": "not empty"},
    "name": "{{subdomain}}",
    ...
  },
  {
    "condition": {"subdomain": "empty"},
    "name": "",
    ...
  },
  {
    "name": "",
    "type": "TXT",
    "content": "always used"
  }
]

(sorry for the close/open..buttons..)

Hello DNSimple -

I was looking to integrating these service definitions into our (GPL) project and was wondering if there was a license I could use to determine whether this is appropriate.

Thank you,

--reese

• Run through JSON lint
• Verify required files are present

Just as an example: http://blog.stackoverflow.com/2009/01/using-your-own-url-as-your-openid/

I realize that's just a snippet in the head tag of an HTML page, but I'm wondering if there's a way to do it from DNSimple's side, or if that even makes sense to attempt.

Update name and logo: https://support.google.com/a/answer/7126147?hl=en

djeese is no longer active. See https://www.divio.com/en/products/aldryn-cloud/

https://devcenter.heroku.com/changelog-items/1488

Currently, when adding a custom domain on Common Runtime, Heroku currently specifies a DNS target based on your domain name e.g. my-domain-name.herokudns.com. On October 16, 2018, Heroku will change to a randomly generated DNS target scheme, e.g. whispering-willow-5678.herokudns.com.

You should always use the DNS target provided by Heroku Dashboard or API for your DNS configuration. The change only applies to apps and domains on the Heroku Common Runtime and existing custom domains will not be affected.

See http://format.com/

In #42, it was mentioned that it will be possible in the future for the user to select an optional subdomain.

Once this feature is implemented, it would be cool if the service would automatically choose to use CNAME instead of ALIAS, if a subdomain is provided. Maybe the type could be specified as CNAME|ALIAS to request this automatic behavior.

After setting up an S3 website on a Frankfurt located bucket the other day I was unable to get it loading through our domain set up via DNSimple services. That was until I realised that the endpoint differs from what DNSimple provides. I thought maybe this would be a quick fix to the template, but that isn't the case.

It seems like AWS has decided that sticking to standards isn't quite a useful feature for a large platform. Therefore we have the issue of the endpoints being different depending on the region. From a quick test it seems like only eu-central-1 and ap-northeast-2 are affected, as per below.

• imple.s3-website.ap-northeast-2.amazonaws.com
• `imple.s3-website.eu-central-1.amazonaws.com*
• imple.s3-website-us-east-1.amazonaws.com

As you can note, the difference is between s3-website and the chosen region, preferring to use a . instead of a -.

Why this is the case I do not know, but I also no longer work for a company with sway at AWS so contacting them as my lowly self would probably yield little to no useful response. I'd be happy to provide a fix if there's something I'm missing (another repository?), but it seems like you need to add some conditionals on your end.

Per some customer feedback, it appears we are not configuring the correct IP addresses for webflow and we could instead use ALIAS records to correctly point to their service. The support page linked to by @synthemesc does not contain any IP address information, but their support informs us that it would be easier to use ALIAS records.

Roon.io no longer exists

We currently prompt for the following Heroku fields this way:

A customer wrote in saying that the field above didn't really match the Heroku terminology. We should use "DNS Target" instead:

They have deprecated custom domains.

Heroku have changed their DNS target in order to simplify a few redirection when switching over to SSL: https://devcenter.heroku.com/changelog-items/1060

Note however that the docs still seem to lag behind since there are plenty of references to "herokuapp.com"

The service is no longer active.