Feature Request: Possibility to create additional (types of) DNS records through CRDs

[mtsr]

The idea is to watch CRDs in addition to Ingress and Service and automatically create DNS records of various types as specified. This would allow more flexibility in created records (SRV records for example), while putting the records into a Helm Chart would give almost the same ease of use as right now.

Optionally, it might be interesting to split all of external-dns into two parts: A part that watches Ingress and Service and creates CRDs for those. And a part that watches CRDs and creates DNS records for those. That way, someone who is OK with fully specifying DNS records in say a Helm Chart, would not need to run the first part.

@szuecs asked on Slack that specify if I want to work on this myself. I'm interested, but want to take a look at the existing code to judge how hard or easy this would be to add. Estimates from people familiar with the project are also welcome.

[mtsr]

Something that needs to be specified in advance is how to allow all different desired DNS record types. It might be useful to start with the set supported by GCP, AWS, etc.

From GCP Cloud DNS:

• A
• AAAA
• CAA
• CNAME
• DNSKEY
• DS
• IPSECKEY
• MX
• NAPTR
• NS
• PTR
• SPF
• SRV
• SSHFP
• TLSA
• TXT

[linki]

Linking an old issue with the same idea here: https://github.com/kubernetes-incubator/external-dns/issues/21

Making another Source for a particular CRD seems like a great first step as it's quite isolated from the rest of code.

I like the idea of having a central DNS resource (kubectl get dns) and logically splitting ExternalDNS in two parts (one creating dns objects from Services etc. and the other one reading dns objects and creating them in some provider.)

[munnerz]

I commented in #21 a while back, but just to re-voice it here...!

This is something we're also really interested in for cert-manager. We currently support ~5 DNS providers, and there has been talk of adding 'generic' providers (ie some grpc based thing), supporting additional providers, or supporting some external component such as external-dns to take care of updating DNS for us.

IMO, a world where cert-manager can simply create a TXTRecord resource (or DNSRecord, or something similar), which causes the record to be updated in the appropriate cloud provider, would be brilliant.

The current functionality of external-dns could then also be extended to use this pattern (and even refactored out, if that made sense to do!). Instead, to achieve what external-dns does now under this model, we can create a very 'slim' controller that watches services/ingresses and creates corresponding DNSRecord resources (saving having to maintain many more code paths). This is similar to how we handle Ingresses vs Certificates in ingress-shim with cert-manager.

Crucially though, I think the "auto generation of DNS records for services/ingresses" and "setting DNS records" should be viewed as two distinct things, and there should be an easy way to opt out of the "auto generation of DNS records for services/ingresses" behaviour for those users that simply want to be able to manage DNS zones via the Kubernetes API 😄.

Is this something that sounds vaguely acceptable/reasonable as a proposal? What would the best first steps be? Dive straight in and get some code together, or a proposal? 😄

[mtsr]

@munnerz That is exactly what I meant.

Sorry that this fell off my radar. My project which I was going to use this for fell through. It's still an interesting task though, so I really free a few hours in the evening.

[mtsr]

Ok, I made a small start on this, but I'm having some trouble finding a version of k8s.io/code-generator that's compatible with the current version of k8s.io/client-go. Are there any plans to upgrade client-go?

[linki]

@mtsr Which version do you need?

[mtsr]

I'm not sure, I haven't tried this without external-dns yet. It seems like there are some breaking changes, though, as external DNS failed to build with any newer versions.

Are there reasons for sticking with the current version of client-go or is upgrading an option? I assume newer client-go works fine with older kubernetes API versions? In which case I could just try upgrading to a newer version and see what needs fixing.

[spjmurray]

Ah ha, I like this project :) So I have a use case that probably fits in this issue. Given an application with client side sharding, each pod has a service exposing it to the internet. We'd love DNS for the ease of deploying with TLS e.g. wildcard certificates for starters. What would also be excellent is service discovery so connection strings can remain static; essentially we need an SRV record with a selector that picks up all the individual services dynamically.

[szuecs]

@spjmurray for me it sounds more, that you like to have DNS SRV records from kubernetes svc/endpoints, not to have it manually set via a CRD. Is my assumption correct? If so, please create a separate issue. :)

[spjmurray]

Roger that!

[shashidharatd]

We do require this feature in federation https://github.com/kubernetes-sigs/federation-v2. i assume nobody is working on it actively, so i want to give a shot. @linki, as a precursor, external-dns should start using the latest stable version of k8s.io/client-go. is there any particular reason that there is a below constraint?

[[constraint]]
  name = "k8s.io/client-go"
  version = "~3.0.0-beta.0"

latest stable client-go version can still work with all previous k8s versions

[mtsr]

@shashidharatd That's great! I started on this twice, but got sidetracked by other stuff. Let me know if I can help.

[shashidharatd]

/cc @pmorie

[whereisaaron]

Has this feature been implemented @njuettner? Can other record types be created now?

[csrwng]

@njuettner was this issue closed because CRDs were implemented as a source? or because there is no plan to support additional record sets in external-dns? My project has a need for NS record support and I can submit a PR if there's interest.

[TimJones]

@njuettner We also need to support adding a CAA record to allow for cert-manager to generate LetsEncrypt for the registered domain. Is there something we need to do to get this to opened again? Or does anyone else have a work-around?

[pdf]

Looks like this was implemented in #657

Docs are under contributing for some reason: https://github.com/kubernetes-sigs/external-dns/blob/7505f29e4cec80ca20468b38c03b660a8481277d/docs/contributing/crd-source.md

[jeanlucmongrain]

Has this feature been implemented @njuettner? Can other record types be created now? @njuettner was this issue closed because CRDs were implemented as a source? @njuettner We also need to support adding a CAA record to allow for cert-manager to generate LetsEncrypt for the registered domain. Is there something we need to do to get this to opened again? Or does anyone else have a work-around?

@njuettner Thanks for your non-answer