CLOUDNS: add support for LOC records

[hmoffatt]

This PR adds support for NAPTR and LOC records on CLOUDNS.

[tlimoncelli]

Thanks!

[tlimoncelli]

Please add a comment with the output of the integration tests (redact as needed)

[systemcrash]

This part should be redundant now.

[hmoffatt]

I think specifically the part that strips the decimal part of altitude is redundant? The rest has to remain as I need to assemble the LOC record from the individual API parts.

Better to call calculateLOCFields directly, but then I would have to duplicate the string to int/float conversions as the API returns strings for everything, despite being JSON.

[systemcrash]

Better to call calculateLOCFields directly, but then I would have to duplicate the string to int/float conversions as the API returns strings for everything, despite being JSON.

🤦

I don't know what to say. But coercing as early as possible is safest, especially when working with numbers and maths.

[hmoffatt]

Oops, I forgot the unit tests. This showed up an interesting quirk with CLOUDNS's handling of the size/precision fields - it quietly substitutes its own default values if you pass "0.00", even though those are documented as valid! I've put in a workaround.

[hmoffatt]

All tests are passing now except the NAPTR test. The CLOUDNS API is rejecting records with both regexp and replacement set, which the test cases use. I couldn't find anywhere in the RFC that explicitly said this wasn't allowed, but none of the examples use both fields.

=== RUN   TestDNSProviders/dnscontrol-test.dev/35:NAPTR:NAPTR_record
    integration_test.go:248: 
        + CREATE NAPTR test.dnscontrol-test.dev 100 10 "U" "E2U+sip" "!^.*$!sip:customer-service@example.com!" example.foo.com. ttl=300
    integration_test.go:253: failed create record (ClouDNS): ClouDNS API error: You need to enter either Regular Expression or Replacement, not both

[systemcrash]

Oops, I forgot the unit tests. This showed up an interesting quirk with CLOUDNS's handling of the size/precision fields - it quietly substitutes its own default values if you pass "0.00", even though those are documented as valid! I've put in a workaround.

Can you supply nothing?

helpers.js assumes 0 if the data source is DMS or DMM using a domain.js. But no assumptions or changes are made for records already deployed in a domain.

[systemcrash]

All tests are passing now except the NAPTR test. The CLOUDNS API is rejecting records with both regexp and replacement set, which the test cases use. I couldn't find anywhere in the RFC that explicitly said this wasn't allowed, but none of the examples use both fields.

=== RUN   TestDNSProviders/dnscontrol-test.dev/35:NAPTR:NAPTR_record
    integration_test.go:248: 
        + CREATE NAPTR test.dnscontrol-test.dev 100 10 "U" "E2U+sip" "!^.*$!sip:customer-service@example.com!" example.foo.com. ttl=300
    integration_test.go:253: failed create record (ClouDNS): ClouDNS API error: You need to enter either Regular Expression or Replacement, not both

Seems pretty wild. Both are necessary for a functioning NAPTR pointer. Flag an error with their support. Edit: actually, the regexp can do both. But which format don't they like from those available here?

https://docs.dnscontrol.org/language-reference/domain-modifiers/naptr

Recommend that you separate out NAPTR changes to a separate PR if you think this could take a while to resolve.

[hmoffatt]

Can you supply nothing?

It turns out that the weird behaviour with "0.00" also applies to the altitude field. If I supply nothing, I get the default of 10,000m. 😕

[hmoffatt]

Recommend that you separate out NAPTR changes to a separate PR if you think this could take a while to resolve.

Done. Once your #3130 is merged I will submit this PR.

[hmoffatt]

I've stripped out the NAPTR code for now, and updated this for @systemcrash 's decimal LOC changes.
cloudns-test.log

All the unit tests are passing, so I think this is ready to go! Thanks all for review and assistance.

[systemcrash]

Sorry lads, I've no experience with cloud but your approach looks sound. 🤓

[hmoffatt]

Hi @tlimoncelli I think this is ready to go now. Thanks.

[tlimoncelli]

Thanks!

[systemcrash]

@hmoffatt have your changes proved beneficial?

[hmoffatt]

My interest in this was academic tbh, just learning my way around Go and the dnscontrol codebase.