I am running an edge router on Amazon Linux and seeing following warning in the log. What can I do to fix it OR it can be ignored?
[ 0.146] WARNING edge/tunnel/dns.flushDnsCaches: {error=[exec: “systemd-resolve”: executable file not found in $PATH]} unable to find systemd-resolve in path, consider adding a dns flush to your restart process
Do router or tunneler require systemd-resolved installed?
You can ignore it if you use IPs only for your Ziti services.Otherwise you will need to configure dns forwarder to use the tunnel internal resolver for Ziti Service destinations.
In the past when I installed tunneler on RHEL , I could make it work by installing systemd-resolved, but I am getting this warning even after installing that on Amazon Linux.
To be honest, from what I’ve seen to date, generally, people are not using an edge-router to intercept traffic. Often you can just ignore this warning entirely. Are you trying to use the edge-router to actively intercept your own private DNS names? If not - I’d say just ignore it since it’s not a feature you’re needing.
I was expanding on my answer as I worried it wasn’t detailed enough…
Yes. If you’re relying on ziti-edge-tunnel, Ziti Desktop/Mobile Edge’s (windows/android/ios/macos) for onboarding - I would expect you can ignore this error entirely on the router. But the linux machine would need systemd-resolved for DNS intercepts to work properly…
If a process/user is on that machine and is trying to access “my.private.dns.name.ziti” (notice that it’s not a proper TLD), and if you expect that to be automatically resolved (like how the edge-tunnelers work) you’ll have a problem without fixing this issue. For that to work you’ll need to have a DNS forwarder like Dariusz said…
If you are using the edge-router only as the onramp to the OpenZiti Fabric Network (which is how I use it, and how most deployments I’ve seen do it), and you’re not planning on having processes on the local machine automatically resolve OpenZiti DNS intercepts, it’s totally just a warning and you can ignore it.
It’s complicated and I’m maybe not using the same terminology so how about an example? If you were on the edge-router, and you expect: curl http://my.private.dns.name.ziti to work, you’ll need to address this issue.
If there’s another machine in your VPC that’s simply using this edge router as an onramp, and that machine is running something like ziti-edge-tunnel, then that machine would need systemd-resolved configured so that it would be able to automatically have the DNS name resolved, and curl http://my.private.dns.name.ziti would be intercepted properly, forwarded over to this edge router and off it goes…
Yep. Completely makes sense. Thank you for the detailed answer.
In your experience, have you seen different behavior on Amazon Linux vs other distributions? I remember running into an issue on RHEL where systemd-resolved didn’t work out-of-the-box and I had to turn off DNSSEC explicitly ( “no” instead of “downgrade” option in resolv.conf ).
By any chance , are there more steps to be taken than just installing and enabling systemd-resolved on Amazon Linux?
I have seen other variants of linux on other OS’es “make a difference” here and there, yah. Some of them have SE Linux enabled which has “gotten in my way” when doing a demo/video on Oracle Cloud… So I just disabled SE Linux because I wasn’t interested in understanding why/how it was in my way. Some distros will have iptables or firewalld installed and block inbound ports in the ‘private’ network whereas AWS doesn’t seem do that. Systemd isn’t installed sometimes (oh wait, you found that one already) So there are some things like that. It’d be wonderful if we could catch/document all these use cases but to be honest, there’s so many ways to do things in linux, it’s hard to cover them all.
So yeah, I’ve seen things like that where the linux variant matters. I haven’t used Amazon Linux myself lately, I’m just not sure if there are any other gotchas to be concerned about. Perhaps someone else has recently