Using an Oracle database within BIND 9.0.0.

[David R. Conrad]

Hi,

At 10:04 AM 11/18/2000 -0800, Greg Rumple wrote:
>I can speak from personal experience of running Bind 8 with over 100,000
>unique zones (7-10 records per zone), and can state that the startup
>time was painful.

Yes, I can imagine.  Are the records for the zone essentially the same 
(e.g., varying only in the RDATA of the A record and the label name)?  If 
so, BINDv9.1 has an example embedded Tcl SDB interface that would allow you 
to specify a Tcl program to generate "templated" zones on the fly (so you 
don't have to have them in your database).

>I do not have
>direct experience with this on Bind 9 yet, but it is only reasonable to
>estimate that even on a fast RAID subsystem, the act of opening and
>closing 100,000 file will take some time.

Right.  However, with BINDv8, the nameserver was deaf until all the zones 
are loaded.  With BINDv9, the nameserver is deaf only while it is 
re-reading the configuration file.  A v9 server will also be deaf to a 
particular zone while that zone is being read, but it will answer for all 
the other zones.

> > All root nameservers use BIND (various versions of BIND 8).
>Yup, keeping in mind that most of them load 1-10 zones (big zones never
>the less).

Actually, the root nameservers (F, for example) secondary for 6 zones (".", 
".arpa", "in-addr.arpa", "root-servers.net",  "gov", and "edu", the latter 
two which shouldn't be on the roots) and they are all pretty small (the 
in-addr zone file, by far the largest, has about 170,000 
delegations).  However, my point in referencing the root nameservers was to 
address concerns about the scaling of number of queries per second (half of 
F gets something like 6000 queries per second sustained last I check (but 
that was a while ago)).

> > BIND 9.1 will include a simplified database (SDB) interface with an 
> example
>So this is purely for the initial population of the in memory database?

No.  The data in kept in the database and extracted on demand.  We figure 
this will be helpful for folks who don't have a high query rate.

Rgds,
-drc