According to the RFC, the way to indicate that a SRV has no target is to set the target to ".". Some providers do not handle this, or the API returns "" instead of ".". This situation is now tested in the integration tests and all providers (that support this) have been fixed.
* Cloudflare: Fix decoding empty SRV target (fixes#561)
SRV records with empty (".") targets are now returned as false by
the API, which breaks Unmarshaling it into a string.
* Use custom type for Cloudflare SRV target
Rewrote the SRV target decoding to use a custom type for (un)marshaling, as
Cloudflare returns false for null targets, but it requires a single period
for giving it one. The target code has also been made more flexible to future
API changes with additional normalization.
This has been tested with record creation, deletion, and update and works
as of 2019-11-05.
* DigitalOcean: Fix target FQDN for null targets
Without this, dnscontrol thinks an update is needed (.. != .) even
when the SRV target is correct.
* DNSimple: Fix parsing of null SRV target
DNSimple only returns two fields when the target is null.
* NameDotCom: Add note about not supporting null SRV targets, skip test
* DNSimple: Do not append a . unless we have all three parts
Signed-off-by: Amelia Aronsohn <squirrel@wearing.black>
* Regenerated provider matrix
Cloudflare API tokens are a new way to authenticate to Cloudflare API.
Unlike the Global API key, tokens can be given specific permissions to
only access parts of the API. See [1] for details.
[1] https://blog.cloudflare.com/api-tokens-general-availability/
This commit introduces a new credential for cloudflare called
`apitoken`, which is mutually exclusive with `apiuser` and `apikey`.
In order for DNSControl to work with this token, it should have the
right to read DNS zones and edit DNS records.
Closes#534
FYI: The support is very minimal. It only supports redirect if it is the last item in an SPF record. At that point, it is equivalent to include.
* In SFP, treat redirect like a special include.
* Document SPF redirect: limited implementation.
* docs improvements
* Updated matrix as part of "go generate" (e.g. adds SSHFP row)
* Commiting full matrix file
* Added docs for SSHFP record
* Matrix: Mark OVH as SSHFP-capable in docs (see PR #482)
* Improve comments in checkLabel
* Reformat labelUnderscores to make it easier to add to
* Add to exception list for label warnings
* Add underscores in hostnames to the opinions list.
- Support DelegationSet for Route53 (create-domains only)
- Retry Route53 operations which fail for rate limits under large numbers of domains
- Support for name_server_set for GCloud (create-domains only)
- Docs for both
* Maint: run generate for missing documentation
Apparently current master is missing some generated documentation.
* Populate ovh zones cache as early as possible (#412)
We are caching the OVH zones in GetNameservers.
It turns out it isn’t a good idea, because GetNameServers will not be called
if the user selects no name servers for a given domain by using for example:
```
D(‘my domain’, DnsProvider(ovh, 0)) {
}
```
The subsequent GetDomainCorrections would automatically fail
with an unknown domain error, because the zones cache hasn’t been
filled in.
To solve the issue, the ovh provider now populates the zones cache during
initialisation.
The `GANDI` provider also seems to be unable to see new domains (the
ones bought through the new interface), but I didn't mention that as
it may be a bug that could be solves at some point.
* Manual rebase of get-certs branch
* fix endpoints, add verbose flag
* more stable pre-check behaviour
* start of docs
* docs for get-certs
* don't require cert for dnscontrol
* fix up directory paths
* small doc tweaks
