Multiple network interface problem

Kevin Darcy kcd at daimlerchrysler.com
Fri Aug 18 22:07:53 UTC 2000


Instead of NAT'ing the new address to the old address, why not configure the
mail/web server with a second interface (virtual if necessary)? That would
allow the OS on the box, and smarter UDP-using applications like BIND, to do
the Right Thing, i.e. respond to a packet from the same interface on which it
was received. Which I think would eliminate the problems you're having.

But, given the architecture you have, a workaround is to just give separate
names to each address (as you have done for mail) and list both names as
NS records for your zone(s). As far as the rest of the world knows, they are
two separate nameservers. Failover will be automatic.

Another alternative which would work in theory is to have multiple A records
for the NS name. But in practice, I don't think the registrars can cope with
multi-valued glue records, so this would only work for subzones of your
registered domain(s).


- Kevin
Mathew Rouch wrote:

> Hello, all.  I'm new to the list, so forgive me if this question has been
> answered in the past (I didn't see it in recent posts.)
>
> I've got a problem with IP address resolution for our web and ftp sites,
> www.pfsdata.com and ftp.pfsdata.com.  Up until recently we had a single
> point of access to the Internet (a T1 line,) and these two sites resolved to
> our registered address 209.46.83.178.  Not long ago we added a second T1
> line to the Internet to give us a) more bandwidth and b) a failover in case
> one line went down.  The two lines are hosted by different ISPs.
>
> We installed a new router outside our firewall with two serial interfaces.
> One connects to our original T1, the other to the new one.  The new ISP
> assigned us the registered address 209.98.219.1 for our web and FTP sites.
> We are using NAT on the new router to translate queries for the new
> registered address back to the old one, which is the configured address of
> our firewall.
>
> So far so good.  The above all works.  The only problem is with the routing
> of queries.  My original intention was to download partial BGP routes from
> both ISPs.  Unfortunately, one ISP refused to let us do this, and the other
> is still waffling.  In order to effect load-balancing between the two T1
> connections to the Internet, I have been forced to implement static routes.
> This works, but it caused a problem.
>
> I find that if someone tries to access www.pfsdata.com, it will resolve to
> 209.46.83.178.  The web request then comes in through our original T1
> connection.  Unfortunately, since the routing here is now static, the T1
> that is selected for the reply will depend on the source address of the
> original query.  if it happens to be an address that is configured
> (statically) to go out through the new T1, the source address of the reply
> is changed to 209.98.219.1, and the originator of the request does not
> recognize the reply as coming from our web server.  To that person, it looks
> as though our web server is not responding to queries.
>
> We originally had this same problem with our e-mail.  To fix it we added a
> record for mail2.pfsdata.com that resolved to 209.98.219.1 and added a
> secondary MX record to the DNS configuration which pointed to
> mail2.pfsdata.com.  That way, if someone queries mail.pfsdata.com and gets
> no reply, they are automatically redirected to mail2.pfsdata.com, and the
> query works.
>
> So my question (finally) is this:  Is there an equivalent way to configure
> the DNS of www.pfsdata.com and ftp.pfsdata.com so that if they do not see a
> response from 209.46.83.178, it will automatically roll over to the
> secondary IP address 209.98.219.1?
>
> Thanks in advance,
>
> Mathew Rouch
> Preferred Financial Systems
> (651)628-5938
> mrouch at pfsdata.com






More information about the bind-users mailing list