search

kubernetes-sigs / external-dns

Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services
Apache License 2.0
7.69k stars 2.56k forks source link

Heritage TXT records are not generated in case of CNAME #1827

Closed wgebis closed 3 years ago

wgebis commented 4 years ago

What happened:

Heritage TXT records are not generated in case of CNAME, so after then the ingress is removed, DNS CNAMEs still persist. For A records it works.

What you expected to happen:

Every records A and CNAME should be tracked via TXT to avoid mess in DNS zone.

How to reproduce it (as minimally and precisely as possible):

Add annotation external-dns.alpha.kubernetes.io/target = "hostname.com" to ingress objects and when observe results in DNS zone. When I put external-dns.alpha.kubernetes.io/target = "1.2.3.4" it will produce A record with expected TXT heritage.

Anything else we need to know?:

Environment:

jgrumboe commented 4 years ago

Are you using the --txt-prefix or --txt-suffix option as described in https://github.com/kubernetes-sigs/external-dns/blob/master/docs/faq.md#im-using-an-elb-with-txt-registry-but-the-cname-record-clashes-with-the-txt-record-how-to-avoid-this ?

wgebis commented 4 years ago

I have tried using prefixes/suffixes with no success.

l0wl3vel commented 3 years ago

https://tools.ietf.org/html/rfc1034 says in 3.6.2:

If a CNAME RR is present at a node, no other data should be present

So not creating a TXT record for a CNAME is the correct behavior

hansbogert commented 3 years ago

@l0wl3vel This is exactly what bind is doing and warning about in my case with rfc2136

updating zone 'x/IN': adding an RR at 'openhab.x' CNAME dd.home.x.
 named[28754]: client @0x7f01dc0e42f0 163.158.131.235#27534/key kubernetes.dd.home.x: updating zone 'x/IN': attempt to add non-CNAME alongside CNAME ignored
named[28754]: zone x/IN: sending notifies (serial 2013080790)

so what should be the correct behaviour for external-dns in this case?

/update nvm me, prefix seems to fix this in my case.

wgebis commented 3 years ago

Hi there! @hansbogert @l0wl3vel in short: external-dns should creates TXT records as well as for A records and manage them as well.

Let me know if it makes sense: I believe that external-dns creates the TXT records just for tracking the ownership of them in DNS zone in order to manage these records. It works perfectly with A records, but don't work with CNAME. I'm pretty sure that it has to in terms of CNAMEs. Without that additional tracking records, external-dns will not able to handle e.g. deletion of the records fro DNS. So "heritage" TXT records are not the part of any standards pointing to RFCs, IETF's docs etc. it's just external-dns specific implementation for dealing with the management of the DNS zone.

jgrumboe commented 3 years ago

You're all are right in my opinion. External-dns should create TXT records to manage the ownership of A and CNAME records it manages. This feature is configured via --txt-owner-id and --txt-prefix/--txt-suffix. I one does not set --txt-prefix/--txt-suffix external-dns will run into a problem especially for CNAME records because of the RFC: you cannot create any other record with the same name as an already existing CNAME record.

@wgebis For further debugging your problem it would be great if you can share your config, cmdline arguments and a log output where every record creation (or not) should be in.

wgebis commented 3 years ago

Ye, you can find my config below"

image = "k8s.gcr.io/external-dns/external-dns:v0.7.4"
          args = [
            "--source=ingress",
            "--source=service",
            "--domain-filter=my_domain",
            "--provider=digitalocean",
            "--log-level=debug",
            "--events"
jgrumboe commented 3 years ago

So you didn't set --txt-owner-id and one of --txt-prefix or --txt-suffix?

wgebis commented 3 years ago

Nope, TXT for A are created/deleted with that config.

jgrumboe commented 3 years ago

🤔 strange ... would need to look into the code. The "right" way would be to choose a --txt-owner-id and one of --txt-prefix or --txt-suffix. Please try to set both.

Update: I see ... "txt-owner-id" defaults to "default" if nothing is set explicitly.

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

atmosx commented 3 years ago

Bumping, my config (terraform):

  do_args = ["--source=ingress",
    "--source=service",
    "--policy=sync",
    "--domain-filter=${var.cluster_zone}",
    "--registry=txt",
    "--txt-owner-id=MANAGED_BY_EXTERNAL_DNS_${var.cluster_environment}",
    "--provider=${var.dns_provider}"] # it is set to digitalocean

docker image image: k8s.gcr.io/external-dns/external-dns:v0.7.6, we're using CNAMEs, I see no TXT records.

fejta-bot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

jgrumboe commented 3 years ago

@atmosx CNAMEs cannot co-exist with other records for the same hostname. Therefore the usage of --txt-prefix or --txt-suffix is mandatory.

jgrumboe commented 3 years ago

/remove-lifecycle rotten

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

k8s-triage-robot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

k8s-triage-robot commented 3 years ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

k8s-ci-robot commented 3 years ago

@k8s-triage-robot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/external-dns/issues/1827#issuecomment-910564004): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues and PRs according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue or PR with `/reopen` >- Mark this issue or PR as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.