[dns-operations] Should medium-sized companies run their own recursive resolver?

[Vernon Schryver]

> From: Jo Rhett <jrhett at netconsonance.com>

> > ...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    vjs at rhyolite.com