AAAA / ipv6 support

[anotherZero]

I am thinking about implementing AAAA / ipv6 support for this package but I'm not sure how best to go about it.

After research I'm finding that the current URL used for getting IP address is returning ipv4 only. (seems to be a current limitation with https://api.ipify.org. Supposedly fixed, but seems to be not functioning now)

Some thoughts to get the ball rolling --

Assertions

• Some hosts will only have ipv6 addresses, and some will only have ipv4 so we can't assume that one or both will exist.

• If only 'A' or 'AAAA' records exist then it might be nice to intelligently make the call to get the public IP for only the required type.

• Separate api calls will need to be made to obtain each ip address since a single request can't be made over both ipv4 and ipv6 protocols simultaneously

• Will need to gracefully handle a failed request for ip address since one or the other might not resolve

Specific Questions

• Should ipv6 address be determined by an api call or by assuming an ipv6 address is the same as the public?

• If an api should be used to obtain ipv6 address, what is a preferred alternative to ipify.org?

• Should the address(s) be stored as JSON in a single ipfile or as strings in separate files?

[lmammino]

Hello @anotherZero, Thanks for the idea and for the elaborate proposal.

At a first glance I am not sure if I want to go for a "smart" approach or for a configuration oriented one (user needs to explicitly define the protocol he wants to use and that will determine the execution flow of the application).

If we use this approach we can easily add the SMART option later on and use some technique to determine wether an IPv6 or an IPv4 is available and which one has higher priority in case they are both available.

So if we go in this direction, the new config file might become something like this:

{
  "apiKey": "",
  "secret": "",
  "domain": "example.com",
  "records": [{"protocol": "ipv6|ipv4|smart", "name": "mysubdomain", "ttl": 600}]
}

Notice that I am replacing the key type with protocol, which could have ipv6, ipv4 or smart as possible values.

As an alternative, we could keep the type key and detect the protocol from the value:

• A -> ipv4
• AAAA -> ipv6
• smart -> smart

This is probably better for backward compatibility.

Anyway I think this still requires a bit of thinking and maybe some experimentation in order to be able to come up with a good solution.

Do you have any plan to start playing with it?

[anotherZero]

I like the idea of a smart option. Don't forget about other possible records that one might want to continue managing such as CNAME or MX (which might better lend itself to keeping the type key.

I am interested in working on this but I have to admit that I haven't worked with bluebird or es6 much so there's a bit of a learning curve. It might be a bit before I could produce anything.

[lmammino]

Regarding CNAME records, I don't think this utility can really be useful (as previously discussed here).

For MX records, it is a very similar situation. With MX records you won't be specifying IP addresses as values but other domain names (which may refer either A, AAAA or CNAME records).

An example here (from this page):

Host/Domain	Address/Mail Server/MX Entries/Value	Priority
@	mx.zoho.eu.	10
@	mx2.zoho.eu.	20
@	mx3.zoho.eu.	50

As far as I am aware you can't specify IP addresses in the Mail Server column.

With this in mind would you prefer to go with a type approach or with the protocol one?

Personally, at the moment, I am more inclined towards the type one.

[anotherZero]

I realize that there is a more limited usefulness for other types of records, but I am currently using this utility to set about a dozen records when deploying a new server.

I use saltstack to write out a config.json and run godaddy-dns once. It's kind of nice to have all of the dns entry calls bundled into a single package as opposed to having the ip related ones done by this package, and the cname/mx done somewhere else.

That being said, I agree that type is the correct parameter to use :)

[lmammino]

That's an interesting use case I haven't thought before.

I have to assume that for non-ip based records you just set the data option directly in the config value.

Something like the following config:

{
  "apiKey": "",
  "secret": "",
  "domain": "example.com",
  "records": [
    {
       "type": "CNAME",
       "name": "mysubdomain",
       "ttl": 600,
       "data": "anotherdomain.com"
     }
  ]
}

I wonder if that's something we should explicitly mention in the documentation.

Also, I am curious to have an example of config from your current use case.

[anotherZero]

I can provide an example config like the one I'm using for this use case. In this case, I'm just filling in the ip addresses as well because ipv6 isn't supported yet and I'm generating the config.json anyway.

{
  "apiKey": "",
  "secret": "",
  "domain": "mydomain.com",
  "records": [
    { "type": "A", "name": "sub1", "ttl": 43200, "data": "171.95.182.198" },
    { "type": "A", "name": "smelt.sub1", "ttl": 43200, "data": "171.95.182.198" },
    { "type": "AAAA", "name": "sub1", "ttl": 43200, "data": "2001:4860:4860::8888" },
    { "type": "AAAA", "name": "smelt.sub1", "ttl": 43200, "data": "2001:4860:4860::8888" },
    { "type": "CNAME", "name": "mail.sub1", "ttl": 172800, "data": "mail.otherdomain.com" },
    { "type": "MX", "name": "sub1", "ttl": 172800, "priority": 10, "data": "mail.sub1.mydomain.com" },
    { "type": "MX", "name": "smelt.sub1", "ttl": 172800, "priority": 10, "data": "smelt.sub1.mydomain.com" }
  ]
}

[lmammino]

Thanks a million @anotherZero! This is very helpful for me to figure out other use cases and possible improvements.

[atkulp]

Was any progress made on AAAA records? I'd be happy to help contribute but I don't want to repeat any work.

[anotherZero]

I think this has been implemented. Closing
thanks @lmammino