EDIT: The bad solution is to unblock UDP port 5353 but the port has to be source port, not destination port. (--sport flag) See the now modified rules. The issue is that this is very insecure (see this stackexchange question and comments) but obviously better than no firewall at all because at least I'm blocking TCP traffic.
The proper solution (other than using glibc and installing nss-mdns package) is to open a port with netcat (nc) in the background (using &) and then listen with dig on that port using the -b flag.
port="42069"
nc -l -p "$port" > /dev/null || exit 1 &
dig somehostname.local @224.0.0.241 -p 5353 -b "0.0.0.0#${port}"
Then we need to remember to kill the background process. The DNS reply will now be sent to port 42069, so we can just open it with this iptables rule:
-A INPUT -p udp -m udp --dport 42069 -j ACCEPT
---->END OF EDIT.
I want to setup iptables firewall but if I do that, it blocks multicast DNS which I need. I am using command
dig "somehostname.local" @224.0.0.251 -p 5353
to get the IP through mDNS and these are my iptables rules (from superuser.com):
*filter
# drop forwarded traffic. you only need it of you are running a router
:FORWARD DROP [0:0]
# Accept all outgoing traffic
:OUTPUT ACCEPT [623107326:1392470726908]
# Block all incoming traffic, all protocols (tcp, udp, icmp, ...) everything.
# This is the base rule we can define exceptions from.
:INPUT DROP [11486:513044]
# do not block already running connections (important for outgoing)
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# do not block localhost
-A INPUT -i lo -j ACCEPT
# do not block icmp for ping and network diagnostics. Remove if you do not want this
# note that -p icmp has no effect on ipv6, so we need an extra ipv6 rule
-4 -A INPUT -p icmp -j ACCEPT
-6 -A INPUT -p ipv6-icmp -j ACCEPT
# allow some incoming ports for services that should be public available
# -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
# -A INPUT -p udp -m udp --dport 5353 -j ACCEPT # does not help
-A OUTPUT -p udp -m udp --sport 5353 -j ACCEPT # SOLVES THE ISSUE BUT IS INSECURE - not recommended
# commit changes
COMMIT
Any help is welcome :)
Yeah no problem. I'd like to point out that this puts a hole in your firewall. If you have something exposed via udp, and an attacker knows about your
--sportrule or figures this out, they can connect to it just by setting their source port to 5353. You can check what's listening on udp withss -lunorsudo ss -lunp(for process info).Also, I have looked up what @Eideen@lemmy.world said about dig not supporting mdns and I think they are correct. With mdns, because of the multicast nature, you can get replies from multiple computers, and that's a pretty big difference to regular dns. How could it even reliably know it has gotten all the replies or if it should wait for more? It just sort of happens to work correctly if you get a single reply.
Also, and I also looked this up, mdns lookups will to go through avahi-daemon on regular glibc distros. The libnss-mdns plugin description for glibc says this:
Indeed, thanks, I realized that shortly after posting it.
Yep you both are correct. Looking at it now, the result does actually warn me that I'm trying to send a regular DNS request to mDNS multicast address.
Yeah I guess it's a hack. To me it does not really matter because I'm just using it for wireguard, so the worst thing that could happen is that I would try to connect to a wrong host and the key exchange would fail.
The reason for why I'm doing this whole hack is that
nss-mdnspackage is only available on glibc version of Void but I'm using musl, so it's really just hacks on top of hacks. I found a final solution though so that's nice (see final edit of post). Thanks for all your replies!