Using isdn-config and selecting dialmode=auto  is a somewhat disappointing
experience.

Initially having started ISDN trying to browse the redhat site produced an
error dialog from Netscape saying "Netscape is unable to find the server
www.redhatcom"

A bit of thought and quick check of /etc/resolv.conf shows why; there
were no nameservers configured so no packet will get as far as the ippp
device to trigger dialling because the resolver library will reject the
host
name lookup before then.

If a DNS server is specified then ipppd is run with the ms-dns option
which I think is wrong. The documentation says that you are supplying
the ISP's DNS server but the ms-dns option to ipppd is to support in-
bound MS-Windows clients

Surely isdn-config should fill in /etc/resolv.conf if you supply a DNS
server
(and being able to supply more than one would be useful). If you don't
know the ISP's DNS server perhaps a "well known" DNS server could be
substituted until the ISP's server is known. Ultimately I suppose the
correct
solution is to change the resolver library so that it could trigger
dialling and
try to discover a DNS server if there are no nameservers listed but dns
is in /etc/nsswitch.conf for host resolution

OK, so edit /etc/resolv.conf and add a handy DNS server - as it happens
my employers rather than my ISPs (I use more than one ISP so my employer
is a useful "neutral" DNS server), everything works.

Now hangup and try again - this time I get a "Network is unreachable" error
from Netscape.

The problem now is that the default route gets removed when the interface
goes down (the network routes to the other end of the PPP link remain) so
although I know where to do the DNS query I have no route to the server.

Ideally the routing should be restored to the pre-dial state by the ifdown
scripts. Leaving the route to the network corresponding to the remote
ppp address seems pointless, not re-instating the default route through
a ppp device means that an outgoing packet will not get far enough to
trigger auto-dial.