The precedence used to determine which features are overridden during deployment is based on the order in which the features are written to the service configuration files.
The later a feature is deployed, the more precedence its settings have. For example, a DNS view is written before the zones below it. Therefore, setting in the zone overrides the setting in the view. For the same reason, an option in a sub-zone has precedence over an option in its parent zone.
Each level of an Address Manager configuration is deployed completely before the next level is deployed. Thus, all of the DNS views are written at the same time. Then, all of the zones for each of these views are written. The entire set of zones for a view is written before moving on to the next view. Because sub-zones are written after their parent zones, the more local options take precedence.
- Server roles
- Server options
- DNS views, including options and roles
- DNS zone and sub-zones, including options and roles
- Reverse DNS space based on IP allocations, including both DNS options and roles
The server role is used to filter out options that aren't compatible with the desired role for the server. If an option isn't compatible with the chosen roles for the server, it isn't written to the configuration. Use the Data Checker before deploying to catch this type of configuration error.
The first time a resource record within a resource record set is deployed, its TTL is
based on the TTL of the first loaded record in the set (that is, the record with
the lowest object ID). Resource record sets are records with the same label and type,
such as two separate TXT records for
my.example.com. When resource
records are later updated, they use the TTL from the last loaded record in the
set (the record with the highest object ID).