0

I am using BIND 9.18 for testing purpose. I create a zone which supports dynamic DNS, and I try to use nsupdate to update the domain's resource record. After 15 minutes the update is successfully written into the original zonefile. However, when I use dig to query the domain and the response didn't change. Then I shutdown named , restart it and use dig to query the domain again, and the response shows the update. I try to manually update the zonefile using rndc and the result is the same--the zone file is successfully updated but the update is only visible to dig after I restart the bind9.

My question is, do I have to periodically restart the bind9 to make updates visible to queries?

Thank you!

dofar21
  • 3
  • 2
  • 1
    The 15 minute delay is expected because [dynamic updates get initially stored in the journal before the zone file gets updated](https://serverfault.com/a/937850/37681). But it shouldn't require a Bind restart for dynamic updates to become effective, they should become effective immediately AFAIK – HBruijn Jul 17 '23 at 14:04
  • @HBruijn Thanks! What does "an update become effective" mean? I think it means that the update is written into zone files. However, it seems that BIND9 only reads zone files when it starts, therefore BIND9's response may be inconsistent with the updated zone files, and BIND9 needs to restart to reload these files. I try to read the code of BIND9 to confirm my assumption but the code is a little bit hard for me :D – dofar21 Jul 17 '23 at 14:16
  • This is not a normal behaviour. Please, show exact commands you are using (nsupdate, dig), configs and BIND log entries corresponding to update events. – Nikita Kipriyanov Jul 17 '23 at 18:23
  • It turned out this question is about adding a new type of the RR, which causes the problem; standard RR types work as intended. The question is about *development* and belongs to StackOverflow rather than here. – Nikita Kipriyanov Jul 18 '23 at 08:46

1 Answers1

0

As @HBruijn noted, dynamic updates are first stored in the journal and are not written immediately into the zone file. So, it is wrong to check an update is applied by viewing the zone file.

Instead, you should query it via DNS (use dig, host and so on) immediately after you did successful send in nsupdate. You will see it is already serving the updated/new data, despite the fact zone file is not yet rewritten. (You may need to direct a client to your server, to avoid caches of intermediate resolvers.) You may also notice in logs that it propagates the change to slave servers immediately after update arrived. Dynamic DNS update is instantaneous.

Textual zone file is ill-suited for quick updates. Such an update requires a full file rewrite. Imagine a server which receives a solid update stream to a big zone — it would be big waste to rewrite a zone file each time. That's why it caches recent updates into zone journal, and applies a journal only periodically. This is like a corrections/errata page at the end of the book: when the book body is already done it is costly to reprint the whole issue, so they add additional page which says where and what and into what should be changed for the book to be correct. And only on the next issue they actually incorporate these corrections into the text.

You can, however, send a command to it to apply journal right now and rewrite zone file:

rndc sync -clean zone.name

Don't do this too often; this is suboptimal. Don't worry about journal and non-immediate zone file update, mind your business (dynamic updates) and let BIND to do its work the way it prefers, without micromanagement.

Nikita Kipriyanov
  • 10,947
  • 2
  • 24
  • 45
  • Hi, thanks for your explanation! My experiment is trying to add support for a new type of resource record which is defined by myself. I try to update other resource types (such as A, AAAA) and BIND9 responds the same as your description. So the conclusion is that my implementation of new resource record causes this problem. I may have to add some updating logic for my record. I am currently investigating. Thank you! – dofar21 Jul 18 '23 at 08:12
  • Besides, I add my resource type according to this BIND 9 document [link](https://kb.isc.org/docs/aa-01140). Following these steps can make BIND 9 to resolve my new resource record correctly, but it seems not enough for updating correctly. :D – dofar21 Jul 18 '23 at 08:16
  • This is the most important. I wonder why didn't you explained this from the very beginning. I think, since this happened to be a development question, it is offtopic here, but well suited for StackOverflow. – Nikita Kipriyanov Jul 18 '23 at 08:43
  • That said, I'm afraid the problem is with *caching*. AFAIK BIND load everything into memory and serves data from memory; if you want your dynamic update to have immediate effect (without restart) you need to update in-memory value too. – Nikita Kipriyanov Jul 18 '23 at 08:52
  • This is weird, because updates of other types like A and AAAA have immediate effect, if the problem is caching it should affect other types. What I only did is adding my definition files in `lib/dns/rdata/generic`. (My resource record is very similar to TLSA record so even most of my contents are copied from `tlas_52` :D) The journal file is correctly written so I think the problems may be parsing journal files. – dofar21 Jul 18 '23 at 09:20
  • A more interesting thing is, I add some resource record of my own type (NewRR) , and I wait for about 15 mins until the zone file is modified by BIND, then I shut down and restart BIND. I try to query BIND for NewRR records but it still shows me the version of the zone file before my updates! – dofar21 Jul 18 '23 at 11:58
  • Hi, I find the problem. I defined my new RR type using private ID (65520-65535), and nsupdate doesn't allow dynamic updates for private resource records. I use a new ID and the problem disappears. Thanks for your help! – dofar21 Jul 18 '23 at 15:24