api level docs?

[Kevin Darcy]

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