| 12 Sep 2025 |
| Em Vee joined the room. | 12:47:05 |
toonn | ghostbuster91: As promised my unicast DNS multicaster, https://codeberg.org/toonn/dns2mdns | 13:15:30 |
Jassuko | Huh? Doesn't nginx support resolving through normal OS provided name lookups? | 13:32:35 |
toonn | If you have a configuration for me that makes that utility redundant, I'm all ears. | 13:37:14 |
magic_rb | @toonn:matrix.org some haskell review
- https://codeberg.org/toonn/dns2mdns/src/branch/trunk/src/Main.hs#L68 bytestring has
toStrict and fromStrict in the lazy module
- https://codeberg.org/toonn/dns2mdns/src/branch/trunk/src/Main.hs#L48 all toplevel bindings should have types
| 13:37:15 |
magic_rb | You can enable mDNS in systemd-resolved and then nginx should use that. | 13:37:49 |
Jassuko | I have that kind of setup somewhere. There's some shitty behaviors with the systemd-resolved mdns implementation relating to IPv6, but I don't remember what exactly was the pain point with that. It was something they specifically defined to do wrong and not care about, if I remember correctly. | 13:40:36 |
Jassuko | I had this on one laptop where I absolutely needed to use network damager for managing WiFi due to reasons. Thus, the rather weird config on that.
# Enable Network Manager for WiFi networking
networking.networkmanager = {
enable = true;
connectionConfig."connection.mdns" = 2;
dns = "systemd-resolved";
# firewallBackend = "nftables"; ## Deprecated
};
networking.resolvconf.dnsSingleRequest = true;
services.resolved = {
enable = true;
llmnr = "false";
fallbackDns = [
# "8.8.8.8"
# "2001:4860:4860::8888"
"1.1.1.1#cloudflare-dns.com"
"1.0.0.1#cloudflare-dns.com"
"2606:4700:4700::1111#cloudflare-dns.com"
"2606:4700:4700::1001#cloudflare-dns.com"
];
extraConfig = ''
MulticastDNS=yes
Cache=no-negative
DNSOverTLS=opportunistic
DNSStubListenerExtra=::53
'';
};
| 13:44:51 |
Jassuko | Firewall needs to be handled as well, like:
# Open ports in the firewall.
networking.nftables.enable = config.networking.firewall.enable || false ;
networking.firewall = {
enable = false;
allowedTCPPorts = [
"22"
];
allowedUDPPorts = [
""
];
extraInputRules = ''
ip6 daddr ff02::fb/128 udp sport 5353 dport 5353 accept
ip daddr 224.0.0.251 udp sport 5353 dport 5353 accept
'';
};
| 13:45:31 |
Jassuko | so systemd-networkd is used to manage all other network things except WiFi, and systemd-resolved is used for all DNS lookups | 13:47:47 |
toonn | Oh, you know what, I think I remember what the problem with systemd-resolved is in my case. It doesn't allow for subdomains of .local! | 13:51:57 |
K900 | That's out of spec | 13:52:15 |
Jassuko | /etc/nsswitch.conf might or might not need adjusting as well for the hosts: -line. Namely, the resolve needs to be there correctly at the correct place depending on your other setup:
hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
| 13:52:23 |
toonn | Yep, and working well for me : ) | 13:52:26 |
toonn | I really don't see a good reason for it to be out of spec, it's just an arbitrary decision AFAICT. | 13:53:07 |
Jassuko | Ahh. Well, that is a use case I have not had. :D | 13:53:13 |
magic_rb | Does the spec restrict valid TLDs? .local is very very common | 13:57:29 |
toonn | I think the spec requires .local actually. | 13:57:51 |
K900 | No, but the mDNS spec does not allow multiple parts in the domain name | 13:58:17 |
K900 | It does require .local | 13:58:36 |
K900 | But foo.bar.local is not allow | 13:58:42 |
K900 | * But foo.bar.local is not allowed | 13:58:45 |
K900 | Only foo.local | 13:58:48 |
magic_rb | Oh, so no subdomains | 13:59:14 |
magic_rb | Weird | 13:59:16 |
toonn | I assume it's because some printer's implementation somewhere splits on the first `.` and then proceeds to freak out. | 13:59:56 |
K900 | No, it's because | 14:01:21 |
Jassuko | Not weird, really. The .local thingy is intended for host discovery on local network by name. And the hostname is by definition the last part of the fqdn. :p | 14:01:24 |
K900 |
Most computer users neglect to type the trailing dot at the end of a
fully qualified domain name, making it a relative domain name (e.g.,
"www.example.com"). In the event of network outage, attempts to
positively resolve the name as entered will fail, resulting in
application of the search list, including ".local.", if present. A
malicious host could masquerade as "www.example.com." by answering
the resulting Multicast DNS query for "www.example.com.local.". To
avoid this, a host MUST NOT append the search suffix ".local.", if
present, to any relative (partially qualified) host name containing
two or more labels. Appending ".local." to single-label relative
host names is acceptable, since the user should have no expectation
that a single-label host name will resolve as is. However, users who
have both "example.com" and "local" in their search lists should be
aware that if they type "www" into their web browser, it may not be
immediately clear to them whether the page that appears is
"www.example.com" or "www.local".
| 14:01:26 |
magic_rb | Aaaah DNS is cursef | 14:03:19 |