Bind9 dynamic dns update

On BIND 9 name servers, the name of the log file -- also called a journal file -- is the name of the zone data file concatenated with. So when you start using dynamic update, don't be surprised to see these files appear alongside your zone data files -- it's totally normal.

On a BIND 8 name server, the log files should disappear hourly though they may reappear very quickly if your name server receives lots of updates as well as when the name server exits gracefully. On a BIND 9 name server, the log files won't disappear at all. Both name servers incorporate the record of the changes in the log file into the zone if the log file exists when the name server starts. In case you're interested, BIND 8's log files are human-readable and contain entries like this:.

Well, not to these humans, anyway. Update Access Control Lists Given the fearsome control that dynamic updates obviously give an updater over a zone, you clearly need to restrict them, if you use them at all. In order to use dynamic updates, you add an allow-update or update-policy substatement to the zone statement of the zone that you'd like to allow updates to. The address or addresses matched by the list are the only addresses allowed to update the zone.

It's prudent to make this access control list as restrictive as possible:. If the primary master name server allows updates from its slaves' addresses, then any forwarded update will be allowed, regardless of the original sender. That's not good. Well, first, you can control which updates are forwarded. The allow-update-forwarding substatement takes an address match list as an argument. Only updates from IP addresses that match the address match list will be forwarded.

So the following zone statement forwards only those updates from the Special Effects Department's subnet:. If they're forwarded, the signature is forwarded with them. The signature, when verified, tells you the name of the key used to sign the update. The name of the key looks like a domain name, and it's often just the domain name of the host the key is installed on. With BIND 8. This mechanism uses the new update-policy zone substatement. It's meaningful only for primary master zones, since the slaves are expected to forward the updates.

The update is specified by the name of the key used to sign it and by the domain name and type of records it attempts to update. The types field is optional and can contain any valid record type or multiple types, separated by spaces except NXT. This is comparable to the way a policy zone is configured as a normal zone and also listed in a response-policy statement. Set up the member zone to be served on the primary as normal. This can be done by editing named.

Add an entry to the catalog zone for the new member zone. When the secondary receives the update to the catalog zone, it detects the entry for the new member zone, creates an instance of that zone on the secondary server, and points that instance to the primaries specified in the catalog zone data.

The newly created member zone is a normal secondary zone, so BIND immediately initiates a transfer of zone contents from the primary. Once complete, the secondary starts serving the member zone. The secondary server, on processing the update, notices that the member zone has been removed, stops serving the zone, and removes it from its list of configured zones.

However, removing the member zone from the primary server must be done by editing the configuration file or running rndc delzone.

Catalog zones are configured with a catalog-zones statement in the options or view section of named. This statement specifies that the zone catalog. This zone must be properly configured in the same view. In most configurations, it would be a secondary zone. Synonym for default-primaries. This option defines the default primaries for member zones listed in a catalog zone, and can be overridden by options within a catalog zone.

If no such options are included, then member zones transfer their contents from the servers listed in this option. This option, if set to yes , causes member zones to be stored only in memory.

This is functionally equivalent to configuring a secondary zone without a file option. A non-absolute pathname in zone-directory is assumed to be relative to the working directory.

This option sets the minimum interval between updates to catalog zones, in seconds. If an update to a catalog zone for example, via IXFR happens less than min-update-interval seconds after the most recent update, the changes are not carried out until this interval has elapsed.

The default is 5 seconds. Catalog zones are defined on a per-view basis. Configuring a non-empty catalog-zones statement in a view automatically turns on allow-new-zones for that view. This means that rndc addzone and rndc delzone also work in any view that supports catalog zones. A record stating the version of the catalog zone format is also required.

If the version number listed is not supported by the server, then a catalog zone may not be used by that server. Note that this record must have the domain name version. The data stored in a catalog zone is indicated by the domain name label immediately before the catalog zone domain.

Catalog zone options can be set either globally for the whole catalog zone or for a single member zone. Global options override the settings in the configuration file, and member zone options override global options. A simple primaries definition:. If multiple primaries are set, the order in which they are used is random.

Note: masters can be used as a synonym for primaries. A primaries with a TSIG key defined:. This option defines a primary server for the member zone with a TSIG key set.

The TSIG key must be configured in the configuration file. These options are the equivalents of allow-query and allow-transfer in a zone declaration in the named. The ACL is processed in order; if there is no match to any rule, the default policy is to deny access.

A member zone is added by including a PTR resource record in the zones sub-domain of the catalog zone. The record label is a SHA-1 hash of the member zone name in wire format. The target of the PTR record is the member zone name. For example, to add the member zone domain. The hash is necessary to identify options for a specific member zone.

The member zone-specific options are defined the same way as global options, but in the member zone subdomain:. Options defined for a specific zone override the global options defined in the catalog zone. These in turn override the global options defined in the catalog-zones statement in the configuration file. Note that none of the global records for an option are inherited if any records are defined for that option for the specific zone.

BIND 9 fully supports all currently defined forms of IPv6 name-to-address and address-to-name lookups. It also uses IPv6 addresses to make queries when running on an IPv6-capable system. However, authoritative BIND 9 name servers still load zone files containing A6 records correctly, answer queries for A6 records, and accept zone transfer for a zone containing A6 records.

Many applications in BIND 9 do not understand the binary label format at all anymore, and return an error if one is given. In particular, an authoritative BIND 9 name server will not load a zone file containing binary labels. Use of IPv4-in-IPv6 mapped addresses is not recommended.

When looking up an address in nibble format, the address components are simply reversed, just as in IPv4, and ip6. For example, the following commands produce a reverse name lookup for a host with address db :. BIND 9 latest. Introduction 2. Name Server Configuration 4.

Advanced DNS Features 5. Notify 5. Dynamic Update 5. The Journal File 5. Split DNS 5. TSIG 5. Generating a Shared Key 5. Loading a New Key 5. Instructing the Server to Use a Key 5. Errors 5. TKEY 5. SIG 0 5. Generating Keys 5. Signing the Zone 5. Converting From Insecure to Secure 5.

Fully Automatic Zone Signing 5. Private Type Records 5. Automatic Key Rollovers 5. Converting From Secure to Insecure 5. Periodic Re-signing 5. Dynamic Trust Anchor Management 5. Validating Resolver 5. Authoritative Server 5. Prerequisites 5. Building SoftHSMv2 5. Using the HSM 5.

Key Generation 5. Specifying the Engine on the Command Line 5. Running named With Automatic Zone Re-signing 5. Configuring DLZ 5.

Sample DLZ Module 5. Dynamic Database DynDB 5. Configuring DynDB 5. Sample DynDB Module 5. Catalog Zones 5. Principle of Operation 5.

Configuring Catalog Zones 5. Catalog Zone Format 5. Docs » 5. Note As a secondary zone can also be a primary to other secondaries, named , by default, sends NOTIFY messages for every zone it loads. Note None of the keys listed in this example are valid.

In particular, the root key is not valid. Note When the validator receives a response from an unsigned zone that has a signed parent, it must confirm with the parent that the zone was intentionally left unsigned. Here are the meanings of the different values of the first octet: algorithm octet 1 key id in network order octet 2 and 3 removal flag octet 4 complete flag octet 5.

Fetching example. The example sets up two zones, whose names are passed to the module as arguments in the dyndb statement: dyndb sample "sample. To use the catalog zone feature to serve a new member zone: Set up the member zone to be served on the primary as normal. IN SOA.

Unfortunately, there's very little software that supports TSIG-signed dynamic updates -- yet. If you allow dynamic updates to a zone, make sure the MNAME field of the zone's SOA record contains the domain name of the primary master name server; ideally, that's where updaters will send their updates. The allow-update and update-policy substatements are only meaningful in zone statements of type master, since you can only modify data on a zone's primary master name server.

Recipes Section 3. Previous page. Table of content. Next page. Authors: Cricket Liu. Network Warrior.