api level docs?
Kevin Darcy
kcd at daimlerchrysler.com
Fri Jun 4 22:12:21 UTC 2004
Aaron Aston wrote:
>I am implementing split dns. The zones that I have to deal with
>include both internal and external resources, so I do not believe that
>'views' will help me.
>
>One of my requirements is that we maintain only a single dns
>'database'.
>
I'm not exactly sure what the requirement *means*, but it sounds pretty
unreasonable to me. After all, no matter how you implement it, by
definition split DNS means that the "database" that is visible to the
outside is going to be different from the "database" that is visible to
the inside, so right there you have more than one "database" right? What
*exactly* is your requirement? That a given zone have only a single
zonefile? What about include files? There are some games you could play
with that (e.g. chroot the internal and external nameserver instances
under different directories, link the main zonefile in the same relative
position under each directory, but with an $INCLUDE directive to a file
that is populated in the internal instance, zero-length in the external
instance).
>As a result, I need to parse and filter BIND zone files.
>
Maybe, maybe not. If you have a hard "single zonefile per zone, no
include file" requirement, then you may be stuck hacking the BIND code.
But you should avoid this if at all possible. Do you really want to be
up-porting your hack every time a new patch comes out?
>In particular, I need to strip out resource records which are
>'internal'.
>
How do you know that a record is "internal"? Is there something about
that name that makes it obvious? If so, why don't you go the next step
and create a separate subzone just for internal entries, e.g.
internal.example.com. Restrict query access so that Internet clients
can't query that zone, or just leave the zone entirely out of the
external instance.
By the way, how do you propose to handle the in-zone references to your
own nameservers? Are those entries considered "internal"? If you strip
them out, then you end up with a zone with no NS records, or
unresolvable NS records. That won't work. Or, do your external
nameservers respond on the same IP addresses as your internal
nameservers? If that's the case, I can't see how you're going to make
split DNS work in the absence of views. Or, are you going to have
*different* nameserver references in your internal and external DNS? If
that's the case, you've violated your own "single DNS database"
requirement. I'm not sure you've thought this through...
>The concensus seems to be that the best way to parse BIND zone files
>is to use the BIND C-libaries. This makes a certain amount of sense
>-- BIND knows how to parse it's one files, so use BIND to parse BIND
>files :).
>
I don't quite catch your drift here. Are you saying you want to hack the
BIND 9 source to read zone files in a "special" way? If so, then it
doesn't really matter whether parsing routine(s) are in a "C-library" or
not; they could just as easily be in the core code. Or, did you intend
to write a standalone utility that (to paraphrase what you said above)
"... strip[s] out resource records which are 'internal'", and writes out
the stripped version of the zonefile for the "external" instance to read
in normally? Doesn't that violate your "one zonefile per zone"
requirement? In any case, rather than write a standalone utility, why
not just use Perl, or sed, or awk, or some other text-processing utility
to do this, as other posters have suggested?
FYI, the main BIND 9 routine that parses zone files, is the "load()"
routine in lib/dns/master.c. It doesn't really lend itself to standalone
operation, as far as I can see, since it calls a whole bunch of other
BIND 9 routines to do its work.
>I took contrib/sdb/pgsql/zonetodb.c, removed the PGSQL calls, and
>implemented simple printf's of resource record data --- so I now have
>a tool that dumps (normalized) resource records.
>
Why did you hack zonetodb.c? You realize, hopefully, that this is not
part of the BIND 9 "C-library", but rather a utility to suck in a
zonefile and populate a PostgreSQL table with the data? It's part of the
overall PostgreSQL "sdb" driver which allows you to use PostgreSQL as a
database backend to BIND 9. I don't see that this is what you want at
all. The output of "zonetodb" is a PostgreSQL database, not BIND 9's
internal structures. How does this get you closer to your goal?
>My problem is this: I don't really understand the source. Where can
>I find documentation on BIND data structures and functions? From what
>I have read so far, the documentation is all "in the source" ... I
>just don't know where to start. In particular I'd really like to know
>what the default 'database' looks like in memory. eg: what is a
>'dns_rdataset' and what's in it?
>
I *really* don't think you want to be getting into the business of
translating zonefile data directly into BIND 9 internal structures. It's
extremely complicated stuff, and you'd basically be reinventing the
"load()" routine I mentioned above. If you *insist* on hacking the code
(and I'm trying to talk you out of that), I'd concentrate on the load()
routine. It's never going to be more than an ugly hack, however, unless
you somehow "parameterize" this filtering function through a "zone"
definition in named.conf and/or provide a way for the admin to call an
external function (e.g. Perl/sed/awk as mentioned above) to do the
filtering inline with the zone load. That would be quite a lot of work,
however...
- Kevin
More information about the bind-users
mailing list