| 10 Jul 2025 |
 maciel310 | And here's the output of a couple commands to show the state, LMK if there are any other commands that would be helpful
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp0s20f0u1u2 ether carrier configured
3 vlan30 vlan routable configured
3 links listed.
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s20f0u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 1c:bf:ce:a7:84:b8 brd ff:ff:ff:ff:ff:ff
altname enx1cbfcea784b8
3: vlan30@enp0s20f0u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 1c:bf:ce:a7:84:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.30.7/24 brd 192.168.30.255 scope global vlan30
valid_lft forever preferred_lft forever
inet6 fe80::1ebf:ceff:fea7:84b8/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
| 05:42:58 |
 hexa | looks good from here | 12:10:14 |
| hexa | I'd expect the issue will be on the switchport or the other endpoint | 12:10:36 |
| hexa | different question âĶ what is the least awful way to make sure a consumer of a module I'm providing uses a DNSSEC validating resolver? | 14:21:04 |
| hexa | given that the resolver can be on the local machine (preferable) or not this seems a bit difficult to assert on ðĪŠ | 14:22:50 |
 emily | seems like not really something you can detect before runtime | 14:23:05 |
 Sandro ð§ | within reason probably not at all | 14:23:10 |
| hexa | so I'm wondering what the right approximation would be | 14:23:11 |
| Sandro ð§ | You could check if kresd is used with dnssec checks on | 14:23:24 |
| emily | I would just do nothing or have services.X.yesIPromiseImUsingDNSSec | 14:23:25 |
| emily | especially 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 resolution | 14:23:49 |
| hexa | so one thing I could do is check for networking.resolvconf.useLocalResolver | 14:24:14 |
| hexa | 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 | * 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 |
| emily | that would (sorry) break resolved with DNSSEC | 14:25:24 |
| hexa | but then I found people used dnscrypt2-proxy and other weird stuff | 14:25:28 |
| emily | dnscrypt-proxy2 doesn't do DNSSEC validation | 14:25:42 |
| hexa | resolved is fucked for this use case, I don't care ð | 14:25:47 |
| emily | I think it'll pass on the bit from the upstream resolver and that's all | 14:25:52 |
| emily | I 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 itself | 14:26:32 |
| hexa | oh, it does | 14:27:32 |
| hexa | the software is postfix for example | 14:27:36 |
| hexa | 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 | that's what you get with resolved fwiw | 14:28:10 |
 K900 | Then just let it fail IMO | 14:28:15 |
| hexa | Redacted or Malformed Event | 14:29:59 |
| emily | can't shift everything left :) | 14:37:18 |
| K900 | shift everything left :)can't | 14:42:45 |
| Sandro ð§ | maybe add a systemd unit which watches the log for that message and fails if it appears? | 14:45:19 |
| hexa | instructions unclear, multiplied by 2 | 14:45:27 |
