> From: Jo Rhett <[email protected]> > > ...did nothing but boot up and offer recursive dns to the local LAN, = > > with auto-update of dnssec keys, default limits for rate limiting, and a = > > subscription to an RPZ that was hosted say by DNS-OARC, then we'd be = > > done by now. it could have a slightly custom kernel that allowed the = > > server to specify IP.TTL=3 in sendmsg(). > > Well on the good front, most of the custom builds to replace the crap = > home router firmwares use Unbound or DnsMasq and I'm even starting to = > see them shipping on units by default. Both of these fit your = > description, and work decently well for that super-minimal need (that = > solves the issue for most households).
It would be good if they had that IP TTL hack so that they would not be open resolvers even if installed backwards, in parallel with another router, with some kind of DMZ configuration, or anything else that exposes the inside DNS interface to the Internet. I'm not sure 3 is the right TTL value. You might want 4 or even 5 to cover big households. You'd want to set the TTL only on UDP responses but not UDP requests. It would probably be too messy and not necessary to set the TTL on DNS/TCP transactions. Doing it to TCP would want the small TTL on SYNs from the listen socket. Or am I wrong about an open recursive TCP resolver not being a more significant problem to the rest of the Internet than any other TCP service? Finally, while the cleanest implementation sounds like a new setsockopt or socket ioctl, kernel changes are not strictly required. `Ping` has worked fine with setting the IP TTL for almost 30 years. Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
