Distributing DNS servers

[Barrett Richardson]

> 
> >Issue 1
> >
> >  With this scheme IP packets leaving the boxen must not
> >  have the IP address of the primary (which is on the loopback
> >  and not unique in the network) but the IP address of the
> >  ethernet (which is unique). The idea is to have answers
> >  to queries to go the box that sent the query.
> >
> >  Doable?
> 
> BIND 4.9 and newer forces the source address of a response to match the
> destination address of the query.
> 
> Why do you think it's wrong for these packets to have the loopback address
> as their source?  So it's not unique, who cares?
>

Hmm. There is only on exit point to the Internet on this particular
network. They have exhausted their address space and have resorted
to using some IP's in the 172.16 - 172.xx range. Some segments are
on these IP's, some on registered IP's. What I was thinking of was
haveing multiple a.b.c.d's, (the authorative primary) potentially
on the 172.xx networks as well. With a single entry point into the network
the border router (actually the firewall just behind it) will have no way
of knowing which a.b.c.d to send a packet too. I guess I need to have
unique sources inside the firewall that all the other nameservers
behind the firewall forward requests for hosts outside the domain to.

Another problem is that most of the users are using a.b.c.d for the
nameserver in their clients -- which is the authorative primary.
Some of their webservers in the future will be placed on 172.xx
addresses -- but for queries that come from the internet, the
nameserver needs to dole out an address for a registered IP (
the firewall will deal with connectivity to it). So I need to
put a.b.c.d on the DMZ so the firewall and it needs to have
different info about the state.ky.us domain than the internal
a.b.c.d nameservers. Management doesn't want a large user base
with limited skills mucking around with the network configuration
on their workstations, and I want to avoid changing the authorative
primary (as far as the internet is concerned) if possible.

So I guess my solution is:

  Have multiple a.b.c.d's internally. Have them *all* forward
  their requests to x.x.x.x and y.y.y.y. Go ahead and have
  an a.b.c.d on the DMZ to answer requests that come from
  internet land.

How about when queries originate from the internal nameservers?
If a.b.c.d is on a loopback, the ethernet is on x.x.x.x, a request
being sent out has source of x.x.x.x, right? This would help
much (I would just have to avoid putting nameservers on the 172.xx
network). Forwarded requests from the internal nameservers to the
forwarders inside the firewall would also need a unique source
(might could stash a nameserver on the 172.xx network then --
as long as I could ensure an internal request *does* go to a
forwarder).

-

Barrett Richardson (my name)
barrett at aye.net    (my email address)
main(){}           (my program)

 
> -- 
> Barry Margolin, barmar at bbnplanet.com
> GTE Internetworking, Powered by BBN, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> 
> 
>