[CentOS] Re: Bind Setup -- summary of "things to know"

[Bryan J. Smith]

Top-part:  I've been purposely holding off commenting to see
what others would say.  With that said, I'm going to make a
"summary" of "things to know" for handling both private and
public DNS for an organization -- SOHO or bigger.

William Warren <hescominsoon at emmanuelcomputerconsulting.com>
wrote:
> I am intently trying to avoid sending anything to the root
> servers w/o checking with my Astaro firewall first.
> Hence why i started with a caching name server.
> Now i am looking to setup a full internal DNS server for
all
> of my network

Correct.  You should do this because your internal systems
might be trying to query public servers for internal-only
names/addresses.

To summarize, bullet-by-bullet, of what most people have
already said and most Enterprises do:  

1.  Use a DNS domain that is _unique_ for the private network
1.a.  If you already have a domain name for your
company/organization, create the private network as a
_subdomain_ -- _never_ call it the same.
1.b.  If you are using ADS-integrated DNS, consider making
ADS domains their own subdomains -- or even a different
domain with an _invalid_ TLD (e.g., ads.mycompany.prvtld) so
it is _never_ resolvable on the internet.

2.  Setup at least 2 DNS servers, one primary, one secondary
2.a.  The Primary DNS has both a forward and reverse zone for
the private network
2.b.  Both Primary and Secondary DNS have "forwarder" entries
to fetch public names
2.c.  NOTE:  While you can have multiple DNS domains to a
subnet, but only 1 reverse zone -- so this might be an issue
with separate ADS-integrated and BIND DNS servers, just FYI.

3.  Set the DNS servers of all Windows and UNIX clients to
_only_ the _internal_ DNS servers
3.a.  _Never_ allow private LAN nodes to query public DNS
servers, only the internal DNS servers
3.b.  The "forwarder" entries on the internal DNS servers
handle fetching public DNS names/IPs

4.  Block any outgoing UDP/TCP traffic to destination port 53
(if you're not blocking all outgoing by default already),
except for the internal DNS servers

5.  Hack the registry on Windows NT5+ (2000+) so they do not
cache DNS resolution failures (as we previously discussed)

Now if you are going to want your public IP addresses to be
reachable, it depends on if you have dynamic or static
addresses.  For dynamic, use a service that will map your
name/IP upon update.  If you have a block of static IPs, then
do the following ...

6.  Again, use _separate_ domains for private and public
6.a.  I typically _still_ use a subdomain for the public
(e.g., public.company.com)
6.b.  I then use CNAMEs from the "root" domain (e.g.,
mycompany.com) so I _never_ have to change the "root" domain
DNS (and can leave it "read only").

7.  If your public IP block is not a perfect class A, B or C
-- you can_not_ maintain your reverse zones directly.
7.a.  It's very typical to have a "classless" IP block of
only 4 (/30), 8 (/29), 16 (/28) or 32 (/27) addresses
7.b.  This could be that your ISP with the "full" class C
handle it
7.c.  Alternatively, per RFC2317 "Classless IN-ADDR.ARPA
delegation" ( http://www.faqs.org/rfcs/rfc2317.html ), you
setup a reverse zone per your ISP's format.  E.g., if your
ISp gives you 100.150.200.192-207, 16 addresses,
255.255.255.240 (/28 CIDR format) subnet mask, your $ORIGIN
for your reverse zone would typically be (there are
alternatives to this, depending on your ISP's entry):
  $ORIGIN 192/28.200.150.100.in-addr.arpa.
          ^^^ ^^ ^^^ ^^^ ^^^
           D  E   C   B   A
A, B and C = 1st, 2nd and 3rd octects, respectively
D = start of 4th octet block
E = CIDR format subnet mask (28 = 255.255.255.240)

> since i intend to implement AD in the future(again for
> learning purposes)

ADS can use DNS in various modes.

One proprietary one is "ADS-integrated" whereby ADS provides
peer-replicated DNS (and BIND can _only_ be secondary to it).

There are a few 3rd party solutions which also offer a
unified layer-2/3 DHCP/DDNS/DNS/etc... name resolution
framework with peer replication, but they are not free (let
alone _none_ are open source).

Frankly, although there are a few "wrapper management tools"
for enterprises around ISC DHCP and BIND, I'd really like to
see an "unified" layer-2/3 name service solution come from
the open source world.  God knows with IPv6, it is also
redundant to keep DHCP and DNS separate, and not under the
control of a single daemon.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)