Ivan Ka

There is a long-standing achitectural gap: accurate differentiation of apex roots independent of provider or zone nesting I see a risk in the proposed APEX check. The rootApexDetector implementation operates...

The PR reduces risk of creating invalid apex TXT records, but it can’t guarantee correctness across all DNS topologies and providers. Golang standart libraries do not provide any ways to...

From my perspective apex detection requires policy, not just data. There’s no single, universally correct way to define a “root apex domain”, as a result, there is no support in...

I see quite few cases in a way implementation is proposed. And there are reasons, to my understanding, why this is an issue for quite a while. Let me explain,...

We could try `--apex-domains` for sure. It will work accross all providers, those with multiple apex domains will struggle. I’m not sure there’s a silver bullet here.

Could you share similar results for this [PR #5085 (comment)](https://github.com/kubernetes-sigs/external-dns/pull/5085#issuecomment-2651003555). Need to make sure it works.

/ok-to-test

I'm not too sure actually about this PR. Extnernal-dns and AWS supports NAPTR records https://github.com/kubernetes-sigs/external-dns/issues/5003 On hold as missing evidences that currently not working. /hold

I dig a bit more in details of issue 5003. Current PR in description does not match the problem explained in the issue. So this need to be addressed first.

I’m not denying the issue. What’s mainly missing are the configuration manifests and steps to easily reproduce it, along with evidence that the fix actually works. It’s not that I...