External-dns: External-dns fails to extract targets for SRV records on Azure

Created on 22 Jan 2020  路  15Comments  路  Source: kubernetes-sigs/external-dns

With SRV DNS records in our public Azure DNS zone, External-DNS logs the following error for each SRV record in the zone, every minute:

time="2020-01-22T19:58:04Z" level=error msg="Failed to extract targets for 'bbb.sub.domain.com' with type 'SRV'." time="2020-01-22T19:58:04Z" level=error msg="Failed to extract targets for 'aaa.sub.domain.com' with type 'SRV'."

This error is thrown on line #202 of the Azure provider because the list of targets for SRV records comes back empty.

The list of targets for SRV records is empty because the function that extract targets does not check for SRV record properties, so the default empty list is returned.

Relates to closed issue (closed because of inactivity) https://github.com/kubernetes-sigs/external-dns/issues/923

I've already forked the repo and I'll check if I can contribute a fix.

kinfeature provideazure

Most helpful comment

Same issue here but with NS...

time="2020-12-17T19:50:38Z" level=error msg="Failed to extract targets for '<my>.<domain>.<tld>' with type 'NS'."

All 15 comments

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.

In response to this:

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/reopen
/remove-lifecycle rotten

@aleveille: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle rotten

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Is there anything I can do to help review & approve the PR? I believe this is an interesting QoL improvement (it prevents thousands of error messages for us).

/assign njuettner

The same is true for CNAME records which are created as an Azure Service Alias (e.g. for CDN)

/kind feature

/unassign njuettner

@seanmalloy No pressure, but were you able to look at the new PR? Is there anything I can do to help you in your review? :)

Same issue here but with NS...

time="2020-12-17T19:50:38Z" level=error msg="Failed to extract targets for '<my>.<domain>.<tld>' with type 'NS'."

I have https://github.com/kubernetes-sigs/external-dns/pull/1864 for NS which is a superset of #1811.

Also getting spammed with NS error messages, would love to see these PRs merged 馃憤

Was this page helpful?
0 / 5 - 0 ratings