Cannot create a reverse pointer DNS record with slcli

[TyMac]

The following command returns no error but no ptr record seems to be created:

slcli dns record-add domain001.com 233 ptr server0001.damain001.com.

233 is the last octet in the IP address. The ongoing thread in the softlayer forums is located here:

https://forums.softlayer.com/forum/softlayer-developer-network/general-discussion/84322-error-when-attempting-to-use-slcli-to-create-a-reverse-pointer-dns-entry

[sudorandom]

Interesting... so PTR records don't come back from the API the same way that other records do... That seems weird.

This is an API call that can be used to see PTR records: http://sldn.softlayer.com/search/apachesolr_search/getReverseDomainRecords

Just a note, there is a command that enabled you to sync dns records (for virtual servers only). Example as follows:

$ slcli vs dns-sync some-host

The source code for that lives here:

softlayer-python/SoftLayer/CLI/virt/dns.py

Lines 60 to 80 in 3eafa59

	def sync_ptr_record():
	"""Sync PTR record."""
	host_rec = instance['primaryIpAddress'].split('.')[-1]
	ptr_domains = (env.client['Virtual_Guest']
	.getReverseDomainRecords(id=instance['id'])[0])
	edit_ptr = None
	for ptr in ptr_domains['resourceRecords']:
	if ptr['host'] == host_rec:
	ptr['ttl'] = ttl
	edit_ptr = ptr
	break
	if edit_ptr:
	edit_ptr['data'] = instance['fullyQualifiedDomainName']
	dns.edit_record(edit_ptr)
	else:
	dns.create_record(ptr_domains['id'],
	host_rec,
	'ptr',
	instance['fullyQualifiedDomainName'],
	ttl=ttl)

There still is an issue that PTR records don't seem very visible from the CLI at this time.

[briancline]

There was a time when I spent about 4 hours looking into the API calls for PTR records for both IPv4 and IPv6 zones. Creating a PTR for an IPv6 zone through our API was quite an endurance test, but got it to work through the Python client eventually.

Might be hairy to create a user-friendly way to specify a zone without having to give the full in-addr.arpa or ip6.arpa zone names, but could probably allow a CIDR to help interpret the proper zone name. Seems necessary for specifying ip6.arpa zone names though because it gets really tedious and error-prone really quickly.

Either way, in this case, it sounds like the desire is to allow the existing commands handle PTRs as expected in a normal zone (a typical case when someone's used created CNAME in a .in-addr.arpa zone to delegate an individual PTR to you, by using a CNAME to point to some predetermined record in your zone).

I'll give this a shot to get it added to the DNS manager and the CLI.

[dominikkukacka]

After the change will the feature also be available in the SDK?