Howto: secure DNS - separate authoritative and caching nameservers with views

aphexer

Verified User
Joined
Oct 18, 2009
Messages
12
Summary: use views in bind to provide a caching-only nameserver and a authoritative-only nameserver. The local host only uses the caching-only nameserver.

These are the problems I'm trying to solve:

A: Your customer wants to host his main website with you, but does email hosting and DNS hosting himself (or outsourced to someone else).

Now what happens when you send mail to this customer, using the smtp server running on the same DA box?

Of course you're smart enouph to untick the box "Use this server to handle my emails." under MX records in DA, because if you didn't, mail would be delivered locally and probably bounce.

The problem here is that you need to enter the value of the current MX record. What if your customer changes his MX records? Next time you send him an email (and you send your email through your own DA box), exim will try to deliver to the wrong IP! (and it'll probably bounce).

You might say: ask the customer to notify you when he changes DNS, so you can copy the records over. (doesn't that sound silly?). In any case, this doesn't work when he has both DNS and Email outsourced to another company.

B: There's also a security issue here. Suppose an evil customer adds a domain called gmail.com. Now what happens when you send your next love letter to someone @gmail.com? Yeah that's right, they end up at the evil customer.

Solution:

Some control panels ignore problem A (they assume if you host the website, you also host DNS), and for problem B, they just put a list of popular domains in the control panel against which they check when adding a new domain. Sure that works for yahoo, gmail and others, but not if someone selectively wants to play man-in-the-middle for a specific not-as-big-as-google customer.

The real solution(tm) is to make sure that /etc/resolv.conf points to a caching-only nameserver. A customer who adds a domain in the control panel should have no effect at all on this caching-only nameserver.

Luckily that's quite easy to achieve. Modify your /etc/bind/named.conf to reflect these changes:

Code:
view "resolver" {
  match-clients  { 127.0.0.0/8; };
  match-destinations { 127.0.0.0/8; };
  match-recursive-only yes;
  allow-recursion { 127.0.0.0/8; };
};

view "auth" {
  recursion no;
  additional-from-auth no;
  additional-from-cache no;
  include "/etc/bind/named-da.conf";
};

Now change /usr/local/directadmin/conf/directadmin.conf:

Code:
namedconfig=/etc/bind/named-da.conf

(If you already have some domains currently hosted, you might need to move those manually to the new config file, named-da.conf)
 
Interesting if you must use your own nameserver to host recursive DNS; mine haven't done that for years.

Jeff
 
Make caching only view authoritative for special zones

It's better to even make your caching-only server authoritative for special zones, like localhost, broadcast zones and the RFC1918 zones.

Replace your resolver view with this:

Code:
view "resolver" {
  match-clients  { 127.0.0.0/8; };
  match-destinations { 127.0.0.0/8; };
  match-recursive-only yes;
  allow-recursion { 127.0.0.0/8; };

  // prime the server with knowledge of the root servers
  zone "." { type hint; file "/etc/bind/db.root"; };

  // be authoritative for the localhost forward and reverse zones, and for
  // broadcast zones as per RFC 1912
  zone "localhost" { type master; file "/etc/bind/db.local"; };
  zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; };
  zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; };
  zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; };

  // RFC1918 zones
  include "/etc/bind/zones.rfc1918";
};

I assume you have those zone files, I had them with my bind installation...
 
The problem here is that you need to enter the value of the current MX record.

Why? If DNS is hosted elswhere AND you don't have your resolv.conf file pointing to your own server (which you shouldn't) then your server will not even be looking at the MX records on itself to deliver the mail. It will do a lookup at the servers listed in resolv.conf.
 
Sure, but the problem is, what do you point your resolv.conf at then?:) I don't have a separate resolver somewhere, nor a spare machine to run it on.

If you do have that, then sure, just point your resolver.conf to that.
 
Normally you use your upstream providers dns or any number of open dns servers. Opendns comes to mind. Make sure you sign up for their free membership and turn off all the features. Personally I use 4.2.2.1 and 4.2.2.2.
 
My upstream provider doesn't provide resolvers. I also prefer not to rely on opendns, or other such free services :) But yes, that's also a possibility instead of what I did.
 
4.2.2.1 and 4.2.2.2 are open to the world, but they're not meant to be public nameservers. They've occasionally failed me in the past. One of my past upstreams used to offer them as his own, but they occasionally blocked IP#s owned and provided by that provider.

OpenDNS is quite reliable and generally very fast as so many people use it that almost everything is always in it's huge cache. If you're going to use it for your servers you need to open an account with them and set it up so it knows you're running a server and don't want any of their desktop-centric services (such as automatic redirect) which screw servers.

Why am I not surprised that your upstream doesn't supply resolving nameservers? I remember when a primary service of an upstream was it's resolving nameservers. All providers should offer them.

The problem with what you're doing is that once you've used your server for resolution, it remains in the cache and it's then a cacheing nameserver for any domain for which you've used it for resolution, even for those who shouldn't be using it.

Jeff
 
The problem with what you're doing is that once you've used your server for resolution, it remains in the cache and it's then a cacheing nameserver for any domain for which you've used it for resolution, even for those who shouldn't be using it.

Of course, that's what a caching nameserver is for. That's the whole idea of distributing DNS.

What whould you prefer? No cache, and make a full recursion on every query? There are bind directives that prevent it from updating the cache, so you could do that, but it undermines the whole idea of DNS.
 
I've already said what I prefer. Use a cacheing (resolving) nameserver for name resolution, and use a separate authoritative nameserver for serving your DNS.

You can do what you want, but you should be aware of the tradeoffs.

Jeff
 
Back
Top