Multihomed problems

Jim Reid jim at rfc1035.com
Thu Feb 17 23:48:57 UTC 2000


>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    >> My server is a redhat 6.1 linux, we have a leased line and use
    >> the machine as mail, web, dns, router with ipchains and
    >> ftpserver.
    >> 
    >> The server is connected to the internet through a leased line
    >> and it is connected with the intranet. It has 2 ethernetcards
    >> and 2 ip addresses.
    >> 
    >> The problem:
    >> 
    >> People accessing their mail, web etc. from outside can't access
    >> the server, I know why but I don't know how to solve it:

    Kevin> You can have separate instances of named, with separate
    Kevin> "internal" versus "external" versions of your zone data,
    Kevin> listening on different interfaces, using the "listen-on"
    Kevin> directive. That's probably the most straightforward
    Kevin> solution to your problem.

Split DNS might not be necessary, but it depends on how the original
poster's net and server are set up.

I'd guess that this Linux box also doubles as the site's router and
firewall. A DNS lookup for this box which returns its internal address
and external address should "just work", whichever of those addresses
was tried by the application. Most UNIX TCP/IP stacks implement the
weak end system model, which means it's OK for a packet addressed to
interface A to be delivered on interface B. So if the outside world
looks up the host name and gets the internal address returned (first),
everything should be OK provided that they know to route to that
address via the host's external address. Maybe the Linux ipchains
stuff stamps on this weak end system model, I don't know. Or care.

Assuming the ipchains code doesn't object, all should be well. Where
things could get tricky is if there's clever packet filtering going on
- i.e. no traffic to the "inside" interface from the outside - or if
they want to have two web/mail/whatever servers, one for internal use
and one for external. If that's the case, split DNS is probably needed
so that the outside world won't be able to see or reach the internal
name space and vice versa.

Unless split DNS is needed, the Linux box should be treated as just
another multi-homed host. The DNS should be set up to return the same
name for all reverse lookups of the Linux box's network interfaces. A
forward lookup should return all those interface addresses. Extra A
records can be used to give each interface a unique name - linux-int,
linux-out or whatever - so traffic like ping and traceroute can be
forced to a specific interface.

As a general rule, split DNS should be avoided unless it's *really*
necessary. For example, when the internal net uses RFC1918 addresses -
split DNS will be compulsory there - or there are other good, strong
reasons to hide the internal name space. It can be difficult to set up
split DNS and even harder to maintain, especially for novice DNS
admins. Some people have a hard enough time understanding how to
manage one zone file, let alone maintain two different zone files for
a zone that has one just name.



More information about the bind-users mailing list