Implement `zone add` functionality

[quinncomendant]

Denominator, surprisingly, lacks the ability to create zones (new hosted domains). It would not be complicated to add this functionality, but perhaps it would also require implementing zone update and zone delete commands.

The Rackspace Cloud DNS API requires name and email address, and optionally a ttl and a comment.

AWS Route 53 API requires name and CallerReference, and optionally HostedZoneConfig and comment.

For each API, denominator's arguments would have different requirements, but in general might look like:

denominator […] zone add --name example.com --email-address dns@admin.com --ttl 300 --comment "Domain for project foo"

Thanks, Quinn

[codefromthecrypt]

@jwbraucher care to comment on DynECT? @jdamick UltraDNS @wnagele discoverydns?

Ideally, we could have minimal properties sent, even if that means setting a dummy email address which could be overridden as something helpful via properties

[jdamick]

UltraDNS can support creating either primary or secondary zones. Ours is created off of the account name though, not the email address as show in the example.

[wnagele]

DiscoveryDNS supports creating zones. Needs a few parameters to be passed.

Required: DNSSEC (boolean) Branded Nameservers (boolean) Plan (String) Nameserver Set (String)

Optional: Resource Records Group (String)

[codefromthecrypt]

Next steps are to make a table of these properties, and see if zero config is still possible. If that isn't possible, if it is at least possible with account-level defaults. That means this table would include the required properties, besides the obvious one which is zone name, a column for if there's an api default for them, and the scope of that property (ex. account level, zone, or otherwise).

[quinncomendant]

It would probably make sense to add zone delete functionality too.

• RS Cloud DNS Delete domains and subdomains
• AWS Route 53 DELETE DeleteHostedZone

[codefromthecrypt]

good catch. This will help users, and plus.. Otherwise our tests will leak :)

[codefromthecrypt]

crazy latency, but I plan to spend a bit of time in denominator. ping back if you'd still like this addressed!

[quinncomendant]

Getting zone add would be my top vote. Thanks for circling back to us. =)

Quinn

On Tue, 27 Jan 2015 22:12:04 -0800, Adrian Cole wrote:

crazy latency, but I plan to spend a bit of time in denominator. ping back if you'd still like this addressed!

---

Reply to this email directly or view it on GitHub: https://github.com/Netflix/denominator/issues/264#issuecomment-71786302

[jwbraucher]

Dynect definitely supports managing zones via the API: https://help.dyn.com/create-primary-zone-api/ https://help.dyn.com/get-zones-api/ https://help.dyn.com/delete-one-zone-api/

This isn't something our organization needs especially, but a reasonable feature to add to denominator nonetheless.

[codefromthecrypt]

Yep. And making tests create their own zones is helpful too.

[codefromthecrypt]

From the caller's POV, they should be able to accomplish this with only supplying the zone name. Anything beyond name is different per provider. Extra required parameters will have to be implicit defaults for now.

The impact is that this won't support advanced things like DNSSec and to adjust the rname or ttl, you'd need to use to do a follow-up call to ResourceRecordSetApi.put(soa), which we can add a live test to ensure works.

The advantage is that users can get started easily and without needing to know the nuances of the providers, which retains the existing experience. It is also an advantage as it makes this feature easier to complete :)

[codefromthecrypt]

I plan to do this before moving to the new UltraDNS api. In such case, here are the commands to use. cc @jdamick @jonbodner

<v01:createPrimaryZone>
  <transactionID/>
  <accountId>{accountId}</accountId>
  <zoneName>{zoneName}</zoneName>
  <forceImport>false</forceImport>
</v01:createPrimaryZone>

<v01:deleteZone>
  <transactionID/>
  <zoneName>{zoneName}</zoneName>
</v01:deleteZone>

[codefromthecrypt]

@quinncomendant fyi, we could still have the CLI accept the email and ttl args, even if the library does it in two commands. Let's see how this goes.

[codefromthecrypt]

@wnagele @MisterK keep an eye on this, as this will be in 4.5. Since it adds methods to the ZoneApi interface, you'll want to have corresponding version available.

[codefromthecrypt]

@everett-toews Can you explain this one? Rackspace CloudDNS seems to support duplicate domains. For example, it has a list by name function. However, if you try to create a domain with the same name, it errors out with this beauty. What's the deal?

{"name":"zonetest.denominator.com","emailAddress":"fake@zonetest.denominator.com"}]}","error":{"message":"Conflict","code":409,"details":"Domain already exists"}...

PS any ETA on Rackspace moving to designate? I forgot how awful this api is.

[codefromthecrypt]

status update:

• working locally on ultradns.
• clouddns is strange because of duplicate dns create behavior, plus it doesn't return SOA records.

will work more tomorrow morning

[codefromthecrypt]

For the time being, I'm going to assume that clouddns has a configuration bug saying it supports multiple domains with the same name. I'll fix the implementation, as there's no api to create multiple domains with the same name at this point. http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/POST_createDomain_v1.0__account__domains_domains.html

[codefromthecrypt]

Looks like designate has the same behavior. The domain ids only indicate different instances of a domain over time. It does not indicate the ability to have duplicate zones (like route53 does). This is a big semantic gap that needs to be plugged before putting in zone add support.

[codefromthecrypt]

Also, looks like designate doesn't automatically populate NS records like other clouds do. I don't think a test that ensure zone creation ends with NS population will hold.

[codefromthecrypt]

status update: basic functionality working locally on designate, clouddns, and ultradns. will proceed to dynect and route53, then revisit api. We may indeed want to expose how to set the email, ttl as it is very provider-specific and some don't even support SOA records!

[codefromthecrypt]

status update: all providers working locally. will cleanup tomorrow. Nuances: Route53 needs a unique caller reference per domain with the same name. DynECT tasks can prevent zone deletion from working. I've routed "blocked on task" errors to retry with at least a second pause.

[codefromthecrypt]

350 is a prerequisite of zone add

[etoews]

@adriancole The Cloud DNS docs explicitly say it does not support duplicate domains, see Create Domain

If you attempt to create a domain that already exists, the API will return an exception saying that the domain already exists.

That list by name function (when it takes the name param) is just a way to look up a single domain by name (as opposed to get by id) and get a list of 1 back.

I honestly can't say when we'll make the switch to Designate.

[codefromthecrypt]

Thanks, Everett. What misled me wasn't the docs, rather the fact that we (probably me) marked the provider as supporting duplicate domains. I was wondering why we did that, and the fact that there was a list by name thing made the topic more confusing. Again, thanks for verifying!

[codefromthecrypt]

initial implementation, covering all providers for basic create by name https://github.com/Netflix/denominator/pull/351

[codefromthecrypt]

nearly there. should be complete by the weekend.

[codefromthecrypt]

Note: zone add is going to be an alias for zone replace Except for the lack of comment support, the syntax will look very similar to the original request.

[codefromthecrypt]

• + -n parameter to zone list
• + add, update and delete zone commands