| 10 Jul 2025 |
 hexa (clat on linux when) | I'd expect the issue will be on the switchport or the other endpoint | 12:10:36 |
| hexa (clat on linux when) | 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 (clat on linux when) | 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 (clat on linux when) | 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 (clat on linux when) | so one thing I could do is check for networking.resolvconf.useLocalResolver | 14:24:14 |
| hexa (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 (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 |
| emily | that would (sorry) break resolved with DNSSEC | 14:25:24 |
