Open liusen373 opened 12 months ago
resolved stub should probably outright refuse dns queries to the .local domain anyway, making the "successful" responses the real error.
Anwyay, in your log the sender's source address is identified as 192.168.1.4, but the later successful response is apparently 192.168.1.2, so something fishy is going on. Based on the messages present, the failed replies were rejected here: https://github.com/systemd/systemd/blob/d4506301f945006c1619f7455b35653517b57a74/src/resolve/resolved-mdns.c#L362-L363
Are those addresses local? Share the ip configuration of your host. This condition should probably hit a debug log.
resolved stub should probably outright refuse dns queries to the .local domain anyway, making the "successful" responses the real error.
Anwyay, in your log the sender's source address is identified as 192.168.1.4, but the later successful response is apparently 192.168.1.2, so something fishy is going on. Based on the messages present, the failed replies were rejected here:
Are those addresses local? Share the ip configuration of your host. This condition should probably hit a debug log.
192.168.1.4 xps13.local, my laptop 192.168.1.2 pi.local, another machine on the lan
So in the first case there simply is noone asking our request. In the second case 192.168.1.2 is answering.
No idea why noone answers in the first case...
The messages from 192.168.1.4 are a red herring, it's just the query messages we sent out ourselves...
systemd version the issue has been seen with
254
Used distribution
Fedora 39
Linux kernel version used
6.5.11-300.fc39.x86_64
CPU architectures issue was seen on
x86_64
Component
nss-resolve
Expected behaviour you didn't see
No response
Unexpected behaviour you saw
systemd-resolved is my default domain name resolver.
When using programs like curl, ping, etc. to resolve .local domains, it always times out; however, if I use dig to query the domain directly, everything works fine.
Also, if I resolve the domain with dig first, let systemd-resolved cache the query results, and then use curl next, everything works fine.
systemd-resolved log:
Steps to reproduce the problem
No response
Additional program output to the terminal or log subsystem illustrating the issue