Description of problem: $ rndc addzone junk.local. '{ type master; file "/path/to/junk.local.zone";};' This yields an xxx.nzf file with zone "junk.local" { type master; file "/path/to/junk.local.zone";}; NOTE: The trailing dot from the domain name has removed $ dig @localhost junk.local. ANY this shows the SOA and NS record Then $ rndc delzone junk.local. This silently fails. dig shows the SOA and NS records, and the zone is still listed in the xxx.nzf file. However $ rndc delzone junk.local Works - removed from xxx.nzf and from DNS I think the behavior should be consistent - both addzone and delzone should work with the DNS standards compliant trailing dot, or both should refuse to accept a zone with a trailing dot. It is confusing that a trailing dot should be accepted by addzone (and silently stripped), but a trailing dot should not be accepted by delzone. Version-Release number of selected component (if applicable): Fedora 20, bind-9.9.4-12.P2.fc20 How reproducible: Always Steps to Reproduce: 1. Setup named with an rndc key and allow-new-zone yes; 2. Add a zone using rndc addzone test.local. 3. rndc delzone test.local. will fail to remove the zone from DNS rndz delzone test.local will succeed Actual results: Expected results: rndc delzone test.local. should strip the trailing dot Additional info: This may be a bug in bind9 version 9.9. With bind9 version 9.8 on ubuntu, the trailing dot is preserved in the xxx.nzf, and delzone with the trailing dot works.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Moving to rawhide. Still the case in bind-9.10.2-1.fc22.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
The problem is, that on line 9307 in server.c (znamelen = strlen(zonename);) strlen(zonename) takes length with trailing dot and then it comparse if (strncasecmp(buf, "zone", 4) != 0) { - propably on line 9362 with name without trailing dot from file (3b65xxxx.nzf).
(In reply to Spáčil Michael from comment #4) > The problem is, that on line 9307 in server.c (znamelen = strlen(zonename);) > strlen(zonename) takes length with trailing dot and then it comparse > > if (strncasecmp(buf, "zone", 4) != 0) { - propably on line 9362 > with name without trailing dot from file (3b65xxxx.nzf). Thank you for the investigation Michael.
Created attachment 1141188 [details] Proposed patch I added proposed patch which fixes bug with delzone.
(In reply to Zdenek Dohnal from comment #6) > Created attachment 1141188 [details] > Proposed patch > > I added proposed patch which fixes bug with delzone. I reviewed the patch. It has two issues: 1. It would break the existing behavior, that delzone would not work in case the name does not contain the trailing dot. 2. znamelen is later used for comparison in strncasecmp() call. In case a name of length "1" would be passed to delzone, znamelen would be decremented to "0" and the following comparison using strncasecmp() would return that the zone name matches basically anything, because zero characters would be compared.
Created attachment 1147699 [details] Proposed patch Proposed patch to fix this bug.
Created attachment 1148123 [details] Updated proposed patch with extending test cases in addzone test
Created attachment 1150857 [details] Proposed patch#3
The problem in this bug is, as Michael found out, a comparison of dns name with dot from command line and string from file with dynamically added zones. Bug doesn't appear if delzone command is with dns name without dot, because the solution in function ns_server_delzone uses length of string from CL's dns name and compares string from CL's dns name and substring from string representing contents of file with string's length of CL's dns name. But this approach fails with CL's dns name with dot, because dns name from file with dynamically added zones is without a dot and ends with character '"', so result of previously mentioned comparison is false (zone. != zone"). Key to solve this bug is to correctly read from file and compare with dns name from CL. I wrote a finite state machine for reading, because there is possibility of appearance of character '"' in dns name, so I have to check a previous character to find out, if '"' means end of dns name or if there is escaping character '\' in previous character of string. After that I create structures representing dnsname from strings (it covers stripping of dot), because function dns_name_compare in bind does deeper comparison than string comparison (compares number of labels etc.). But this solution treated two dns names with same names but different cases as two different dns names (this is wrong behaviour), so I used flag DNS_NAME_DOWNCASE in dns_name_fromstring function call, which makes all string's characters downcase. To verify my solution, I created tests, which checks results of CL input combinations.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Zdenek, what is the status of this? Did you ever sent the patch to the upstream? Or even the bug report?
No, I only added patch as an attachment in bugzilla. I did not report it to upstream. We had agreement you will review that patch, but we did not talk about what to do next. Should I report it now?
I checked it in rawhide, where bind's version is bind-9.11.0-2.P1, and bug is not there anymore. Closing this bug as RAWHIDE.