Closed de1m closed 4 years ago
What happens if you update the record? From what I've seen in the code it deletes the record and add's a new one. Does this work?
I just wanna narrow down the issue.
So, I've created the ingress (like above) then I've saw, that the cname record was created (k8s-exmp-2.aditocloud.de). After this I changed the Ingress and apply the changes. The external-dns created a second record with "k8s-exmp-3.aditocloud.de". My external-dns docker image is "bitnami/external-dns:0.5.10" and I've testet also "registry.opensource.zalan.do/teapot/external-dns:latest"
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-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
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-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
/remove-lifecycle rotten
~We also have this issue, we were using the powerdns provider and want to change for the RFC2136 one, but this issue is a show stopper.~
We were missing the EXTERNAL_DNS_RFC2136_TSIG_AXFR=true
environment variable in external-dns. Now it works perfectly.
We are also experiencing this issue. We're trying to integrate with Active Directory DNS, which doesn't support TSIG, so enabling it isn't an option for us. I have tried it with a variety of variations of the TSIG parameters as suggested here and elsewhere, but it doesn't seem to matter.
Here's the parameters to the container:
- args:
- --log-level=info
- --policy=sync
- --provider=rfc2136
- --registry=txt
- --interval=1m
- --source=service
- --source=ingress
- --rfc2136-host=ad.example.com
- --rfc2136-port=53
- --rfc2136-zone=k8stmp.example.com
- --rfc2136-insecure
I do not see anything in the container's logs indicating it trying to delete records:
[~]$ kl external-dns-58c6d9fbf-plk8g | grep '\.k8stmp'
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 A 10.128.26.119"
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 A 10.128.26.120"
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 A 10.128.26.121"
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 A 10.142.67.252"
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 A 10.142.67.253"
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 A 10.142.67.254"
time="2019-08-28T21:26:52Z" level=info msg="Adding RR: tst-zbx.k8stmp.example.com 0 TXT \"heritage=external-dns,external-dns/owner=default,external-dns/resource=ingress/zabbix/tst-zbx\""
Here's the startup message:
time="2019-08-28T21:15:50Z" level=info msg="config: {Master: KubeConfig: RequestTimeout:30s IstioIngressGatewayServices:[istio-system/istio-ingressgateway] ContourLoadBalancerService:heptio-contour/contour Sources:[service ingress] Namespace: AnnotationFilter: FQDNTemplate: CombineFQDNAndAnnotation:false IgnoreHostnameAnnotation:false Compatibility: PublishInternal:false PublishHostIP:false ConnectorSourceServer:localhost:8080 Provider:rfc2136 GoogleProject: DomainFilter:[] ExcludeDomains:[] ZoneIDFilter:[] AlibabaCloudConfigFile:/etc/kubernetes/alibaba-cloud.json AlibabaCloudZoneType: AWSZoneType: AWSZoneTagFilter:[] AWSAssumeRole: AWSBatchChangeSize:1000 AWSBatchChangeInterval:1s AWSEvaluateTargetHealth:true AWSAPIRetries:3 AWSPreferCNAME:false AzureConfigFile:/etc/kubernetes/azure.json AzureResourceGroup: CloudflareProxied:false CloudflareZonesPerPage:50 CoreDNSPrefix:/skydns/ RcodezeroTXTEncrypt:false InfobloxGridHost: InfobloxWapiPort:443 InfobloxWapiUsername:admin InfobloxWapiPassword: InfobloxWapiVersion:2.3.1 InfobloxSSLVerify:true InfobloxView: InfobloxMaxResults:0 DynCustomerName: DynUsername: DynPassword: DynMinTTLSeconds:0 OCIConfigFile:/etc/kubernetes/oci.yaml InMemoryZones:[] PDNSServer:http://localhost:8081 PDNSAPIKey: PDNSTLSEnabled:false TLSCA: TLSClientCert: TLSClientCertKey: Policy:sync Registry:txt TXTOwnerID:default TXTPrefix: Interval:1m0s Once:false DryRun:false LogFormat:text MetricsAddress::7979 LogLevel:info TXTCacheInterval:0s ExoscaleEndpoint:https://api.exoscale.ch/dns ExoscaleAPIKey: ExoscaleAPISecret: CRDSourceAPIVersion:externaldns.k8s.io/v1alpha1 CRDSourceKind:DNSEndpoint ServiceTypeFilter:[] CFAPIEndpoint: CFUsername: CFPassword: RFC2136Host:ad.example.com RFC2136Port:53 RFC2136Zone:k8stmp.example.com RFC2136Insecure:true RFC2136TSIGKeyName: RFC2136TSIGSecret: RFC2136TSIGSecretAlg: RFC2136TAXFR:false NS1Endpoint: NS1IgnoreSSL:false TransIPAccountName: TransIPPrivateKeyFile:}"
Could you run it with --log-level=debug
and check the additional logs. Specifically look for the DESIRED CHANGE
log lines.
I've set --log-level=debug
but am not seeing any DESIRED CHANGE
lines.
[~]$ kl external-dns-84b68dfc58-vfq2l | grep 'DESIRED CHANGE'
[~]$
@bjschafer I had the same issue. I've added the --rfc2136-tsig-axfr
flag and it seems to be deleting the entries correctly now. I think the issue is that axfr is turned on by default if you're using tsig security but if you're not you need to explicitly turn it on.
Update
The deletion works if you're using A records. If you use a CNAME via external-dns.alpha.kubernetes.io/target
it will never work. This is because if you have a CNAME you can't have any other data (including TXT records). I believe that because of this external-dns doesn't believe it has ownership of the record and so won't clean it up afterwards.
@dbason good call on --rfc2136-tsig-axfr
- that does indeed allow deletion. We're not currently using CNAMEs (nor do we plan to), so I think this works for us. Thanks a ton!
The only issue remaining is how to restrict zone transfers on the Windows DNS side, since external-dns isn't actually a DNS server (the MMC snapin doesn't like it, anyways). But that's neither here nor there :)
I think I'll try and update the RFC2136 documentation to clarify some of what we've learned and send in a PR.
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-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
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-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
I've found the issue #442, but I get the same error. My external-dns deploy:
Ingress example:
The external-dns create the dns record
but not delete this after deleting the ingress.
Can me help someone?
Ps: I use the BIND DNS 9