Forwarding to a non-standard port

[Jim Reid]

>>>>> "Christine" == Christine Tran <Christine.Tran at East.Sun.COM> writes:

    Christine> I'm not sure if I have presented an accurate picture.
    Christine> Our internal NS is on a separate host and this subnet
    Christine> is roped off.  Our forwarder (caching server) is on the
    Christine> DMZ, and querries recursively for our internal NS about
    Christine> stuff not in our auth. zone.  If the forwarder is
    Christine> compromised I don't think the bad guy can get into our
    Christine> internal NS, (although of course he can poison the
    Christine> cache.)  I was going to put our external NS on the same
    Christine> box as the forwarder.  My question was should I run
    Christine> forwarder + external NS as one named process: that is,
    Christine> recurse for internal NS as well as anyone who asks.
    Christine> OR: forwarder on listening on one IP, recursive
    Christine> querries on behalf of internal NS; external NS
    Christine> listening to the other IP, provide auth. zone answers
    Christine> only, no recursive querries.

I thought I already answered this. Run two name server processes on
the bastion host. It's the only way to go if you want to ensure that
you can keep the outside from getting to your internal domains. It's
also much cleaner to administer and configure: just watch about the
names of the named config files and things like /var/run/named.pid and
/var/run/ndc. Conceptually, you have two different name servers doing
different things. They just happen to run on the same box, albeit
using different network interfaces.

One server presents your domain to the outside world AND NOTHING ELSE.
Simple. No mess, no fuss, no worries. The other server listens
internally. It's probably a good idea to make this server slave your
internal zones. That makes it authoritative for the internal name
space, so nobody can poison that server's cache with interesting local
names. It also gives you another authoritative name server, which is
no bad thing: single points of failure and all that.

Your internal name server's configuration is easy too. There's no
weirdness with forwarding (rejoice!) or wacky access lists (rejoice!)
to set up in the hope this makes it bullet-proof to the outside. It's
just another boring slave name server that can query the
Internet. Apart from the stuff with config and run-time files and
making it listen on only one interface, this is a simple, easily
understood and trivially implemented name server configuration. And
a couple of lines in the options{} statement to make those changes are
very easy too. You've probably spent more time sending mail about this
that it would have taken to write the two named.conf files you'd need.

Now you could try to use one name server process. With lot of work,
you might be able to set up fancy access control lists and forwarding
statements to that some folks get one answer and others get a
different response, but it's just not worth it. For one thing, it's
hard to get right (and even harder to keep it right). There's always
the prospect that some sneaky DNS packet is able to jump over the
shaky partition you've set up between the internal and external name
spaces. Oh and don't forget to document that snakepit for the person
who one day takes over from you as hostmaster for this set up.

BTW, as a general rule, I dislike forwarding name servers. I prefer to
let name servers find their way to resource records for themselves by
following NS records. Single points of failure and all that again. [Your
mileage may vary.] The DNS protocol has enough robustness built in to
it with multiple NS records. Leveraging that robustness is a whole lot
better than telling your name server to always send queries to this
address or that address IMHO. What if this or that IP address is
unreachable or no longer runs a name server?