when using nsupdate to add records the new record is added as static record. as far as I understand this is because in source4/dns_server/dlz_bind9.c b9_parse does not set rec->dwTimeStamp. This results in rec->dwTimeStamp being 0. 0 means "static" somewhere later there is a call to dns_name_is_static that would suggest that dwTimestamp is set if it is not a static record, but since dns_name_is_static only checks if ONE record has a dwTimeStamp that is 0 (there will always be one if it is a new record, the b9_parse'd one) or it is a SOA record, this will always return true I think this can be fixed by replacing if (dns_name_is_static(recs, num_recs)) { rec->dwTimeStamp = 0; } else { rec->dwTimeStamp = unix_to_dns_timestamp(time(NULL)); } with rec->dwTimeStamp = unix_to_dns_timestamp(time(NULL)); if (dns_name_is_static(recs, num_recs)) { rec->dwTimeStamp = 0; } if recs is really static there will be a rec that has dwTimeStamp==0 and the new rec->dwTimeStamp will be also set to 0 (=static).
sorry, the bug report is not precise and I was fooled a bit the issue can be triggered by: update add rec.domain.test 300 IN A 1.2.3.4 -> now a dynamic record is added update delete rec.domain.test -> now the record is deleted update add rec.domain.test 300 IN A 1.2.3.4 -> now the record is static the proposed changes would fix this issue. I am currently not sure why this happens I think there is a tombstoned entry, but this should be ignored explicitly by dns_name_is_static
I think I found the issue. dns_name_is_static(recs, num_recs) is called with the incremented num_recs but the new record is not appended yet. This means the memory is probably not initiallized (talloc_realloc does not zero the memory, else it would probably work since wType would be 0 =DNS_TYPE_TOMBSTONE)
Created attachment 17262 [details] patch
The current meege request is https://gitlab.com/samba-team/samba/-/merge_requests/2491 which includes Michael Saxl's patch attached here, along with tests, a related fix for the case where a record is being replaced.
This bug was referenced in samba master: 247a39bba046da0a507303a3b58db71ddd10fe0e 9b47d818d04811afac9e4d34b0050c427112fb70 5d89c90ab45bdf0cc2236f71c02b05208fd715f3 937c2cd38a6365924e0eaaa34b60815eced6126c d0d18934fa0660f85225f6a9387a4583f77bb780 aae689945369cc47574a7cf90faa0e2f20b5b504 590d2e169c4538a41ed1cd99f5cf72f4b6e6e424 f1017c6f2dd136d1654a8ed3734721fc8f3c5b82
Closing, as it seems neither I nor anybody else felt enough urgency to backport. The fix is now in 4.17 and 4.18rc1, and the window for a 4.16 port is narrowing daily.