Breaking apart large zone files.
Kevin Darcy
kcd at daimlerchrysler.com
Wed Nov 17 00:11:13 UTC 2004
Brian F. wrote:
>On one of our DNS servers we currently we have a zone file with
>2,195,387 entries. As you can imagine, this takes forever to reload,
>and really hammers the server resources during a reload.
>
>But i notice on other servers that don't have the large zone, but many
>small zones adding up to much more than the one large one. It doesn't
>eat up the resources or take as long to reload all the zones.
>
>Could this be fixed by way of breaking apart the large zone into
>several smaller files? What could be done to break apart a large zone
>file that is for a single domain?
>
>Would it make sense to break it apart as such:
>
>db.big.zone.net -- 2,195,387 entries
>broken into
>db.1.big.zone.net -- 250,000 entries
>db.2.big.zone.net -- 250,000 entries
>so on and so forth...
>
>then make a db.big.zone.net with something like this:
>
>$ORIGIN big.zone.net
>$INCLUDE db.1.big.zone.net
>$INCLUDE db.2.big.zone.net
>$INCLUDE db.3.big.zone.net
>
>Or am i way off in what i think include can do?
>I know this would be bad practice for a zone that needs maintenance
>just based on the fact that you'd have to search many files for your
>entry to make changes or deletes. But this big zone is script
>generated twice a day, and never needs any changes by hand. So
>changing the scripts to create several files could be easily done.
>
>Does it make sense to do this, or is there a better way?
>Should i just leave the zone alone and live with the pain?
>
I can't imagine that breaking the zone into separate *files* like that
is going to help your reload time or performance impact, since named
still needs to read in all of the data in all of the files on a reload.
Breaking the zone up into separate *subzones*, however, if the structure
of the zone permits it, should help matters, if your twice-a-day script
is smart enough to reload just the subzones that have changed, the
downside being that now all your slaves need zone definitions for all of
those subzones, and there'll be some additional serial-checking and
zone-transfer overhead incurred. Even if all of the subzones change
twice a day, you might be able to stagger the subzone reloads to
minimize the impact.
It might be best to have your script make its changes incrementally via
Dynamic Update -- then you shouldn't need any forced reloads at all.
- Kevin
More information about the bind-users
mailing list