Document how to use multiple providers

[samip5]

Please document how to utilize your application with multiple providers.

I would like to do the following:

home.example.org => PowerDNS, if annotation filter allows
example.org => Cloudflare, if annotation filter allows

Similar how you can in external-dns do public=true annotations and only then push it to Cloudflare.

[danopia]

So this is a bit of an open question because external-dns doesn't have multiple provider support (that I'm aware of). I added very basic support, where every single endpoint that gets pulled in by a source is equally eligible to be exported to each configured provider. I currently only offer annotation filters at the source level.

As far as adding multiple providers, I actually have an example, which includes zone filters to be a bit more explicit:

kubernetes-dns-sync/examples/complex.toml

Lines 14 to 20 in 6fb5d81

	[[provider]]
	type = "vultr"
	domain_filter = [ "example.com", "asdf.com" ]
	[[provider]]
	type = "google"
	zone_filter = [ "my-test-zone" ]

In your example, configuring both providers today would result in iot.home.example.org getting created in both providers, given that the parent zones already exist in both. I have a similar zone layout & I personally run two copies of this program, with different annotation-filters on each instance. So one instance acts as an internet instance and the other as a vpn instance. This works because these instances have different source and provider configurations.

I'm open to ideas on how to solve this with a single instance, but I also have some of my own:

1. Allow for further annotation filtering at the provider side.

   • I believe this is your suggestion.
   • Downside: all sources used must have the same annotation, e.g. your nodes must have your ingress-class annotation to use the node source in this configuration. This solution wouldn't be applicable to my current usage.

2. Automatically recognize nested zones and prevent matching records from being presented to a less-specific zone.

   • In your example, with home.example.org and example.org as two zones, any record under home.example.org would only be presented to the zones named home.example.org. Other records are unaffected
   • Downside: doesn't allow having two different versions of the same zone managed by a single kubernetes-dns-sync instance

3. Optionally allow a source definition to include a "context" of sorts, which places the endpoints into a non-default list which only a provider definition with a matching "context" will pick up. So you'd have two different source blocks with your different annotation filters.

   • Downside: repetitive source blocks, probably error-prone to configure

4. Maybe some sort of zone or provider priority thing, so that records are only given to the highest-priority zones that somehow match them. This is like a non-automatic version of idea 2.

   • I can't really imagine when this solution would be more useful than the other.

5. Allow for blocking a particular list of names from being managed by a provider, including child names. In your example, this would involve adding home.example.org to the block list for the Cloudflare provider. This can be forgotten easily but I feel it could be quite robust, as the providers don't need to interact to provide this feature.

[danopia]

I left this alone for a bit... I want to release a 1.0 in the next month or so, and one last feature I want to add is a better method of configuring the controller.

I'm now leaning towards defining a new CRD which provides a single dns-sync configuration (a list of sources + providers, and a registry). Secrets could be referenced directly for credentials, like if there's two different Cloudflare accounts. You'd then be able to create multiple CRD resources to have parallel universes of DNS records from one dns-sync instance.

If I take this approach I'll probably keep TOML config support as well (at least thru 1.x) just because it's a bit easier to test and get going.

For more background, there's a wishlist ticket on external-dns about working with CRD configurations: kubernetes-sigs/external-dns#1961

[samip5]

Hi,

How is it going? It seems the repo hasn't had activity in a while.