provide an API to manage host records

[anuaimi]

we have a traditional monolithic app that we are moving to microservices on kubernetes. we would like to use coredns with our test and staging environments. while coredns can detect the services running on kubernetes, it can not detect the services that are still running on a traditional VM. we would like our orchestration code to populate the missing host overrides. as a result, coredns should support one of the common dns apis. examples might be dnssimple or zerigo. I considered aws route53 but it is much more complicated.

dns services ruby (fog) supports:
http://fog.io/about/supported_services.html

dns services python (libcloud) support:
https://libcloud.readthedocs.io/en/latest/supported_providers.html#dns

Note, I would be willing to write the code for this issue

[johnbelamaric]

Do you expect the services running on VMs to be in the same zone or will you have different zones for k8s and those services?

If they are different zones, you can use a separate middleware (say etcd) to manage those records.

If you want them to be the same zone, it's something we may be able to do with #515 in combination with etcd (or others).

You can definitely build a middleware for any of these APIs. That can live in-tree or out-of-tree depending on how generally applicable it is. For an example out-of-tree middleware (the only one in existence so far as I know) take a look at https://github.com/infobloxopen/coredns-grpc.

[miekg]

[ Quoting <notifications@github.com> in "Re: [miekg/coredns] provide an API ..." ]

Do you expect the services running on VMs to be in the same zone or will you have different zones for k8s and those services? If they are different zones, you can use a separate middleware (say etcd) to manage those records. If you want them to be the same zone, it's something we may be able to do with #515 in combination with etcd (or others). You can definitely build a middleware for any of these APIs. That can live in-tree or out-of-tree depending on how generally applicable it is. For an example out-of-tree middleware (the only one in existence so far as I know) take a look at https://github.com/infobloxopen/coredns-grpc.

To echo what John said, to "old" way of service discovery (before k8s) was skydns + etcd; this is functionality coredns also supports. That API is just the etcd2 API (etcd3 is an open issue: #341). The generic DNS api for updating zones is called dynamic updates: rfc2136

[anuaimi]

Appreciate the quick replies. The issue with etcd is that I don't believe its meant to be available over the internet (i.e. no api key authentication). Dynamic DNS is interesting as it uses the DNS protocol. Need to investigate if this is something easy for orchestration (i.e. something in ruby or Go) to generate. Let me research both of these options further.

[miekg]

Note that the file middleware currently does not support dynamic updates, nor do any of the other middlewares.

dyn. update + tsig (+optional source ip validation) is usually used here, downside is that tsig is a shared secret. Maybe a REST like protocol layered on top of dyn. updates is something to link into.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ventz]

Adding a comment here - the referenced repo does not have any code in it. From what I can tell, no solution to this is currently available.

It seems that quite a few users are asking about the same thing - REST API to CoreDNS.

[polarathene]

It'd be useful for using CoreDNS with ACME DNS challenge support afaik?

Is there any API that CoreDNS can expose for a separate service could use to update records? It wouldn't need to be exposed to public internet, although a companion service that uses that API could expose a more secure API without burdening CoreDNS devs?

Caddy manages it's internal config in v2 as JSON, exposing an admin REST API for retrieving or modifying it for example.

[johnbelamaric]

AFAIK, no one has added this yet. To do this properly, you need:

1. A "writable" interface for backends to implement. And to implement it for a plugin or two.
2. A plugin that provides the REST API and allows writing to the backends that support it.
3. Some way of doing AAA, ideally in a plug-in mechanism that is orthogonal to the API plugin, so that other types of API plugins can be developed.