* Replace Jekyll highlight tags with fenced code blocks
Replace Jekyll highlight tags with fenced code blocks.
Canonicalize javascript to js.
Correct highlighting languages.
Add highlighting to code blocks.
Remove leading $ from bash blocks.
Remove empty lines at start and end of code blocks.
Stripped trailing whitespace.
* Fix language of code highlighting
TXT records are now handled different.
1. The raw input from dnsconfig.js is passed all the way to the provider. The provider can determine if it can or can't handle such records (auditrecords.go) and processes them internally as such.
2. The CanUseTXTMulti capability is no longer needed.
* DSPs now register a table of functions
* Use audits for txt record variations
* unit tests pass. integration fails.
* fix deepcopy problem
* rename to AuditRecordSupport
* Reduce use of TXTMulti
* Remove CanUseTXTMulti
* fix Test Skip
* fix DO
* fix vultr
* fix NDC
* msdns fixes
* Fix powerdns and cloudflare
* HEDNS: Fix usage of target field to resolve TXT handling (#1067)
* Fix HEXONET
Co-authored-by: Robert Blenkinsopp <robert@blenkinsopp.net>
Co-authored-by: Jakob Ackermann <das7pad@outlook.com>
* 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!
* 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>
