Re: Root Server Simulation Communication Problem
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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] *On Behalf Of *T
RE: Root Server Simulation Communication Problem
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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Thursday, March 26, 2009 6:57 AM
To: bind-users@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:bbrid...@springnet.net]
Sent: Tuesday, March 24, 2009 7:26 PM
To: T MANIKANDAN-PKXR74; bind-users@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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Tuesday, March 24, 2009 12:52 AM
To: bind-users@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
_
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:bbrid...@springnet.net]
Sent: Tuesday, March 24, 2009 7:26 PM
To: T MANIKANDAN-PKXR74; bind-users@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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Tuesday, March 24, 2009 12:52 AM
To: bind-users@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:bbrid...@springnet.net]
Sent: Friday, March 20, 2009 8:35 PM
To: T MANIKANDAN-PKXR74; bind-users@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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Friday, March 20, 2009 8:30 AM
To: bind-users@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
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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Tuesday, March 24, 2009 12:52 AM
To: bind-users@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:bbrid...@springnet.net]
Sent: Friday, March 20, 2009 8:35 PM
To: T MANIKANDAN-PKXR74; bind-users@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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Friday, March 20, 2009 8:30 AM
To: bind-users@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 N
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:bbrid...@springnet.net]
Sent: Friday, March 20, 2009 8:35 PM
To: T MANIKANDAN-PKXR74; bind-users@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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Friday, March 20, 2009 8:30 AM
To: bind-users@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
$TTL86400
@ 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 A1.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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
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-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Friday, March 20, 2009 8:30 AM
To: bind-users@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
$TTL86400
@ 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 A1.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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
