This functionality is required by the GCLOUD provider, which supports
recordsets of type DS but only for child records of the zone, to enable
further delegation. It does not support them at the apex of the zone (@)
because Google Cloud DNS is not itself a registrar which needs to model
this information.
A related change (14ff68b151, #760) was
previously introduced to enable DS support in Google, which broke
integration tests with this provider.
To cleanly support this, we introduce a new provider capability
CanUseDSForChildren and appropriate integration tests. Further, it is no
longer possible to verify a provider has the proper capabilities for a
zone simply by existence of particular records; we adapt the capability
checks to enable inspection of the individual recordsets where this is
required.
Closes#762
Thanks to @haraldkoch for starting this, @McNetic for picking it up.
* Added DS record type
* Added DS for cloudflare provider with tests
* Removed DS validation, fixed parse test
* Added generated files
* Added dnsimple ds record
* Regenerated documentation matrix
* rebased and regenerated
* Updated integration tests
* Rebase and regenerate
* Enable DS record type for provider desec
* Added DS record type
* Added DS for cloudflare provider with tests
* Removed DS validation, fixed parse test
* Added generated files
* Added dnsimple ds record
* Regenerated documentation matrix
* rebased and regenerated
* Updated integration tests
* Rebase and regenerate
* Enable DS record type for provider desec
* Rebase and fixes
Co-authored-by: Robert Koch <robert@kochie.io>
Co-authored-by: Nicolai Ehemann <nicolai.ehemann@enerko-informatik.de>
* Tests: ensure provider capabilities are checked
Adds test: `TestCapabilitiesAreFiltered`
We have a number of records and pseudo-records which in theory can only
be used with a given provider if that provider indicates support. In
practice, we've been missing the checks for that support and have been
passing the records down anyway. The advice comment in the
providers/capabilities.go file to edit `checkProviderCapabilities()` has
not been reliably followed.
We need an internal self-consistency test. The constants are not
directly exported or enumerable based solely on the package interfaces
at run-time, but with source access for a test suite, we can use the
`go/ast` and related interfaces to examine the code, extract all the
constants from a given package, figure out which ones we want to be
handled, and then insist that they're handled.
Before my recent work, we only checked:
ALIAS PTR SRV CAA TLSA
After this commit, we check:
ALIAS AUTODNSSEC CAA NAPTR PTR R53_ALIAS SSHFP SRV TLSA
I've added `AUTODNSSEC` as a new feature; `SSHFP` and `PTR` were caught
in other recent commits from me; implementing this test caused me to
have to add `NAPTR` and `R53_ALIAS`. I whitelist `CanUseTXTMulti` as a
special-case.
This should prevent regressions. We will probably want to post publicly
to warn people that if they're using SSHFP/PTR/NAPTR/R53_ALIAS then they
should check the feature matrix and if they don't see their provider
listed, to report is as "hey that actually works" so we can update the
provider flags. Bonus: our feature matrix will suddenly be more
accurate.
* Add comments/docs for capabilities authors
* fixup!
* fixup!
* github.com/miekg/dns
* Greatly simplify the logic for handling serial numbers. Related code was all over the place. Now it is abstracted into one testable method makeSoa. This simplifies code in many other places.
* Update docs/_providers/bind.md: Edit old text. Add SOA description.
* SOA records are now treated like any other record internally. You still can't specify them in dnsconfig.js, but that's by design.
* The URL for issue 491 was wrong in many places
* BIND: Clarify GENERATE_ZONEFILE message
* Add AUTODNSSEC, implement for DNSimple
There are two models for DNSSEC in DNS management: either dnscontrol
manages all the DNSSEC records and has to be invoked regularly for
re-signing, or the provider manages DNSSEC automatically and dnscontrol
is not involved beyond saying "yeah, do that".
This implements the latter, as a model, and for one provider.
Potentially we could tune/configure options for DNSSEC such as
algorithm, but DNSimple don't expose that API so I haven't implemented
it.
This minimal model should be something which maps into other providers
cleanly.
* Fix missing CanAutoDNSSEC on provider
* Validation fix for master broken
This is broken in master and causing Travis in my branch to fail. The
validation tool runs with `gofmt -s` to require "simplify", and so
rejects an ignored second bound variable to range iteration.
* Correct wire in the AUTODNSSEC validation step
* Add GetZoneRecords to DNSProvider interface
* dnscontrol now uses ufave/cli/v2
* NEW: get-zones.md
* HasRecordTypeName should be a method on models.Records not models.DomainConfig
* Implement BIND's GetZoneRecords
* new WriteZoneFile implemented
* go mod vendor
* Update docs to use get-zone instead of convertzone
* Add CanGetZone capability and update all providers.
* Get all zones for a provider at once (#626)
* implement GetZoneRecords for cloudflare
* munge cloudflare ttls
* Implement GetZoneRecords for cloudflare (#625)
Co-authored-by: Craig Peterson <192540+captncraig@users.noreply.github.com>
Although _mta-sts is normally used with a TXT record it can
also be used with a CNAME record to delegate the authority.
See sections 3.1 and 8.2 of RFC8461 for details.
* Replaced errors.Wrap with fmt.Errorf (#589)
* Find: errors\.Wrap\(([^,]+),\s+(["`][^"`]*)(["`])\)
Replace: fmt.Errorf($2: %w$3, $1)
* Replaced errors.Wrapf with fmt.Errorf (#589)
* Find: errors\.Wrapf\(([^,]+),\s+(["`][^"`]*)(["`])\)
Replace: fmt.Errorf($2: %w$3, $1)
* Find: errors\.Wrapf\(([^,]+),\s+(["`][^"`]*)(["`])(,[^)]+)\)
* Replace: fmt.Errorf($2: %w$3$4, $1)
* Replaced errors.Errorf with fmt.Errorf (#589)
* Find: errors\.Errorf
Replace: fmt.Errorf
* Cleaned up remaining imports
* Cleanup
* Regenerate provider support matrix
This was broken by #533 ... and it's now the third time this has been missed.
* Switched to v2 go.mod
Also set GO111MODULE=on in build stuff to always use Go modules
even when in GOPATH.
* Ensure go.mod, go.sum, and vendor are up to date
* Attempt to fix Azure pipelines
* Add set -e to properly fail on exit (it didn't seem to be
propagating properly before).
* Set workingDirectory for GoFmt and GoGen (this might be why it
fails unlike compile and unitests).
* Another attempt to fix Azure Pipelines
* Use the Go env template for all go-related jobs.
* Completely fixed Azure Pipelines
* Added a display name to GoFmt for consistency.
* Fixed diffs for GoFmt and GoGen.
* Show git status for checks.
* Drop GOPATH for tests
TODO: Do the same for integration tests.
* Drop GOPATH for integration tests
* Show more diffs
* Regenerate provider support matrix
This wasn't done in #590...
* 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.
* models/record.go: SRV targets are case insensitive. Downcase them.
* models/t_srv.go: Rename setTargetIntAndStrings() to setTargetSRVIntAndStrings() (makes it easier to search for /setTargetSRV/).
* pkg/js/parse_tests/021-srv.js*: SRV: Add parse_tests
* pkg/normalize/validate.go: SRV targets are hostnames, turn into FQDNs.
* Add #rtype_variations warnings for future developers
* Added CAA support
* Fixed bind parsing of CAA records
* Added CAA parsing test
* Renamed CAA json fields
* Added CAA tag validation
* Updated CAA docs to clarify on the value field
* parse_tests: Fixed typo in caaflags
* Added integration test
* Small cleanups
