CLOUDFLAREAPI: LOC supported by CF but not by integration

[ConnorMcF]

Describe the bug
The LOC record is supported by Cloudflare, but not by the integration.

dnscontrol/providers/cloudflare/cloudflareProvider.go

Line 46 in 56220fb

providers.CanUseLOC: providers.Cannot(),

Expected behavior
Cloudflare supports LOC records, I would assume that the DNSControl integration would also support them.
I'm hoping this may be as simple as switching Cannot to Can.

LOC is listed as a valid type in the Cloudflare API: https://developers.cloudflare.com/api/operations/dns-records-for-a-zone-list-dns-records

DNS Provider

• Cloudflare

[cafferata]

I'm hoping this may be as simple as switching Cannot to Can.

That's right! Do you want to prepare a GitHub pull request yourself? Or shall I do that for you? ☺️

[cafferata]

cc: Maintainer CLOUDFLAREAPI @tresni for visibility.

[cafferata]

type string
Record type.

Allowed values: A, AAAA, CAA, CERT, CNAME, DNSKEY, DS, HTTPS, LOC, MX, NAPTR, NS, PTR, SMIMEA, SRV, SSHFP, SVCB, TLSA, TXT, URI

Deeplink

[tlimoncelli]

I've been thinking about this bug and the associated draft PR #2799.

This bug exposes a fundamental design problem with DNSControl: a record like LOC() has its inputs validated, massaged, etc, in Javascript which is difficult to work with because DNSControl has no unit testing framework, debugging tools, etc. for Javascript. Also, the Javascript interpreter we use implements an old standard of Javascript. (Such tools exist for Javascript, but we don't use them.)

If you look at how CF_SINGLE_REDIRECT() was implemented, you'll see it uses a new technique that does all that processing in Go, which has a richer toolset for unit testing, debugging, and so on. With that technique, Javascript simply packages up the arguments of CF_SINGLE_REDIRECT and sends them verbatim to "the Go side of the house". Once in in the Go environment, it's easier to work with the data.

In the future I hope to migrate LOC to use this new technique. That will make it easier to enable LOC and the related builders on many different providers. (Though I can't make promises about the dates because this isn't a top priority.)

I'll be moving MX() to this new technique first. Once I have 2 records using it, I'll be able to generalize it so that it is easier to adopt for additional record types. LOC would be a good candidate at that time.