> On Wed, 21 Apr 1999, Cary O'Brien wrote:
>
> >> How did you handle the DNS issues? I think I have a way using bind, but
> >> I'm not totally sure ...
>
> > I see -- the customer had a full-time ip connection, so whichever link
> > came up, I always used the nameservers at my isp.
>
> So there has to be a route to your ISP when diald brings up the connection
> to your customer ... (and the ISP has to accept DNS requests from outside
> its domain, and it will be somewhat less efficient, etc.).
>
This is from memory (Finished the contract, deployed the system, everyone
is happy, I go home!)...
The first diald was set up as the default route, and would dial my ISP.
There was a route to the customer subnet that pointed to the slip interface
for the second diald, which would dial the customer.
> Does everything work OK if both configuration files for both dialds have
> "defaultroute" in them? Is it just a coincidence or will it surely work
> correctly?
>
No, the second diald did not have the defaultroute option.
> > In addition, I put the ip addresses of the customer's machines
> > in my /etc/hosts file.
>
> Right, something like that is necessary. I'm trying to figure out a way
> to do it with named instead of /etc/hosts , but everything I've come up
> with so far is kludgy.
>
> There should be a cleaner way to do this ... mobile IP I guess.
>
People have been kicking this around for a while. We have one customer
who (we hope!) will be dialing out to hundreds of sites using a CISCO RAS.
It would be nice if diald could grab all packets destined for a subnet
(a big 10.x one), then slice the ip address up and figure out how to
start up a pppd to dial that one remote site and route traffic for that
site out the ppp connection. But I'm not sure where to start.
-- cary
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]