!tCyGickeVqkHsYjWnh:nixos.org

NixOS Networking

878 Members
Declaratively manage your switching, routing, wireless, tunneling and more. | Don't rely on `networking.*` for interface and routing setup, use systemd-networkd, ifstate or NetworkManager instead. | Set `SYSTEMD_LOG_LEVEL=debug` to debug networking issues with networkd | No bad nft puns, please. | Room recommendations: #sysops:nixos.org255 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
10 Jul 2025
@hexa:lossy.networkhexa (clat on linux when)so I'm wondering what the right approximation would be14:23:11
@sandro:supersandro.deSandro 🐧You could check if kresd is used with dnssec checks on14:23:24
@emilazy:matrix.orgemily I would just do nothing or have services.X.yesIPromiseImUsingDNSSec 14:23:25
@emilazy:matrix.orgemilyespecially for remote it's hopeless, but even locally there can be all kinds of layers between an enabled service and what actually ends up being used for DNS resolution14:23:49
@hexa:lossy.networkhexa (clat on linux when) so one thing I could do is check for networking.resolvconf.useLocalResolver 14:24:14
@hexa:lossy.networkhexa (clat on linux when)

the other thing, that I found super awful was

         lib.any (with config; [
          services.bind.enable
          services.dnsmasq.enable
          services.kresd.enable
          services.unbound.enable
          services.pdns-recursor.enable
        ]);
14:25:03
@hexa:lossy.networkhexa (clat on linux when) *

the other thing, that I found super awful was

        lib.any (with config; [
          services.bind.enable
          services.dnsmasq.enable
          services.kresd.enable
          services.unbound.enable
          services.pdns-recursor.enable
        ]);
14:25:05
@emilazy:matrix.orgemilythat would (sorry) break resolved with DNSSEC14:25:24
@hexa:lossy.networkhexa (clat on linux when)but then I found people used dnscrypt2-proxy and other weird stuff14:25:28
@emilazy:matrix.orgemily dnscrypt-proxy2 doesn't do DNSSEC validation 14:25:42
@hexa:lossy.networkhexa (clat on linux when)resolved is fucked for this use case, I don't care 🙂 14:25:47
@emilazy:matrix.orgemilyI think it'll pass on the bit from the upstream resolver and that's all14:25:52
@emilazy:matrix.orgemilyI don't really think asserting on dynamic network conditions is something a module should be doing at all tbh. if the software absolutely needs the DNSSEC validation bit in responses it should be checking for it itself14:26:32
@hexa:lossy.networkhexa (clat on linux when)oh, it does14:27:32
@hexa:lossy.networkhexa (clat on linux when)the software is postfix for example14:27:36
@hexa:lossy.networkhexa (clat on linux when)
postfix/smtp[2110025]: warning: DNSSEC validation may be unavailable
postfix/smtp[2110025]: warning: reason: dnssec_probe 'ns:.' received a response that is not DNSSEC validated
14:28:05
@hexa:lossy.networkhexa (clat on linux when)that's what you get with resolved fwiw14:28:10

Show newer messages


Back to Room ListRoom Version: 6