Root Server Simulation Communication Problem
Kevin Darcy
kcd at chrysler.com
Fri Mar 27 00:07:10 UTC 2009
There's a certain threshold, let's say several thousand zones, or
several 10s of thousands of resource records, where any organization
probably wants to make a complete separation between DNS hosting and DNS
resolution. At the same time, you'd probably want to put a load-balancer
of some sort in front of your DNS hosting servers, to, well, balance
load, and also to provide continuous availability in the case of a
system failure, hardware swap-ins/swap-outs or scheduled maintenance.
Having DNS servers in diverse locations, with diversity of carriers,
also becomes a priority, if your hosting functions are critical to your
business.
We currently fall below the volume thresholds mentioned above, so in the
interests of cost savings on the hardware and server-admin side, we
combine resolution and hosting on the same nameserver instances, in
separate views, but have multiple servers in multiple facilities and
multiple carriers, behind load-balancers. I should point out that we're
not a DNS hosting company, we're a car company (we make them
occasionally, when we find people who are actually willing to buy them
:-), although we do host several hundred domains, many of them as a
courtesy to our various dealerships.
If we were actually selling hosting services to customers, and
contractually obligated to certain service levels on that hosting
function, I'd seriously consider a complete isolation between the
resolution functions and the hosting functions.
As for security, such a complete separation makes it easier to lock
things down hard, since there's no reason for a query packet to come
from the outside into a nameserver instance that is dedicated to
resolving Internet names for internal clients. You can just drop those
packets with prejudice. Similarly, you can control access to your
hosting/authoritative nameservers with as much granularity as you wish,
e.g. block a whole range of addresses which is demonstrably the source
of a DoS attack, without worrying that there might coincidentally be a
nameserver in that range that your resolving nameserver instances need
to talk to for resolving names in certain domains.
At high query volumes, performance also becomes an issue, and the tuning
strategies for recursive and non-recursive servers are somewhat
different, which also argues for having a separation between the functions.
- Kevin
Ben Bridges wrote:
> Mani,
>
> That's a very general question, and I don't claim to be an expert on
> all aspects of dns security, so hopefully those who are will chime in
> on this point. I think most of those who are knowledge about dns
> would probably recommend separating your authoritative and caching
> servers, especially if you're a big dns shop hosting lots of domains,
> but I'm not sure if that's for security reasons or for performance
> reasons. If you're a small shop and host relatively few domains
> and you want to present the same records for public domains to both
> internal and external clients, then I personally don't see that it
> would hurt to make one server both authoritative and caching from a
> security standpoint. You'd want to be careful about allowing
> recursion to only your internal clients, of course, and you'd want to
> restrict access to private zones to only your internal clients (see
> below). If you want to have public and private views of the same
> zones (which is often the case), then it might be just as easy to have
> separate authoritative and caching servers.
>
> If you want your abc.com server to be purely authoritative, then
> you'll want to restore your original "recursion=no" in the options.
> You should also move the "10.168.192.in-addr.arpa" zone to your
> caching server. That's private address space, so you don't want to
> serve that data to internet hosts. (If you decide to make abc.com
> both authoritative and caching, you'll want to add an "allow-query"
> statement to that zone restricting it to only internal clients.)
>
> For a caching server, the only zones you should need are the root
> hints zone and any zones you may have for internal clients
> (like "10.168.192.in-addr.arpa" and internal versions of other zones
> like "abc.com"). You'd want "allow-query" and "allow-recursion"
> statements in your global options restricting queries and recursion to
> your internal clients. (I suppose you could use "recursion=yes"
> instead of "allow-recursion { internal-clients; }", but
> "allow-recursion" seems safer to me.)
>
> Ben
>
>
> ------------------------------------------------------------------------
> *From:* bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] *On Behalf Of *T
> MANIKANDAN-PKXR74
> *Sent:* Thursday, March 26, 2009 6:57 AM
> *To:* bind-users at lists.isc.org
> *Subject:* RE: Root Server Simulation Communication Problem
>
> Ben,
>
> In that case if I want an authoritative server and also a
> caching name server, is it fine if I place both the
> functionalities together as a best practice of implementation, how
> about security issues ?,
> If I want to introduce one more server for caching functionality
> alone how will I separate both in two different servers what are
> the changes I will be making in my abc.com server and what
> configuration should be there for the new caching name server, so
> that my clients can do a external query.
>
> Regards
> Mani
>
> ------------------------------------------------------------------------
> *From:* Ben Bridges [mailto:bbridges at springnet.net]
> *Sent:* Tuesday, March 24, 2009 7:26 PM
> *To:* T MANIKANDAN-PKXR74; bind-users at lists.isc.org
> *Subject:* RE: Root Server Simulation Communication Problem
>
> Mani,
>
> With recursion enabled, your abc.com server is both authoritative
> (for the zones configured in named.conf) and caching. If you want
> it to be purely authoritative, you'll need to disable
> recursion. But if you want to be able to query it for the root
> server (which is why you started this thread), you're going to
> have to allow recursion for at least your internal hosts because
> the server is not authoritative for ".". Why are you wanting to
> be able to query it for the root server? To want to be able
> to query a purely authoritative server for something for which it
> is not authoritative is a bit of a self-contradiction.
>
> Ben
>
> ------------------------------------------------------------------------
> *From:* bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] *On Behalf Of *T
> MANIKANDAN-PKXR74
> *Sent:* Tuesday, March 24, 2009 12:52 AM
> *To:* bind-users at lists.isc.org
> *Subject:* RE: Root Server Simulation Communication Problem
>
> Hi Ben,
>
> Thanks for reply now my root server (rootns.man) is responding
> to abc.com. after enabling the recursion to Yes in abc.com
> server, now my question is, Is my abc.com still called
> authoritative Name server or a caching name server I was
> intend to set up a authoritative name server, and hope by
> enabling recursion iam still authoritative server.
>
> Regards
> Mani
>
> ------------------------------------------------------------------------
> *From:* Ben Bridges [mailto:bbridges at springnet.net]
> *Sent:* Friday, March 20, 2009 8:35 PM
> *To:* T MANIKANDAN-PKXR74; bind-users at lists.isc.org
> *Subject:* RE: Root Server Simulation Communication Problem
>
> You have recursion disabled on your abc.com server, and I
> believe that is preventing your query from succeeding. My
> understanding is that the contents of the root hints file are
> not stored in the server's cache (which means, I think, that
> they are not themselves returned in response to queries for
> those records). Since you have recursion disabled on abc.com,
> it is never using its root hints to query your root server
> (rootns.man) for the NS and A records for the root zone (which
> sounds obfuscated, but it is done that way because the root
> servers themselves have the most current list of servers for
> the root zone).
>
>
> ------------------------------------------------------------------------
> *From:* bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] *On Behalf Of *T
> MANIKANDAN-PKXR74
> *Sent:* Friday, March 20, 2009 8:30 AM
> *To:* bind-users at lists.isc.org
> *Subject:* Root Server Simulation Communication Problem
>
> Hi,
>
> I am trying to set up lab which replicates the root
> server also. ( DNS with Root server simulation for Intranet),
> Basically I have two servers one abc.com as authoritative
> server and the other rootns.man acting as root server.
> running BIND 9 on both.
>
>
> I have done the following things in my named.conf file
>
> options {
> directory "/var/named";
> recursion no;
> };
>
> zone "." {
> type hint;
> file "root";
> };
>
> zone "abc.com" IN {
> type master;
> file "forward";
> };
>
> zone "10.168.192.in-addr.arpa" IN {
> type master;
> file "reverse";
> };
>
> *_My root File (Points to another DNS acting as Root
> server let us call rootns.man)
> _*
> . 86400 IN NS rootns.man.
> rootns.man. 86400 IN A 1.2.3.4
>
> *_My Forward and reverse file
> _*
> $TTL 3600
> @ IN SOA abc.com. root.abc.com. (
> 42 ; serial
> 3H ; refresh
> 15M ; retry
> 1W ; expiry
> 1D) ; minimum
> IN NS abc.com.
> abc.com. IN A 192.168.10.12
>
>
> $TTL 3600
> @ IN SOA abc.com. root.abc.com.(
> 42 ; serial
> 3H ; refresh
> 15M ; retry
> 1W ; expiry
> 1D) ; minimum
>
> IN NS abc.com.
> 12 IN PTR abc.com.
>
> *_In the other DNS server rootns.man (acting root server)
> _*
> zone "." IN {
> type master;
> file "forward";
> };
>
>
> *_Forward file in roons.man server
>
> _*
> $TTL 86400
> @ IN SOA rootns.man root.rootns.man (
> 42 ;
> serial (d. adams)
> 3H ;
> refresh
> 15M ;
> retry
> 1W ;
> expiry
> 1D ) ;
> minimum
> . IN NS rootns.man.
> rootns.man. IN A 1.2.3.4
>
>
>
> *Once completing this I have a minor problem that is my
> abc.com server is not able to determine the root server
> (rootns.man) IP address. attached the DIG output from
> abc.com server. can any one please help me in resolving
> this issue.*
>
> **
>
> Regards
>
> Mani
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list