The third edition "DNS and BIND" books, from O'Reilly <http://www.ora.com> also goes into detail on how to do it. ----------------------------- Roeland M.J. Meyer Morgan Hill Software Company, Inc. http://staff.mhsc.com/~rmeyer mailto://rmeyer@mhsc.com ----------------------------- You can always tell the people that are forging the new frontier. They're the ones with flaming arrows sticking out of their backs and looking a little charred around the edges.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Andrew Brown Sent: Sunday, April 25, 1999 8:10 AM To: Phil Howard Cc: nanog@merit.edu Subject: Re: address spoofing
then, you can have (if you want) another bind listening on other interfaces for other stuff. like the "internal dns" server that you mentioned. or maybe a recursive, caching-only server that listens only on 127.0.0.1. of course...they can speak to each other if need be. :)
I tried 2 instances of BIND and they didn't work right. One functioned and the other played dead (very dead ... as in the process blocked and would not wake up). One needs 2 separate machines to get it to actually work right (times the amount of redundancy desired). If you know the magic to make it work right, I'd sure like to know. Maybe some kind of lock somewhere?
the trick is to tell them specifically to listen on different interfaces. if you don't do that, then they will collide. other things (such as a different query or forwarding port, a separate pid file, etc.) are also rather necessary.
i will attach a small shar file that paul vixie posted to the bind-workers mailing list a little over a year and a half ago that demonstrates exactly this.
-- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."