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
* 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)
* 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.
* Initial commit for OpenSRS registrar support #272
* sort existing name servers before comparing.
* vendor philhug/opensrs-go
* Update docs for OpenSRS #272
* Cache OpenSRS client to prevent http connection leak
* run go fmt
* govendor gopkg.in/yaml.v2
* Ignore YAML and BIND test data litter. Create README.txt files to force git to create subdirectories.
* Update convertzone to also read OctoDNS files
* Add gandi LiveDNS api provider
* vendor testify and gandi live DNS
* govendor update github.com/prasmussen/gandi-api/{client,live_dns}
* Fix Gandi-livedns TXT unit test
* TravisCI should use go 1.10
* Stable comparison of metadata (#239)
Iterating over a map in Go never produces twice the same ordering.
Thus when comparing two metadata map with more than one key, the
`differ` is always finding differences.
To properly compare records metadata, we need to iterate the maps
in a deterministic way.
Signed-off-by: Brice Figureau <brice@daysofwonder.com>
* Support for Route53 ALIAS record type (#239)
Route53 ALIAS doesn't behave like a regular ALIAS, and is much more
limited as its target can only be some specific AWS resources or
another record in the same zone.
According to #239, this change adds a new directive R53_ALIAS which
implements this specific alias. This record type can only be used
with the Route53 provider.
This directive usage looks like this:
```js
D("example.com", REGISTRAR, DnsProvider("ROUTE53"),
R53_ALIAS("foo1", "A", "bar") // record in same zone
R53_ALIAS("foo2", "A",
"blahblah.elasticloadbalancing.us-west-1.amazonaws.com",
R53_ZONE('Z368ELLRRE2KJ0')) // ELB in us-west-1
```
Unfortunately, Route53 requires indicating the hosted zone id
where the target is defined (those are listed in AWS documentation,
see the R53_ALIAS documentation for links).
* GANDI: add registrar support for changing nameservers. #87
* Update docs with Gandi registrar support #87
* Updated dependencies for Gandi Registrar Support #87
* OVH DNS Provider (#143)
This adds the OVH Provider along with its documentation.
Unfortunately we can't set this DNS provider to support `CanUsePTR`,
because OVH only supports setting PTR target on the Arpa zone.
* OVH Registrar provider (#143)
This implements OVH as a registrar provider.
Note that NS modifications are done in a "best effort" mode, as the
provider doesn't wait for the modifications to be fully applied
(the operation that can take a long time).
* Allow support for dual providers scenarios
Since OVH released their APIv6, it is now possible to update
zone apex NS records, opening the door to complete dual providers
scenarii.
This change implements apex NS management in an OVH zone.
* Added Vultr provider
* Fixed tests
* Fixed CI build validation
* Add unsupported features
* Added #rtype_variations tags according to stackexchange.github.io/dnscontrol/adding-new-rtypes
* Add title (for compatibility with #223)
* Removed extra rtype_variations
Add SoftLayer DNS as a DomainServiceProvider.
The SoftLayer API is a bit of a mess and treats MX and SRV records
differently. This leads to some replication and custom handling issues
to work around.
In this patch I have to change the SRV test case to be _tcp instead of
_protocol because softlayer requires a "known" protocol which AFAICT is
tcp, udp or tls. I think this will be acceptable in most cases.
Signed-off-by: Jamie Lennox <jamielennox@gmail.com>
