| 10 Jul 2025 |
 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 |
