Costin Manolache

I am a bit more nuanced on this. Strong -1 on the entire feature set getting promoted to stable or default. However a subset of the feature - that is...

ServiceEntry can be used to program a "real" DNS resolver too - external-dns does it for Services/Ingress/Gateway, plenty of tools to automate that and it can be done as an...

Not so much kube dns as all 'enterprise' or 'managed' resolvers - I don't know if kube dns is checking dns-sec signatures and last I checked the DOT support was...

@ramaraochavali - I generally agree. We MUST have the base DNS capture for environments lacking a secure resolver, and we must return DNS for service for VMs or cases where...

Few comments: enabling this feature can have very serious security implications, as there is very little control on how DNS is generated. Having it on by default is IMO out...

DNS capture using ServiceEntry IPs. From what I've seen it can't take over Service IPs - but not at all clear about external IPs. It is effectively a way to...

Istioctl install is using the same config as operator. Which is a kind of CRD that is not applied or reconciled.

I would add that with all refactorings and with ambient behaving in different way leaves an unknown part of the install API in an undeterministic state.

Not sure what is best behavior if user attempts to make a request to an unknown destination. If it was not .cluster.local we would do a passthrough with DNS resolution....

I think 'capture' and 'redirection' are a property of the low-level network and CNI layer. Istio-cni already define some annotations - which we should probably move to a CRD and...