3rd party CNAMEs and open recursion

[Vernon Schryver]

> > On 3/4/2013 3:26 PM, Verne Britton wrote:

> > 1. serve the A records as authoritative
> > 2. somehow handle resolutions coming at me for the CNAMEs
> > 3. not have a public open recursive server

> From: Kevin Darcy <kcd at chrysler.com>

> You can achieve all of that as long as you provide recursive service 
> only *selectively* (otherwise, #2 degenerates into what you're trying to 
> avoid with #3). If you can't convince your users to use their own 
> resolvers when they are on the Internet, and you can't constrain them to 
> only certain source-address ranges (because they are geographically 
> and/or topologically diverse when they're on the Internet) the only 
> technical fix that comes to mind is to set up some sort of 
> crypto-authentication of your client's queries (e.g. TSIG or GSS-TSIG) 
> on the endpoints. You could use that to allow/deny recursion and/or 
> match views.

Yes, but are they really using only the company resolvers and no
other company applications?  If they don't care about other company
applications, why not tell them to use 8.8.8.8 or equivalents?
If they have VPNs for other applications, why not use the tunnels
for port 53 as well?

On the other hand, DNSSEC seems to me to want a lot more resolvers
a lot closer to applications, so why not install simplistic caching
resolvers on the user systems?
(such as a Windows copy of BIND, since this is the bind-users mailing list)
(of course, suitably restricted to answering only 127.0.0.1 or ::1)

When traveling with a Windows thing, I want to use my trusted,
DNSSEC aware resolver.  I wanted to use TSIG or SIG, but could find
no way to tell Windows' stub anything about any keys.  Tunnelling
was easier than fiddling with BIND on Window, and works fine.


Vernon Schryver    vjs at rhyolite.com