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