Adding static DNS entries on a dynamic BIND setup

Question

I've got a DNS (BIND9) and DHCP (ISC-DHCP-SERVER) setup in which the DHCP server dynamically updates the DNS when hosts grab an IP address. I'm currently resubnetting a portion of my network that's not currently handled by DHCP and it's critical that clients can access the servers in this subnet. To avoid interruption to clients, I wish to create static entries pointing to various servers so clients can access them via their FQDN rather than IPs and once I change the subnet these servers are on (and the servers start grabbing DHCP addresses) the clients won't have to modify anything as the FQDN's will then point to the new addresses.

Since DNS is dynamically updated for the zone I cannot manually create records in the zone file since they'll just be overwritten. What I'm wondering is how could one create (permanent until removed) static entries in a dynamically updated zone? Right before the subnet changes, these entries would be deleted and then dynamically re-added by DHCP with the proper addresses.

Solution

To directly answer your question, there is no way of flagging a record for being read-only within a dynamic zone. (that I'm aware of at least)

Two workarounds:

1. If you're absolutely sure that the DNS clients won't overwrite your manually created records, you can use rndc freeze to write out the journal file and temporarily disable updates. You can then modify the zone, and re-enable the updates with rndc thaw. Problem is, you lose all dynamic DNS changes that fire during the freeze. You have probably considered this possibility and dismissed it already.
2. Ugly workaround: if you declare additional zones that are more specific than the dynamic zone (i.e. "zone foo.bar.com" is more specific than "bar.com"), each of those will take precedence over the less specific zone. Massive pain since it clutters up your config, and each of the zone files would need SOA and NS records in addition to the single A record.

Comments

[David W]

What about the idea of setting up reserved DHCP entries? Don't configure static IP addresses on the servers at all, but create reservations on the DHCP server for those machines? You can then obviously drop the TTL down for the DNS entries and then just update the DHCP reservations when you're ready to do the switch.

[Rauffle]

I had considered this but these servers all currently have static IPs and won't be using DHCP until after the subnet changes. I could create reservations now then switch all of the servers to DHCP but this will be too time consuming (lots of servers) and I'm strained for time as it is. Currently readdressing a number of VLANs and these servers will be the last to change over.

[Rauffle]

Thank you for the input. 1. I had considered something similar but realized it would not work for what I'm trying to accomplish. 2. Unfortunately this won't work either as the servers will be in the same 'bar.com' zone as the clients and putting them in a subdomain will go against the naming structure I have to work with.

[Andrew B]

RE: 2, the names and answers would be unchanged from a client perspective. The new zone would have a single A record of "@". So if you had a "foo" record in "bar.com", you'd have a "@" record in "foo.bar.com". Like I said, it's a very ugly hack but it would do the job.

[Rauffle]

To make sure I understand what you're getting at: Are you saying to create a zone with a single '@' record for each host I wanted to 'statically' add?

[Andrew B]

Bingo. It's ugly because you end up with N additional zone declarations and zone files, where N is the number of records you need to add in this fashion.

[Rauffle]

I didn't expect the solution for this to be too pretty :) Sounds like exactly what I'm trying to accomplish, just done in a different fashion than I expected.

[Andrew B]

Also, by "single A record" I meant that it would be the only A record. As stated in the answer, you would still need a SOA record and your standard NS records in each of these zones. Those can be identical between each of the zone files at least. (if you define the SOA+NS records as @)