Config knob to enable/disable dns packet redirection

[vishnoianil]

Istio does not enable dns redirection by default.
This PR provides an option to explicitly enable/disable
DNS redirection related eBPF programs. User need to
edit the merbridge daemonset and modify --dns-redir to true
to enable the dns redirection.

Signed-off-by: Anil Kumar Vishnoi vishnoianil@gmail.com

[mergify]

Welcome to the Merbridge OpenSource Community!👏

We're delighted to have you onboard 💘

[kebe7jun]

Right now we are actually automatically recognizing when and only when the DNS_CAPTURE_PORT port is being listened to, and doing the redirect.
Of course, there's nothing wrong with what you've added, but maybe I think we need an "auto-detect" mode.
Instead, we will use DNS_CAPTURE_PORT detection only when working in "auto-detect" mode, other modes may not need this step.

[vishnoianil]

@kebe7jun If I understood your comment correctly, you are suggesting that user should not have to set --dns-redir=true if they want to enable the dns redirection and merbridge should determine it at the load time and than internally just set it to --dns-redir=true/false ( or just define the macro's)?

[kebe7jun]

@kebe7jun If I understood your comment correctly, you are suggesting that user should not have to set --dns-redir=true if they want to enable the dns redirection and merbridge should determine it at the load time and than internally just set it to --dns-redir=true/false ( or just define the macro's)?

I think there are three possible scenarios.

1. the "auto-detect" mode (default), in which we automatically determine, via bpf_lookup, that DNS redirection is performed whenever a port listener exists.
2. "DISABLED" mode, in which we do not handle UDP requests directly.
3. "ENABLED" mode, in which we completely redirect DNS requests without port detection to ensure better performance.

What do you think?

/cc @dddddai

[dddddai]

3. "ENABLED" mode, in which we completely redirect DNS requests without port detection to ensure better performance.

I'm not sure if it's worthy to remove the detection completely for performance, which is a little bit risky I think

We should use auto-detection by default, for users who don't use DNS proxying and want the best performance, they could turn it off

[vishnoianil]

I think the only concern I see with the auto-detect mode is that mb_sendmsg4 will make two lookup call (for OUT_REDIRECT_PORT & DNS_CAPTURE_PORT) for every dns request message it will receive, and in large scale cluster number of dns requests can be significant. Even in my small setup of 3 master/ 3 worker with only fortio pods, i see that the sendmsg/recvmsg counter keep increasing.

[vishnoianil]

3. "ENABLED" mode, in which we completely redirect DNS requests without port detection to ensure better performance.

I'm not sure if it's worthy to remove the detection completely for performance, which is a little bit risky I think

We should use auto-detection by default, for users who don't use DNS proxying and want the best performance, they could turn it off

Yes, I think this makes sense. We can keep the auto-detection on by default and if user don't want to use it, disable it at the time of merbridge deployment. And if it's disable, dns redirection will still works anyways because of the iptables. The only concern with keeping auto-detection by default on is that in large scale cluster where you can have significant number of dns requests, it might cause performance issues for redirection of other traffic.

[vishnoianil]

@kebe7jun @dddddai
I just pushed another commit, where i enable dns-redir by default. And if user wants to disable it they can set --dns-redir=false.

Apart from that, I am wondering if we can use cni-mode to filter the packet in sendmsg/recvmsg coming from istio injected pod, rather than doing a lookup for OUT_REDIRECT_PORT. I am hoping that will reduce significant number of lookups, and probably give us better performance. Just guessing at this point, but would like your suggestion on it. I will test some of these scenario locally to see if it helps.

[dddddai]

Apart from that, I am wondering if we can use cni-mode to filter the packet in sendmsg/recvmsg coming from istio injected pod, rather than doing a lookup for OUT_REDIRECT_PORT.

I don't see solutions without lookup for now, feel free to comment if you have any ideas :)

BTW cni-mode is currently alpha, we are still working on it to make it more robust

[kebe7jun]

Apart from that, I am wondering if we can use cni-mode to filter the packet in sendmsg/recvmsg coming from istio injected pod, rather than doing a lookup for OUT_REDIRECT_PORT

Sounds like a good idea, it means that we use the CNI to determine if the current Pod needs to have DNS forwarding enabled.

In fact, I think we could put the need for DNS forwarding into pod_info, so that we can check directly based on MAP.

@vishnoianil is very concerned about the performance of lookup_sock.

[vishnoianil]

ut the need for DNS forwardin

That sounds like a good options. Although in upstream Istio, DNS redirction is global configuration, but there are some Istio based service mesh distribution that support dns redirection per namespace. So having this configuration in pod_info can cover those scenarios as well. I will look into it and push a patch.

[mergify]

Welcome to the Merbridge OpenSource Community!👏

We're delighted to have you onboard 💘