On Wed, 21 May 1997, Francois Gouget wrote: > > Most Linux documentation advises against running bind, saying that it's > [...] > > get it working....it only takes a few minutes at most. > > I would rather say that it took me a several hours but perhaps I'm > worse than average.
for a site that doesn't need to be primary or secondary for any domains, bind installation & configuration should only take a few minutes. The only thing you need to know is the IP address of a forwarder (optional but recommended) and whether you want debian's bindconfig to run a primary for the 127.in-addr.arpa domain (reverse lookup for localhost) - the answer to that question is "yes"...i can't think of any reason for saying no. If you need to run a primary or secondary name server (not advised on a dial-up connection - nameservers are meant to be on the net permanently) then configuration will take longer than that, of course. > > BTW, if you're using diald you'll probably want to configure it so that > > it doesn't bring up the link every time you want to resolve a name. But > > you'll want to do that whether you're running bind or not. > > In fact if you're using diald having a local bind server is > perhaps more trouble than it's worth. Here is why: > > - Either diald does not bring the connection up for DNS requests. Then > applications will seem to hang if the result for their DNS query is not in > the cache. They will stay blocked in some gethostbyname call until the DNS > server times out which takes quite a long time. With some X applications > you can completely freeze the X server (with netscape click on a menu. It > does it's name lookup right here and it seems to block X). OK, you might be able to speed that up. try editing your /etc/ppp/ip-{up,down} scripts so that: - when the link goes down, use ipfwadm to 'reject' (not 'deny') outbound packets for upd port 53 (allow for your internal network, but reject for 0.0.0.0/0). bind should get a 'no route to host' reply whenever it attempts to do a lookup. With any luck, it will return the error result immediately rather than trying again. - when the link goes up, use ipfwadm to remove the udp 53 block. I haven't tested any of this. I don't know if it works, but it's worth a try. (i'd test it myself but i don't use either IP Masquerading or diald on any of my machines) > - The second problem does not depend on whether DNS bring the PPP > link up. If your IP address is dynamically assigned by you ISP and you > type "ftp ftp.debian.org" and the name lookup is returned by the local > DNS cache then the first packet on the network is the first packet > for the TCP conenction. But I noticed that in that case diald seems > to send the packet with the wrong source IP address, i.e. that of the > fake serial device instead of the one of the fresh new PPP connection. > Consequence the connection will never make it, you have to abort ftp > and restart it. This effectively prevents me from using diald with the > DES client. that sounds like a problem with either diald or IP masquerading...or possibly a routing problem. it seems unrelated to bind. have you tried putting a wrapper script around your des ftp client? send a couple of pings first, and then run ftp? craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .