1

I'm not quite sure how exactly to phrase what it is I need, which makes searching challenging. :) Basically I've got Bind DNS running on RackSpace instances and I want to set named up so that any of my clients can recursively query without risking an open resolver.

All clients are Linux based, though the Android mobile clients are a bit harder to configure. I know that I can setup caching instances of Bind on the laptops and gateways, which might allow some form of key based authentication of recursive requests. I am unsure if this is possible on Android clients, though.

Note that I know that I can use a wide array of public resolvers, like those provided by Google, but for reasons not relevant here, I need to run my client requests through my own server if at all possible. I have tried wading through the man pages and online docs, but I'm not clear on exactly what I need to look for.

----- More info as per comments. -----

Clients are not connected through a VPN, and I'm trying hard to avoid that for certain reasons. Just one of those reasons is that the extra memory footprint and CPU load of even lightweight, low security VPNs is challenging on the most affordable cloud instances. A second is that VPNs add a layer of complexity in almost all Android implementations that I've seen that is super annoying if not truly needed for security.

I am not "married" to Bind as a name server. If there are other FOSS name servers that might be more useful in this particular instance, I'll happily give them a spin. I've simply spend 15+ years using Bind and stopped thinking about alternatives.

I am also not greatly concerned about anyone trying to hack the DNS responses to my clients. If we were living in a world like that the DNS system was designed for, I'd happily run an open resolver. Alas, miscreants of various stripes tend to abuse my open resolver to attack third parties.

I am not running a "mission critical" network here. It is used by few people, for nothing financially or personally critical, rather for experimentation, development and testing.

justinzane
  • 181
  • 2
  • 13
  • 1
    The clients are not in a particular network or VPN? – wfaulk Sep 16 '15 at 18:49
  • possible duplicate of [How do I set up a "secure" open resolver?](http://serverfault.com/questions/634793/how-do-i-set-up-a-secure-open-resolver) – Andrew B Sep 16 '15 at 19:03
  • A secure tunnel might work, but not much else. There is nothing BIND can do to protect you against UDP source address spoofing. A source address ACL will limit the spoofed source IPs that you will respond to, but will not actually prevent it. – Andrew B Sep 16 '15 at 19:10
  • @AndrewB It may be a duplicate of that question, however, the question was left unanswered with a "do not do that" response. A nonanswer is really rather useless for anyone interested in learning and seems rather ridiculous on a site like this. I'm asking to learn, not have a snotty expert tell me to hire someone. – justinzane Sep 16 '15 at 19:59
  • If I was being snotty I wouldn't have tried to give you some supplemental advice in this comment thread already. Read the answer again, and focus more on the concepts that are being exposed. Does Rackspace have a way of validating that neighboring routers aren't forwarding traffic that spoofs the source IP of the traffic your server receives? The answer is almost imminently "no". Trying to tell someone that they're offensive for implying that this is not imminently solvable by a person in your position will not change this. – Andrew B Sep 16 '15 at 20:33
  • RE: your edit, use of another product can't solve this either. This is a networking layer challenge. It is already too late to prevent spoofing by the time the packet has arrived at the server. – Andrew B Sep 16 '15 at 20:36
  • @AndrewB Sorry if I came across as attacking you. I know that your intent was helpful; I simply found the way the linked question was handled to be demeaning to those trying to learn HOW to accomplish tasks, as opposed to those attempting to learn WHAT best practices are. Sorry again for the misdirected bile. – justinzane Sep 16 '15 at 23:15
  • The best practice is not to do it. :( That's the problem. No one really cares whether we express that in short form or long form, we're told that we're dismissive jerks because we're not "enabling" people to do it anyway. It's becoming clearer and clearer to me that people don't "get" the fact that you can't tell someone how to design a datacenter to do this in one Q&A, especially when the people who keep asking this of us are system administrators - the ones least in a position to do something about this. (note: *I* am a system admin, and I fall in that category) – Andrew B Sep 16 '15 at 23:19

3 Answers3

3

You can use TSIG-based access-control on your BIND resolvers for this. This works with clients that can actually use TSIG, which probably limits it to those running a local BIND instance themselves.

See http://www.cyberciti.biz/faq/unix-linux-bind-named-configuring-tsig/ and http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch04.html#id2570685.

Do note that this makes it very easy to mount a denial of service attack on your resolvers by forcing them to validate a flood of bogus signatures.

In general, I would strongly advise against running your own resolvers for your clients on the Internet. It will work only in exceptional cases, and there simply isn’t any rational use-case. Your DNS queries should not contain sensitive data, or you’re doing it wrong. If your ISPs’ resolvers are too unreliable or nonexistent, use OpenDNS or Google Public DNS (I’d rather not use those if I don’t have to).

If anything, run local BIND (or rather unbound) resolvers where you can, enable DNSSEC and sign your zones.

Stefan Paletta
  • 231
  • 1
  • 3
  • Yeah, so long as the recursor is internet facing there's going to be a significant risk of some sort. I didn't go into TSIG because that's changing the nature of the DNS queries themselves (i.e. modern resolver clients are still dumb and not equipped to do this), but +1 for the creative approach. – Andrew B Sep 16 '15 at 21:01
  • One of the primary points of this is to allow full access to both client and server sides of network communications. I set "excessively" short TTLs and throw up temporary CNAMES and other silliness that I do not really want to have to propagate through. Plus I'm a stubborn idiot who wants to learn what is and is not possible. :) – justinzane Sep 16 '15 at 23:27
  • I've tried that long ago and not quite gotten local TSIG caching nameds working. Is Zytrax the best documentation on TSIG setup now? – justinzane Sep 16 '15 at 23:29
  • Sorry, I don’t know what the best documentation is. The official BIND documentation is of course comprehensive and correct, but obviously not a howto-style thing. – Stefan Paletta Sep 16 '15 at 23:32
0

The following won't work for Android, but it works great on GNU/Linux clients. Technically, it involves setting up a VPN, but there's no actual setup involved, nor does your actual network traffic go to the remote server (except for your DNS queries, of course, which go to the remote server -- that's the whole point!), so the load on the remote server is minimal. If you have ssh access to your remote server then you can do this.

On the Rackspace instance, which I'll call remote-server.com: make sure sshd and named are working.

On the Linux clients:

sudo apt install sshuttle ### or dnf install sshuttle, or whatever
sshuttle --dns -r username@remote-server.com 192.0.2.0/24

This sets up a VPN which routes all DNS queries, plus all network traffic sent to 192.0.2.0/24, to the remote server. But 192.0.2.0/24 is an IP address blackhole (RFC 5737), so in practice no actual network traffic gets sent to the remote server. However, DNS queries will be sent to the remote server.

djao
  • 101
0

I don't believe you can filter based on the os that the client is running. But if you know the ips the clients(or caching serves) are connecting from, you can use an acl like this:

acl "trusted" {
    192.168.0.0/16;
    10.153.154.0/24;
    localhost;
    localnets;
    };

options {
    ...
    allow-query { any; };
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    ...
    };
MVanOrder
  • 175
  • 5
  • The core problem is that I cannot use any IP based filters. I've got no idea what network the clients will be connecting through and therefore no idea what IP ranges to use. I need something that will work for a laptop at some Motel 6 or a mobile roaming through AT&T. – justinzane Sep 16 '15 at 19:53
  • Allowing access by the OS type would make it open to any Linux server or PC, and cell phone on the internet. Have you considered a split tunnel VPN to gain access to the DNS? Also I haven't found any easy way to implement it, but if you could put a DNS record for any request that isn't in the trusted ACL which would point to a login web interface. Then once logged in the client IP would get added to the ACL(with some sort of expiration that removes the IP form the ACL). – MVanOrder Sep 16 '15 at 20:49