zone revision 816e576f77e2c46df3e3d97d65822aa8aded7c4b
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppoCopyright (C) 1999, 2000 Internet Software Consortium.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppoSee COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo $Id: zone,v 1.8 2000/08/09 04:37:29 tale Exp $
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo Zones are the unit of delegation in the DNS and may go from holding
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo RR's only at the zone top to holding the complete hierachy (private
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo roots zones). Zones have an associated database which is the
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo container for the RR sets that make up the zone.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo Zone have certain properties associated with them.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * master / slave / stub / hint / cache / forward
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * serial number
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * signed / unsigned
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * update periods (refresh / retry) (slave / stub)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * last update time (slave / stub)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * access restrictions
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * transfer restrictions (master / slave)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * update restictions (master / slave)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * expire period (slave / stub)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * children => bottom
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * rrsets / data
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * transfer "in" in progress
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * transfers "out" in progress
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * "current" check in progress
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * our masters
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * primary master name (required to auto generate our masters)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * master file name
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * database name
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * database type
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * initially only master_file (BIND 4 & 8)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * expanded axfr + ixfr
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * transaction logs
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * notification lists
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * static additional sites (stealth servers)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * dynamically learned sites (soa queries)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo Zones have two types of versions associated with them.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo The image of the "current" zone when a AXFR out is in progress.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo There may be several of these at once but they cease to need
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo to exist once the AXFR's on this version has completed. These
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo are maintained by the various database access methods.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo These are virtual versions of the zone and are required to
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo support IXFR requests. While the entire contents of the old
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo version does not need to be kept, a change log needs to be
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo kept. An index into this log would be useful in speeding
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo up replies. These versions have an explict expiry date.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo "How long are we going to keep them operationally?"
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo While there are expriry dates based on last update /
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo change time + expire. In practice holding the deltas
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo for a few refresh periods should be enough. If the network
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo and servers are up one is enough.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo "How are we going to generate them from a master file?"
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo UPDATE should not be the only answer to this question.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo We need a tool that takes the current zone & new zone.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo Verifies the new zone, generates a delta and feeds this
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo at named. It could well be part of ndc but does not have
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo Zones need to have certain operations performed on them. The need to
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * updated (UPDATE / IXFR)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * copied out in full (AXFR) or as partial deltas (IXFR)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * read from
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * validated
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * generate a delta between two given versions.
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * signed / resigned
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * maintenance
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo validate current soa
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo remove old deltas / consolidation
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo purge stale rrsets (cache)
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo * notification
1ae0874509b6811fdde1dfd46f0d93fd09867a3fheppo responding to
BIND 8.x.
Used if masters are not given in named.conf.
Used if masters are not given in named.conf.