>If BIND could be modified to deliver different results depending on the
>source of the request, or it's interface, then it might become easy for
>people to setup DNS to avoid this.
not running a current bind, eh?
the 8.x.x series bind dynamically picks up and drops interfaces as
they appear and disappear, and can be told on which interfaces to
listen. so...you can actually have a publicly available,
non-recursive name server to answer the queries for the zones for
which you need to be authoritative on the interface(s) to which those
zones are delegated.
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?
> 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?
Works great here. You need to make sure that each bind instance has its
own set of named.conf/zone files/pid file/ndc channel, that they bind to
different interfaces. I also like to force them to have different query
ports, but this shouldn't be necessary as long as they are on different
interfaces.
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.
