kubernetes-sigs / external-dns

Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services

hide
toc navigation

ExternalDNS

ExternalDNS synchronizes exposed Kubernetes Services and Ingresses with DNS providers.

What It Does

Inspired by Kubernetes DNS, Kubernetes' cluster-internal DNS server, ExternalDNS makes Kubernetes resources discoverable via public DNS servers. Like KubeDNS, it retrieves a list of resources (Services, Ingresses, etc.) from the Kubernetes API to determine a desired list of DNS records. Unlike KubeDNS, however, it's not a DNS server itself, but merely configures other DNS providers accordingly—e.g. AWS Route 53 or Google Cloud DNS.

In a broader sense, ExternalDNS allows you to control DNS records dynamically via Kubernetes resources in a DNS provider-agnostic way.

The FAQ contains additional information and addresses several questions about key concepts of ExternalDNS.

To see ExternalDNS in action, have a look at this video or read this blogpost.

The Latest Release

ExternalDNS allows you to keep selected zones (via --domain-filter) synchronized with Ingresses and Services of type=LoadBalancer and nodes in various DNS providers:

• Google Cloud DNS
• AWS Route 53
• AWS Cloud Map
• AzureDNS
• BlueCat
• Civo
• CloudFlare
• RcodeZero
• DigitalOcean
• DNSimple
• Infoblox
• Dyn
• OpenStack Designate
• PowerDNS
• CoreDNS
• Exoscale
• Oracle Cloud Infrastructure DNS
• Linode DNS
• RFC2136
• NS1
• TransIP
• VinylDNS
• Vultr
• OVH
• Scaleway
• Akamai Edge DNS
• GoDaddy
• Gandi
• ANS Group SafeDNS
• IBM Cloud DNS
• TencentCloud PrivateDNS
• TencentCloud DNSPod
• Plural
• Pi-hole

ExternalDNS is, by default, aware of the records it is managing, therefore it can safely manage non-empty hosted zones. We strongly encourage you to set --txt-owner-id to a unique value that doesn't change for the lifetime of your cluster. You might also want to run ExternalDNS in a dry run mode (--dry-run flag) to see the changes to be submitted to your DNS Provider API.

Note that all flags can be replaced with environment variables; for instance, --dry-run could be replaced with EXTERNAL_DNS_DRY_RUN=1.

New providers

No new provider will be added to ExternalDNS in-tree.

ExternalDNS has introduced a webhook system, which can be used to add a new provider. See PR #3063 for all the discussions about it.

Known providers using webhooks:

Provider	Repo
Adguard Home Provider	https://github.com/muhlba91/external-dns-provider-adguard
Bizfly Cloud	https://github.com/bizflycloud/external-dns-bizflycloud-webhook
Gcore	https://github.com/G-Core/external-dns-gcore-webhook
GleSYS	https://github.com/glesys/external-dns-glesys
Hetzner	https://github.com/mconfalonieri/external-dns-hetzner-webhook
IONOS	https://github.com/ionos-cloud/external-dns-ionos-webhook
Netcup	https://github.com/mrueg/external-dns-netcup-webhook
STACKIT	https://github.com/stackitcloud/external-dns-stackit-webhook

Status of in-tree providers

ExternalDNS supports multiple DNS providers which have been implemented by the ExternalDNS contributors. Maintaining all of those in a central repository is a challenge, which introduces lots of toil and potential risks.

This mean that external-dns has begun the process to move providers out of tree. See #4347 for more details. Those who are interested can create a webhook provider based on an in-tree provider and after submit a PR to reference it here.

We define the following stability levels for providers:

• Stable: Used for smoke tests before a release, used in production and maintainers are active.
• Beta: Community supported, well tested, but maintainers have no access to resources to execute integration tests on the real platform and/or are not using it in production.
• Alpha: Community provided with no support from the maintainers apart from reviewing PRs.

The following table clarifies the current status of the providers according to the aforementioned stability levels:

Provider	Status	Maintainers
Google Cloud DNS	Stable
AWS Route 53	Stable
AWS Cloud Map	Beta
Akamai Edge DNS	Beta
AzureDNS	Stable
BlueCat	Alpha	@seanmalloy @vinny-sabatini
Civo	Alpha	@alejandrojnm
CloudFlare	Beta
RcodeZero	Alpha
DigitalOcean	Alpha
DNSimple	Alpha
Infoblox	Alpha	@saileshgiri
Dyn	Alpha
OpenStack Designate	Alpha
PowerDNS	Alpha
CoreDNS	Alpha
Exoscale	Alpha
Oracle Cloud Infrastructure DNS	Alpha
Linode DNS	Alpha
RFC2136	Alpha
NS1	Alpha
TransIP	Alpha
VinylDNS	Alpha
RancherDNS	Alpha
OVH	Alpha
Scaleway DNS	Alpha	@Sh4d1
Vultr	Alpha
UltraDNS	Alpha
GoDaddy	Alpha
Gandi	Alpha	@packi
SafeDNS	Alpha	@assureddt
IBMCloud	Alpha	@hughhuangzh
TencentCloud	Alpha	@Hyzhou
Plural	Alpha	@michaeljguarino
Pi-hole	Alpha	@tinyzimmer

Kubernetes version compatibility

A breaking change was added in external-dns v0.10.0.

ExternalDNS	<= 0.9.x	>= 0.10.0
Kubernetes <= 1.18	✅	❌
Kubernetes >= 1.19 and <= 1.21	✅	✅
Kubernetes >= 1.22	❌	✅

Running ExternalDNS:

The are two ways of running ExternalDNS:

• Deploying to a Cluster
• Running Locally

Deploying to a Cluster

The following tutorials are provided:

• Akamai Edge DNS
• Alibaba Cloud
• AWS
  • AWS Load Balancer Controller
  • Route53
    • Same domain for public and private Route53 zones
  • Cloud Map
  • Kube Ingress AWS Controller
• Azure DNS
• Azure Private DNS
• Civo
• Cloudflare
• BlueCat
• CoreDNS
• DigitalOcean
• DNSimple
• Dyn
• Exoscale
• ExternalName Services
• Google Kubernetes Engine
  • Using Google's Default Ingress Controller
  • Using the Nginx Ingress Controller
• Headless Services
• Infoblox
• Istio Gateway Source
• Kubernetes Security Context
• Linode
• Nginx Ingress Controller
• NS1
• NS Record Creation with CRD Source
• MX Record Creation with CRD Source
• OpenStack Designate
• Oracle Cloud Infrastructure (OCI) DNS
• PowerDNS
• RcodeZero
• RancherDNS (RDNS)
• RFC2136
• TransIP
• VinylDNS
• OVH
• Scaleway
• Vultr
• UltraDNS
• GoDaddy
• Gandi
• SafeDNS
• IBM Cloud
• Nodes as source
• TencentCloud
• Plural
• Pi-hole

Running Locally

See the contributor guide for details on compiling from source.

Setup Steps

Next, run an application and expose it via a Kubernetes Service:

kubectl run nginx --image=nginx --port=80
kubectl expose pod nginx --port=80 --target-port=80 --type=LoadBalancer

Annotate the Service with your desired external DNS name. Make sure to change example.org to your domain.

kubectl annotate service nginx "external-dns.alpha.kubernetes.io/hostname=nginx.example.org."

Optionally, you can customize the TTL value of the resulting DNS record by using the external-dns.alpha.kubernetes.io/ttl annotation:

kubectl annotate service nginx "external-dns.alpha.kubernetes.io/ttl=10"

For more details on configuring TTL, see here.

Use the internal-hostname annotation to create DNS records with ClusterIP as the target.

kubectl annotate service nginx "external-dns.alpha.kubernetes.io/internal-hostname=nginx.internal.example.org."

If the service is not of type Loadbalancer you need the --publish-internal-services flag.

Locally run a single sync loop of ExternalDNS.

external-dns --txt-owner-id my-cluster-id --provider google --google-project example-project --source service --once --dry-run

This should output the DNS records it will modify to match the managed zone with the DNS records you desire. It also assumes you are running in the default namespace. See the FAQ for more information regarding namespaces.

Note: TXT records will have the my-cluster-id value embedded. Those are used to ensure that ExternalDNS is aware of the records it manages.

Once you're satisfied with the result, you can run ExternalDNS like you would run it in your cluster: as a control loop, and not in dry-run mode:

external-dns --txt-owner-id my-cluster-id --provider google --google-project example-project --source service

Check that ExternalDNS has created the desired DNS record for your Service and that it points to its load balancer's IP. Then try to resolve it:

dig +short nginx.example.org.
104.155.60.49

Now you can experiment and watch how ExternalDNS makes sure that your DNS records are configured as desired. Here are a couple of things you can try out:

• Change the desired hostname by modifying the Service's annotation.
• Recreate the Service and see that the DNS record will be updated to point to the new load balancer IP.
• Add another Service to create more DNS records.
• Remove Services to clean up your managed zone.

The tutorials section contains examples, including Ingress resources, and shows you how to set up ExternalDNS in different environments such as other cloud providers and alternative Ingress controllers.

Note

If using a txt registry and attempting to use a CNAME the --txt-prefix must be set to avoid conflicts. Changing --txt-prefix will result in lost ownership over previously created records.

If externalIPs list is defined for a LoadBalancer service, this list will be used instead of an assigned load balancer IP to create a DNS record. It's useful when you run bare metal Kubernetes clusters behind NAT or in a similar setup, where a load balancer IP differs from a public IP (e.g. with MetalLB).

Contributing

Are you interested in contributing to external-dns? We, the maintainers and community, would love your suggestions, contributions, and help! Also, the maintainers can be contacted at any time to learn more about how to get involved.

We also encourage ALL active community participants to act as if they are maintainers, even if you don't have "official" write permissions. This is a community effort, we are here to serve the Kubernetes community. If you have an active interest and you want to get involved, you have real power! Don't assume that the only people who can get things done around here are the "maintainers". We also would love to add more "official" maintainers, so show us what you can do!

The external-dns project is currently in need of maintainers for specific DNS providers. Ideally each provider would have at least two maintainers. It would be nice if the maintainers run the provider in production, but it is not strictly required. Provider listed here that do not have a maintainer listed are in need of assistance.

Read the contributing guidelines and have a look at the contributing docs to learn about building the project, the project structure, and the purpose of each package.

For an overview on how to write new Sources and Providers check out Sources and Providers.

Heritage

ExternalDNS is an effort to unify the following similar projects in order to bring the Kubernetes community an easy and predictable way of managing DNS records across cloud providers based on their Kubernetes resources:

• Kops' DNS Controller
• Zalando's Mate
• Molecule Software's route53-kubernetes

User Demo How-To Blogs and Examples

• A full demo on GKE Kubernetes. See How-to Kubernetes with DNS management (ssl-manager pre-req)
• Run external-dns on GKE with workload identity. See Kubernetes, ingress-nginx, cert-manager & external-dns
• ExternalDNS integration with Azure DNS using workload identity

external-dns's Issues

Add Kubernetes Nodes Source

Add a source that lists/watches for Node objects.

Add Google CloudDNS implementation

Add an implementation using Google CloudDNS.

Come up with an Interface for internal storage

We need some way of keeping track of what records external-dns is responsible for in order to:

• support running with already present legacy records
• allowing for easy migration to external-dns
• running multiple instances of external-dns concurrently

In mate we used co-located TXT records with a value identifying the instance of mate to keep track of it. This worked well but turned out to add some additional complexity. Maybe there's another way.

@justinsb mentioned keeping track of that data as annotations or via a ConfigMap. This wouldn't work with multiple clusters targetting the same zones, though.

Anyways, maybe we are able to come up with an interface/abstraction so we can make this storage configurable:

• back external-dns with a ConfigMap so that it can decide what records it has and which are legacy/manually created records (would not support concurrent instances across clusters, given there aren't any other restrictions)
• back it by using some storage in the dns-provider (TXT record, S3 bucket, separate etcd cluster 😮 , federated control plane's storage, what have you...) to support multiple instances of external-dns across different clusters.
• null-storage when you just don't care, i.e. every record is automatically under external-dns juristiction.

Read LB address from infrastructure-managed ressource

I'm opening this issue to find out if our use-case is supported.

We use ingress objects and nginx-ingress-controller to route external traffic coming from ALBs inside the cluster. Currently we have our own approach of updating route53 with the address of the ALB.
However we'd like to move to external-dns and have it update route53 with the address of the ALB, but without leaking the ALB-address into the application manifests.

Not sure how feasible that is. One solution could be to get the ALB-address from a TPR?

Repository Set up

• Makefile
• Code of Conduct
• CONTRIB.md
• Apache License

We just need most of these dropped in, we can always change them later.

Apply opensource best practices

Go through these resources and make sure external-dns is in good shape

• https://github.com/zalando/zalando-howto-open-source
• https://opensource.guide/

add a --version flag

That got lost somehow :) @ideahitme

create ALIAS records instead of CNAMEs on Route 53

relevant PR #144

Support custom TTLs

Especially for k8s services it would be good to be able to set a lower TTL than 300 seconds.
When one node goes down it could take up to five minutes to have an updated DNS.

EDIT
just realized that the load balancer's IP address is used so my argumentation is not valid. Nevertheless a custom TTL would still be a good idea ;)

k8s.io/client-go informer library

As suggested by @linki it might make sense to checkout the client-go informer library to fetch/watch the list of services/ingress resources. A pretty clean example can be found here:

https://github.com/wfarr/client-go/blob/577d1900c3ba12335dc1edb4a812c14a07effd73/examples/informer/main.go

It is currently used in main kuberentes repo and in few of the /contrib projects as well

About using bazel

During the meeting @justinsb had the idea of using bazel for building.

Let's discuss what the benefits are and how we can best tackle this.

Thanks!

Not really an issue at all. Just wanted to quickly say "Thanks" for the work you are doing. The project is shaping up nicely and with some of the 0.2 stuff I think we can start testing it out in some of our lower environments.

Add Kubernetes Services Source

Add a source that lists/watches for Service objects.

Project structure and file system layout

Proposal and brainstorm kickoff for the general project structure. This shouldn't be too technical but rather serve as a way to capture the components involved.

external-dns/
  cmd/external-dns/        <= place for external-dns binary
  producers/               <= place for producer implementations (kubernetes, fake, ...)
  consumers/               <= place for consumer implementations (route53, googledns, ...)
  controller/              <= place for orchestrator that connects producers and consumers
  plan/                    <= place for code related to the plan object
  util/                    <= place for commonly shared code
  vendor/                  <= place for vendored libraries (maybe wrong with bazel)

Questions

• Different naming for producers and consumers? e.g. sources and targets?

Clarify whether to use alpha annotations

I was wondering if we should rather use alpha annotations while external-dns is still unstable?

Looking at other projects I think it makes to target alpha.external-dns.kubernetes.io for now so that we allow us to change them at any time if we discover they aren't suitable. I know that we discussed the desired annotations for quite some time but you never know if they really works out.

Automatically build and push image

We have to setup a Pipeline that builds and pushes our docker image.

I would like to give Google's Container Builder a try: https://cloudplatform.googleblog.com/2017/03/Google-Cloud-Container-Builder-a-fast-and-flexible-way-to-package-your-software.html?m=1

Provide a way to specify the source

Currently external-dns is hard-coded to watch Services only. We should allow to watch Ingress as well. Here's one way:

• To keep the controller simple it should still take a single Source.
• Create a MultiSource object that implements Source and wraps other Sources
• One multi-source would the "Kubernetes" source which fans-out to Service and Ingress Source

Ingress Source should not gather ingresses with different controller annotation

Currently it's not possible to opt-out of being processed by external-dns.

Add detailed documentation how to use external-dns

• GCE
  • with type=LoadBalancer services
  • with GLBC ingress controller
  • with nginx-ingress-controller
  • with voyager ingress controller
  • with traefik ingress controller
• on AWS
  • with type=LoadBalancer services
  • with skipper-ingress-controller
  • with nginx-ingress-controller
  • with voyager ingress controller
  • with traefik ingress controller
• on Bare metal (no cloud load balancer)
  • with nginx-ingress-controller

Add Kubernetes CustomResourceDefinition Source

Add a source that lists/watches for a specific CustomResourceDefinition objects.

We could make a CRD the central source for DNS entries. And then just create those objects as needed. This would allow other components to declare DNS entries as well.

Add Kubernetes Ingresses Source

Add a source that lists/watches for Ingress objects.

Document design: features and annotations

First thing to do for this new Incubator project: create a design doc (docs/design folder as @justinsb proposed) with all planned features and the interface to the user (annotations and Ingress resource).

We can use the contents of the "External DNS" Google Doc as a start.

Expose metrics through Prometheus endpoint

A lot of kubernetes users use prometheus for monitoring their cluster. And, many core kubernetes components offer a /metrics endpoint. It might be useful to expose some info, even if it's just the basic go metrics that are provided by the go prometheus package.

Explorer integration with StackExchange's dnscontrol

https://github.com/StackExchange/dnscontrol looks interesting and may be worth integrating with external-dns.

Support DNS records for ingresses without rules

If my ingress does not contain any rules but only a default backend no records are created. It would be great to implement an alternative way to create records if no rules are set.
For example the way mentioned in #142 can be a solution here. As a result we have a consistent way to handle services and ingresses.
We can just use both ways at the same time (use the template AND create records for every rule if one exists) or just fallback to the template method from #142 if no rules are defined.
Maybe a more sophisticated opt in/out configuration using annotations could be useful.

Make every flag configurable via ENV vars

Be twelve-factor. Also allows to transparently inject env vars into pods and have them picked up in the future, e.g. with PodInjectionPolicies.

drone does a good job here

$ docker run drone/drone:0.5 server --help
OPTIONS:
   --debug							start the server in debug mode [$DRONE_DEBUG]
   --broker-debug						start the broker in debug mode [$DRONE_BROKER_DEBUG]
   --server-addr ":8000"					server address [$DRONE_SERVER_ADDR]
   --server-cert 						server ssl cert [$DRONE_SERVER_CERT]

GitHub repo description & topics

Just a reminder to hunt down some admin to fix the GitHub repo description. My proposal:

Configure external DNS servers (Route53, Cloud DNS and others) for Kubernetes ingress and services

I think the repo description should be meaningful and attract the main potential users (which are users of cloud providers right now as we have no other implementation at the start).

Add policy flag to control lifecycle behaviour of DNS records

Use a flag --policy flag to control how external-dns deals with the lifecycle of DNS records.

Possible values could be:

• create-only: only create records, don't update or delete
• update-only: only update existing records, never created nor delete anything else
• upsert-only: create and update records as needed, never remove records without replacement
• crud or sync: full authority over records, create, update and delete records as needed

/cc @ideahitme

The One with the Plan

Background

When developing mate we found out that one of the more difficult parts was calculating the diff from a current state to a desired state of dns records. In mate, this responsibility was part of each consumer implementation although many things could have been shared between consumers and it was difficult to test.

Glossary:

• producer: source of desired dns records
• consumer: adapter to the specific dns provider
• controller: glue between producers and consumers

Proposal

We propose an intermediate object that's used to capture the transition that's needed to go from a current to a desired state of dns recors in a dns-provider-independent way. This object would then be used as input to the consumers and the logic is not part of each of them.

Hence, making the consumer implementations easier to write (less responsibilities) and allowing the intermediate object to be easier to test (less external dependencies). I would like to call this object Plan as it's a sort of execution plan.

A plan would be constructed from two input lists:

• a desired list of records and a current list of records.

And it would return three lists as output:

• a list of records to create
• a list of records to update (including old and new records)
• a list of records to delete

This plan object can be tested in isolation and many combinations and edge cases can easily be added to the test suite.

The plan would then be passed to a consumer object which would "just execute" the actions according to the dns provider. This also makes each consumer easier to test as one just needs to provide a Plan and see that the consumer runs the right actions against the dns provider. Any errors that may happen (e.g. because of records to delete that don't exist) can be considered errors and don't need to be handled necessarily.

The flow would be the following:

• controller asks producer to return a list of desired dns records
• controller asks consumer for the current list of dns records
• controller passes list from producer (desired) and list from consumer (current) to plan calculator and retrieves a Plan
• controller passes Plan to consumer for execution

We chose to represent the necessary actions as three lists as it seems to be the most compatible way of defining it between dns providers. For instance, AWS Route53 doesn't differentiate between creates and updates so it could just merge them into an upsert list before processing. On the other hand, Google CloudDNS doesn't support updates natively and one would have to convert the updates list to a combination of delete+create first. Other consumers will be different but we think those three lists capture all the information they would require.

Inspired by work we had planned for mate: linki/mate#46

Contribution guideline

Improve contribution guideline docs. Should include manual regarding createing PRs, PR labelling, updating Changelog.

Add Fake Source

Add a source that generates fake values (for testing).

CloudFlare as a new provider

Add AWS Route53 implementation

Add an implementation using AWS Route53

Set up Travis CI

We should setup travis at some point. This should include various tests.

AFAIK standard way of doing it for k8s related projects is to include some of the bash/python scripts from https://github.com/kubernetes/kubernetes/tree/master/hack. It provides a way to test if the boilerplate is set correctly for all relevant files (license agreement on top of the file) + all go tools verifications (vet, fmt, lint etc) + unit/integration/e2e tests

Basically after we include all of the above everything can be run with slightly modified version of https://github.com/kubernetes/kubernetes/blob/master/hack/verify-all.sh

Opening this issue for now and we can add all of this once actual development starts :)

Increase logging output

external-dns currently doesn't log anything if it's not running in dry-run mode. Change that!

Setup basic integration test on GCP

I'll try to setup a basic integration test for Services on Google Cloud Platform.

This will run in its own Google project, gets a valid DNS name, spins up a cluster running external-dns inside. At some point we may be able to run it wherever CNCF runs the Kubernetes integration tests?

Run on kube?

Hey, is there a way to run this as a sidecar / recurring job in kube itself?

Add a dry-run flag

Very useful for the DNS provider side. Just display what would have been done. This is not intended to replace the fake DNS provider but rather to run a provider safely.

Add a way to provide external-dns with a template to generate service FQDNs

It'll be great to have the possibility to provide external-dns with a template string like {{.Namespace}}-{{.Name}}.example.com to generate DNS records instead of using the annotation in the service.
Using this template one can manage multiple zones which contains all services without altering the annotation for each service. Also; as far as I understand; currently one service can only map to exactly one FQDN.
Using the templating I can launch one external-dns instance per zone without messing around with my kubernetes service definition.
zalando-mate supports this using --kubernetes-format which was a great fit for our use case.

Investigate dnsprovider from kubernetes

Afaik kops-dns-controller is using Kuberentes dnsprovider lib - https://github.com/kubernetes/kubernetes/tree/master/federation/pkg/dnsprovider
It probably makes sense to investigate if we should consider using the library to keep us in sync with kubernetes main repository and help us speed up the development. If we find it to be unusable or a blocker we could consider implementing our own dnsprovider, like we did in Mate.

/cc @linki @justinsb

Add integration tests

We entirely skipped integration tests for mate. Let's not make the same mistake again.

#65

Create a Helm chart for external-dns

We should create a chart as soon as we have a suitable version.

Handle records pointing to multiple IP addresses

If setting up A records with multiple target IPs on GCP external-dns is unable to remove them and fails.

Also required to support services with type=NodePort

consider changing controller annotation's value to "external-dns"

By annotating the controller by which objects should be processed, the user can opt-in and out from being processed by external-dns.

external-dns.alpha.kubernetes.io/controller: mate

However, this controller's identifer was defined to be dns-controller but I think it makes more sense to use the name of this project, external-dns. Meaning, not annotating or annotating a resource with external-dns will allow to opt-in.

external-dns.alpha.kubernetes.io/controller: external-dns

Currently, you would have to use

external-dns.alpha.kubernetes.io/controller: dns-controller

CoreDNS as a DNS provider

CoreDNS is an alternative for on-prem deployments where google/aws are not available. It has some support as a Federation DNS backend now: https://github.com/kubernetes/kubernetes/blob/master/federation/pkg/dnsprovider/providers/coredns/coredns.go

Can it be added as a valid external DNS source as well?

Requirements for initial usable version

Late braindump, take with a grain of salt.

In- and out-of-scope for marking the first "working" version (time frame: before KubeCon)

• basic sync loop
  • watch can be done later
• support for Service and Ingress hostnames
  • Node can come later
• support for simple new annotations
  • i.e. hostname + controller
  • legacy + more advanced can come later
• single cluster, single zone support
  • zone auto-detection can come later
  • multi-cluster single-zone conflicts out of scope
• support for tolerating conflicting records in target zone
  • i.e. do not mess with existing legacy records in zone
  • leads to: basic ownership model must exist, has to work across pod restarts
• CNAME record support for Route53
  • A should be easy to add but probably not needed
  • ALIAS out of scope if too difficult
• A record support Google CloudDNS
  • CNAME easy but probably not needed
• Good unit test coverage
  • basic integration test would be great, though

@ideahitme @justinsb @iterion let me know if you agree or want to add/remove stuff.

Single broken entity breaks the whole batch

If a single dns record cannot be created, e.g. when a desired DNS name doesn't match the managed zone it will fail and the whole batch will be rolled back. We should tolerate individual records failing.

Annotations strategy

We'll support several annotations from the beginning, some of them are supposed to be deprecated soon, others will be added over time as new requirements come up.

@justinsb throw in an idea where we store JSON as the value of an annotation which can then be used to encode more complicated data in order to support more advanced but less common use cases.

We could design our annotations around a single annotation holding JSON. This would be the source of truth for our controller. Keys can be added over time to support new features (CNAME, TTL, provider specific stuff). Though, normally one would use the simpler annotations using plain text values (e.g. external-dns/hostname: foo) but internally external-dns would convert the simpler annotations to the source-of-truth-struct before processing.

This way, most users could just use the simple annotations that are exposed but more adavanced users could directly set the JSON based annotation to have access to everything that external-dns provides.

This can also help with solving backwards-incopatible changes and with rolling out new versions. New features could be made available solely via some keys in the JSON before being promoted to top-level annotations if they prove to be useful.

@justinsb @ideahitme @iterion Any thoughs?

Incubator process stuff

Please put the following in the README:

• Who is the champion?
• Who is the sponsor?
• Link to the kubernetes-dev announcement

Example: https://github.com/kubernetes-incubator/service-catalog#kubernetes-incubator

cc @calebamiles

Add a ROADMAP

TL;DR add a ROADMAP file

Our first release won't be the fully usable thing we intend to achieve (and need for ourselves). However, we want to release early and not wait until everything is perfectly done.

Users visiting the project after the first release should have a clear understanding where the project is right now and what and in which order they can expect certain things.