Sorry for the mixed format. I updated the post here.
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.3
ynucdn 600 IN A 202.203.208.4
......
And this is the auto updated parts of that file.
$ORIGIN .
$TTL 86400 ; 1 day
ynu.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-http
65031141 CNAME www.itc
$ORIGIN 65031141.ynu.edu.cn.
ip-watcher A 113.55.13.114
kibana 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: enter
14-Dec-2023 14:39:25.460 general: debug 1: zone_maintenance: zone
ynu.edu.cn/IN/INTRANET: enter
14-Dec-2023 14:39:25.460 general: debug 1: zone_dump: zone
ynu.edu.cn/IN/INTRANET: enter
14-Dec-2023 14:39:25.460 general: debug 1: zone_settimer: zone
ynu.edu.cn/IN/INTRANET: enter
14-Dec-2023 14:39:25.460 general: debug 1: zone_gotwritehandle: zone
ynu.edu.cn/IN/INTRANET: enter
14-Dec-2023 14:39:25.460 general: debug 1: dumptostreaminc(0x7efe0d938010) new
nodes -> 212
14-Dec-2023 14:39:25.461 general: debug 1: dumptostreaminc(0x7efe0d938010) new
nodes -> 310
14-Dec-2023 14:39:25.464 general: debug 1: dump_done: zone
ynu.edu.cn/IN/INTRANET: enter
I did not configure master/slave mode of bind9. And I serached the sources of
bind9, but failed to find some keywords like zone_timer or zone_gotwritehandle.
I have stucked on this strange problem for a few days.
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 have also posted on stackoverflow, but without any response.
2023-12-17 12:04:18 "刘东华" <liudong...@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. --
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
