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. 
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to