Zone file got updated via named process unexpected
liudonghua at ynu.edu.cn
liudonghua at ynu.edu.cn
Sun Dec 17 04:30:37 UTC 2023
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 "刘东华" <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/03f1d1d1/attachment-0001.htm>
More information about the bind-users
mailing list