Zone file got updated via named process unexpected

[liudonghua at ynu.edu.cn]

Hi, I have a bind9 service running on the server, and some views configured, but I found a zone file got updated unexpected when I made some resolve changes.

Here is parts of the original contents of the updated zone file.

$TTL 86400      ; 1 day@       IN      SOA     pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (                                2019091901    ;   serial number                                10800   ;   Refresh interval, every 3 hours                                3600    ;   Retry interval, every 30 minutes                                 604800  ;   Expire after 1 week                                86400 ) ;    Minimum TTL of 1 day$INCLUDE /etc/named.data/db.ynu.edu.cn.common; RR of type A; lb-http-jz                      IN  A       113.55.14.52; vpn1                    10800   IN  A       192.168.208.3ynucdn                  600     IN  A       202.203.208.4......

And this is the auto updated parts of that file.

$ORIGIN .$TTL 86400	; 1 dayynu.edu.cn		IN SOA	pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. ( 2019091903 ; serial 10800      ; refresh (3 hours) 3600       ; retry (1 hour) 604800     ; expire (1 week) 86400      ; minimum (1 day) )$ORIGIN ynu.edu.cn.100			CNAME	lb-http65031141		CNAME	www.itc$ORIGIN 65031141.ynu.edu.cn.ip-watcher		A	113.55.13.114kibana			CNAME	lb-http.ynu.edu.cn.portainer		CNAME	lb-http.ynu.edu.cn.$ORIGIN ynu.edu.cn._cdnauth		TXT	"2023060823081361d03c617f075ac05df69f6309bd9aa6"access			A	113.55.0.80......

The update contents contain some $ORIGIN seems to produced via named process.

The related pieces of named.conf configurations is:

......view "INTRANET"{        match-clients { INTRANET_ACL;};        recursion yes;        include "/etc/named.common.zones.conf";        zone "ynu.edu.cn" in {                type master;                file "db.ynu.edu.cn.intranet";        };};......

And I found some general logs maybe provide some clues.

14-Dec-2023 14:39:25.460 general: debug 1: zone_timer: zone ynu.edu.cn/IN/INTRANET: enter14-Dec-2023 14:39:25.460 general: debug 1: zone_maintenance: zone ynu.edu.cn/IN/INTRANET: enter14-Dec-2023 14:39:25.460 general: debug 1: zone_dump: zone ynu.edu.cn/IN/INTRANET: enter14-Dec-2023 14:39:25.460 general: debug 1: zone_settimer: zone ynu.edu.cn/IN/INTRANET: enter14-Dec-2023 14:39:25.460 general: debug 1: zone_gotwritehandle: zone ynu.edu.cn/IN/INTRANET: enter14-Dec-2023 14:39:25.460 general: debug 1: dumptostreaminc(0x7efe0d938010) new nodes -> 21214-Dec-2023 14:39:25.461 general: debug 1: dumptostreaminc(0x7efe0d938010) new nodes -> 31014-Dec-2023 14:39:25.464 general: debug 1: dump_done: zone ynu.edu.cn/IN/INTRANET: enter

I can confirm that I did not use or configure master/slave mode of bind9.

I found this zone file got updated in about 15 minutes when I made changes or restarted named, and this behavior seems match the docs bind9.readthedocs.io/en/latest/chapter6.html#dynamic-update, but I can confirm I DO NOT configure allow-update or update-policy. I even add "allow-update {none;}; // no DDNS by default" in the zone block of the problematic view. Is there any chances this configuration comes from other config file or named build options?


I also have posted on stackoverflow, but without any response. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231217/c377b05a/attachment-0001.htm>