>> At my organization we are looking to implement both DHCP, and DNS (separate
>> questions), and I have some concerns.
>> DHCP:
>> We have a large campus environment across several blocks, and most of the
>> more remote locations are connected together by 10M ethernet via microwave.
>> These links are pretty heavily utilized, so in our quest to implement DHCP,
>> the thought has come up to locate multiple DHCP servers throughout the
>> network. For example, putting a DHCP server in the most remote
building, to
>> service "just that building" and not having to propogate the DHCP traffic
>> across the smaller network pipes.
A separate DHCP server at each location would probably work best in your
situation. If you're not planning on running anything else on it, and old
486 should work nicely. Assuming your sites are on different subnets the
DHCP broadcast traffic from each shouldn't cross the links. If you decide
you'd rather have 1 DHCP server and allow the DHCP broadcast traffic to be
routed across the links, setting the lease time higher will help reduce the
amount of DHCP traffic.
>> DNS:
>> Currently we are usind NAT with a firewall, and our internal network is
>> 159.139.0.0 (which we don't own - the previous net admin just picked them
>> out of a hat, and yes I am planning on replacing them with RFC1918
>> addresses..) and we would like to set up our own DNS servers to resolve to
>> some internal hosts, as well as provide name resolution for FQDN's out on
>> the internet - sort of a mix of a internal DNS and an external DNS all in
>> one "box". Would I have to have 2 seperate boxes? I also don't want our
>> "internal" hosts FQDN's propogated outside of our network. Any
suggestions,
>> tips, etc?
>Actually, you want 4 DNS boxes. Two inside your firewall (master and slave)
>and two outside of your firewall (master and slave). The two on the outside
>will sit right on the Internet, or in a DMZ. Those will have the smaller,
>subset of DNS data - just the hosts that you want the general public to know
>about, or those that they need to know about (like the machine in an MX
>record). Keep security in mind with these (e.g. - no telnet, etc.)
>The two inside should not be accessible from the outside and can contain
>every host on your internal net.
This is definately the most secure/robust route, although ideally for
*publically* accessable DNS records the two servers should not be on the
same physical network. Your ISP would provide zone slave services on their
nameserver(s) for your public DNS records. Depending on your needed level
of security (paranoia?) you could probably do the same thing with 2 local
DNS servers and some help from your ISP:
Server #1
Inside firewall. Acts as a zone master for *all* your zones, internal &
external. Has access to internet root nameservers but does not allow
queries from the internet.
Server #2
Outside firewall. Acts as a zone slave for *all* your zones, internal &
external. Has access to internet root nameservers. Allows queries from
the internet of your public DNS records. Allows zone transfers of your
public zone(s) from your ISP's nameserver(s). Allows queries of all records
from your private network. Does not allow queries/zone transfers from the
internet of your private records.
Clients
Have them use server #1 as their primary and #2 as their secondary.
You'd need the correct rules on your firewall to allow for zone transfers
between the DNS servers and queries from your internal PC's to the external
nameserver.
Bind 8 has security features that allow you to control who can
querey/transfer which zones. I understand about wanting to keep your
private records private, but if the firewall is configured properly and the
internal network uses private IP addresses, I'm not sure how much of a
security problem having your private records "leaked" poses. Maybe someone
else can comment on this...
Although this scenario isn't as safe as having the public & private records
on separate servers, it does reduce the hardware & administration costs - 2
servers instead of 4. It also provides nameserver redundancy for your
internal machines (highly recommended) and allows for easy maintenance of
DNS records - change them on the internal server and they get propigated to
the external server and your ISP, when applicable.
If you'd rather not have the public & private records on the external
nameserver, here's another possible solution:
Server #1
Inside firewall. Acts as a zone master for *all* your zones, internal &
external. Has access to internet root nameservers but does not allow
queries from the internet.
Server #2
Outside firewall. Acts as a zone slave for *public* records only. Has
access to internet root nameservers. Allows queries from the internet of
your public DNS records. Allows zone transfers of your public zone(s) from
your ISP's nameserver(s). Allows queries from your private network.
Clients
Have them use server #1 as their primary and #2 as their secondary.
In this case, if the internal nameserver goes down you clients will be
unable to resolve local addresses, but will be able to resolve internet
addresses using server #2. If this is unacceptable, add a third server
inside the firewall and make it a zone slave for public & private zones.
A final thought and then I'll stop rambling, I promise. ;-) If you're
going to provide DHCP servers at each location you could also make some/all
of them internal DNS servers using one of the solutions above. Via DHCP
you can also configure each PC to use its own "local" DNS server first,
thereby reducing traffic across the links even more. As far as the clients
are concerned, a nameserver is a nameserver.
Hope this provides some food for thought!
-Eric
Eric Sisler
Library Computer Technician
Westminster Public Library
Westminster, CO, USA
[EMAIL PROTECTED]
Linux - don't fear the Penguin.
Want to know what we use Linux for?
Visit http://gromit.westminster.lib.co.us/linux
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
