intelligent NAMED

[Dave Barr (鬼佬)]

On 6/26/07, Clenna Lumina <savagebeaste at yahoo.com> wrote:
> I believe this can be alleviated somewhat why having a "shared" zone
> file that's $INCLUDE'ed into all the view-specific zone files. That way
> data that needs to be consistent regardless of view doesn't need to be
> maintained redundantly.

Except this model falls apart when you have any significant number of
views serving any significant amount of zone data.  If you have 100MB
of zone data, and have 10 different views, suddenly you're using up
1GB of RAM.  Your zone load times go up dramatically too.

What you really want is overlays.  A way to simulate this with BIND is
to have a default view at the end that includes all your data, and
have many views that contains all your "viewed" data under individual
zone files.  (say, .v.example.com).  Define views for each of your IP
blocks, with "forward only" and "forwarders { 127.0.0.1; }".  Put your
default view zone at the end.

If you want to provide a viewed record for, say, www.example.com,
alias it to www.v.example.com in your main zone file.  Then in each of
your viewed zone files of v.example.com define www.v.example.com to be
whatever you want it for each netblock.

The downside of this is that queries from viewed netblocks will return
non-authoritative (cached) data even though the nameserver is
authoritative, since the query goes through a forward only cache for
records not in the view.  This can be an issue if propagation time is
important.  You'll need to turn down your default TTLs.  It's too bad
there's not a directive for "forward only" to disable caching.

I really wish BIND had a real mechanism for overlays.  IMHO views as
currently designed solve a problem few people really want.  What
people really want is a way to overlay one or more zones on top of
another base zone based on a view.  This model is far more flexible
and also solves the case where people want traditional views (where
your base zone is empty).

--Dave