Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

external-dns creates DNS entries for sub-domains even if exclude-domains filter is set #1137

Closed
wndhydrnt opened this issue Aug 9, 2019 · 3 comments · Fixed by #1442
Closed

Comments

@wndhydrnt
Copy link

In our current setup, external-dns tries to create DNS entries for sub-domains even if --domain-filter and --exclude-domains are set.
We are running a Kubernetes cluster in an AWS account.
The cluster serves requests arriving at multiple Route53 Hosted Zone.
The Hosted Zones are in the same AWS account as the Kubernetes cluster. Applications in the Kubernetes clusters can receive traffic via a sub-domain and on the Apex domain.
It looks like this:

foo.cluster1.example.com --> k8s cluster1
foo.example.com --> k8s cluster1

We use the external-dns Kubernetes Ingress source to create domains for an application running on Kubernetes.
Sample output of kubectl get ingress:

NAME                            HOSTS                                       ADDRESS   PORTS   AGE
foo-ingress1                    foo.cluster1.example.com                              80       1d
foo-ingress2                    foo.example.com                                       80       1d

We start multiple external-dns processes, one for each Hosted Zone where DNS entries should be created (other options omitted for brevity):
1: external-dns --domain-filter=cluster1.example.com
2: external-dns --domain-filter=example.com --exclude-domains=cluster1.example.com
Process "1" does exactly what it is supposed to, creating records in the Hosted Zone cluster1.example.com only.
Process "2" however tries to create DNS entries for example.com and cluster1.example.com:

{"level":"info","msg":"Desired change: CREATE foo.cluster1.example.com A","time":"2019-08-09T11:19:47+02:00"}
{"level":"info","msg":"Desired change: CREATE _test_foo.cluster1.example.com TXT","time":"2019-08-09T11:19:47+02:00"}

I would have expect it to ignore all domains containing cluster1.example.com.
We are not sure if this is a feature request or if external-dns can be set up in a different way to achieve what we are looking for. Please advice.

@wndhydrnt
Copy link
Author

After reading through the code and doing additional tests, it looks like the --domain-filter and --exclude-domains only apply to the provider to find the zone(s) where records can be created.
external-dns does not check if the incoming domains from a source, e.g. an ingress, match with the zone(s) where records can be created.
This leaves me with the following questions:

  • Should the filter logic be applied to records read from a source?
  • Should such logic be implemented on a per-provider basis or globally?

@wndhydrnt
Copy link
Author

Hello @linki @njuettner
this issue is still bugging us. We would be willing to contribute the functionality, but are hesitant to put in the work without some feedback by the maintainers (see my two questions in my previous comment).
Does this sound like a useful addition to external-dns?

@mariusmarais
Copy link

mariusmarais commented Dec 18, 2019

Running into the same issue. We run 4x external-dns deployments in our production cluster so that we can access Route53 in four different AWS accounts using --aws-assume-role, which is working nicely.

However, one account maintains the abcxyz.net root, while another has cluster.abcxyz.net with an NS delegation from the root.

We're not using --domain-filter, but only --exclude-domains=cluster.abcxyz.net on the root instance and it's not working as we expected it to.

Our intention is to have external-dns process all requests, except the ones being excluded, which is not happening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants