'Nodes' source assumes all discovered IPs are IPv4

[danopia]

What would you like to be added:

The node.go source only knows how to make A endpoints: https://github.com/kubernetes-sigs/external-dns/blob/master/source/node.go#L129

The source should be extended to recognize IPv6 addresses and add them as AAAA endpoints instead of A.

I looked at providing a refactor but struggled to handle the code as-written, it wants to only think about one type of endpoint. This is the basic gist of the tests that should pass:

		{
			"node with both IPv4 and IPv6 addresses results in both A and AAAA records",
			"",
			"",
			"node1",
			[]v1.NodeAddress{{Type: v1.NodeInternalIP, Address: "2.3.4.5"}, {Type: v1.NodeInternalIP, Address: "2::5"}},
			map[string]string{},
			map[string]string{},
			[]*endpoint.Endpoint{
				{RecordType: "A", DNSName: "node1", Targets: endpoint.Targets{"2.3.4.5"}},
				{RecordType: "AAAA", DNSName: "node1", Targets: endpoint.Targets{"2::5"}},
			},
			false,
		},
		{
			"node with only IPv6 addresses results in only AAAA records",
			"",
			"",
			"node1",
			[]v1.NodeAddress{{Type: v1.NodeInternalIP, Address: "1::1"}, {Type: v1.NodeInternalIP, Address: "2::5"}},
			map[string]string{},
			map[string]string{},
			[]*endpoint.Endpoint{
				{RecordType: "AAAA", DNSName: "node1", Targets: endpoint.Targets{"1::1", "2::5"}},
			},
			false,
		},

Why is this needed:

I have geographically diverse nodes and external-dns's nodes source made for a pretty sweet Kubernetes-native dynamic DNS solution. Unfortunately I found a limit when I added a dual-stack node. (Even more important because the relevant ISP rotates the customer's IPv6 prefix every few days)

time="2020-11-28T21:08:34Z" level=info msg="Change zone: myzone batch #0"
time="2020-11-28T21:08:34Z" level=info msg="Del records: chicago.my.zone. A [8.8.8.8] 300"
time="2020-11-28T21:08:34Z" level=info msg="Del records: chicago.my.zone. TXT [\"heritage=external-dns,external-dns/owner=nodes-usc1f\"] 300"
time="2020-11-28T21:08:34Z" level=info msg="Add records: chicago.my.zone. A [8.8.8.8 2001::1] 300"
time="2020-11-28T21:08:34Z" level=info msg="Add records: chicago.my.zone. TXT [\"heritage=external-dns,external-dns/owner=nodes-usc1f\"] 300"
time="2020-11-28T21:08:34Z" level=error msg="googleapi: Error 400: Invalid value for 'entity.change.additions[0].rrdata[1]': '2001::1', invalid"

[danopia]

Well, I wrote my intended sloppy patch on node.go (linked in above activity) and it satisfies my test cases but apparently external-dns has larger issues with IPv6 preparedness:

1. AAAA just isn't planned by default... https://github.com/kubernetes-sigs/external-dns/blob/master/plan/plan.go#L245
2. When planning multiple endpoints for one dns name; the planner just takes the "less" endpoint and rolls with it

So I suppose this is somewhat blocked on overall AAAA support in external-dns. I tried also patching AAAA into the plannable record passlist and now IPv6-only nodes work correctly keep re-adding the AAAA over and over, while dual-stack ones simply pick one family to use.

Also, related, another source that hardcodes A: #1812

[fejta-bot]

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

[unixfox]

/remove-lifecycle stale

[fejta-bot]

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

[morremeyer]

/lifecycle frozen

this is part of the IPv6 efforts and should therefore not be autoclosed.

[samip5]

Could this get some more traction as the IPv6 support in Kubernetes is moving to stable in the next release?

[djh00t]

Is there any news on this feature?