Report information
The Basics
Id:
45495
Status:
open
Priority:
Medium/Medium
Queue:

BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
(no value)
Severity:
(no value)
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)

Dates
Created:Fri, 30 Jun 2017 19:52:43 -0400
Updated:Mon, 23 Oct 2017 20:37:09 -0400
Closed:Not set



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

From: "Simon Ferrett" <sferrett@slacker.com>
Date: Fri, 30 Jun 2017 23:52:39 +0000
Subject: 9.11.1-P2, 9.10.5-P2 - "key" option for also-notify/masters broken when using masters name
To: bind-bugs@isc.org
Bug Report from www.isc.org: Name: Simon Ferrett Email: sferrett@slacker.com Software Version: 9.11.1-P2, 9.10.5-P2 OS: linux (centOS 6) Subject:"key" option for also-notify/masters broken when using masters name Bug Detail =========== From the configuration reference: also-notify [ port ip_port] [ dscp ip_dscp] { ( masters | ip_addr [ port ip_port ] ) [ key key_name ] ; ... } ; In my configuration the following works: view test { allow-recursion { any; }; zone "myzone.example" { type master; also-notify { 1.1.1.1 key trusted-key; }; file "trusted/db.myzone.example"; }; }; But the following fails (ie: if I use the name of a masters config rather than an IP address in the also-notify section): masters mlist { 1.1.1.1; }; view test { allow-recursion { any; }; zone "myzone.example" { type master; also-notify { mlist key trusted-key; }; file "trusted/db.myzone.example"; }; }; 30-Jun-2017 16:43:59.070 /home/dns-master/data/conf/qs.conf:12: unexpected token 'trusted-key' The failing config works with version 9.10.3-P2 however... so when I upgraded my configs that were using masters by name and tsig keys (in "also-notify" and "masters" zone options) began failing with "unexpected token" Thanks- Simon. --- This email was received through isc.org Bug Submission Form
Thank you for the report (and sorry for the slow reply). I'll look into this.
From: "Simon Ferrett" <sferrett@slacker.com>
Date: Wed, 12 Jul 2017 00:20:49 +0000
Subject: RE: [ISC-Bugs #45495] 9.11.1-P2, 9.10.5-P2 - "key" option for also-notify/masters broken when using masters name
To: "bind9-confidential@isc.org" <bind9-confidential@isc.org>
No problem - please let me know if there's any other detail I can provide to assist. Cheers, Simon. -----Original Message----- From: Evan Hunt via RT [mailto:bind9-confidential@isc.org] Sent: Tuesday, July 11, 2017 4:53 PM To: Simon Ferrett Subject: [ISC-Bugs #45495] 9.11.1-P2, 9.10.5-P2 - "key" option for also-notify/masters broken when using masters name Thank you for the report (and sorry for the slow reply). I'll look into this.
This appears to have been introduced in commit aa49af836, which added a correctness check to also-notify clauses that hadn't been there before. What I haven't worked out yet is whether the code is correct and that also-notify statement is invalid (in which case the doc should be fixed), or whether the also-notify statement is valid and the code is being overly restrictive. The fact that it was accepted by earlier versions of named doesn't necessarily mean it was working correctly at the time. I'll keep looking.
Subject: RE: 9.11.1-P2, 9.10.5-P2 - "key" option for also-notify/masters broken when using masters name [ISC-Bugs #45495]
To: "bind9-confidential@isc.org" <bind9-confidential@isc.org>
Date: Wed, 12 Jul 2017 17:03:21 +0000
From: "Simon Ferrett" <sferrett@slacker.com>
Sounds good - In my configuration, the intent of including the key in the 'also-notify' section in a view on the master server is so that the notify messages being sent from master to slave correctly tell the slave which view needs refreshing (by tagging the notify with the view's tsig). It appears to work as I expected, however it's possible something else in my configuration is causing the correct behavior and including the key in the 'also-notify' is superfluous. It was curious that with the latest version if I put the IP address of the master (rather than the name) in the also-notify, the 'key xxx' was allowed, so there's a little ambiguity in the current behavior, aside from the documentation maybe being incorrect. Anyhow, thanks again for the feedback - Cheers, Simon. -----Original Message----- From: Evan Hunt via RT [mailto:bind9-confidential@isc.org] Sent: Tuesday, July 11, 2017 5:52 PM To: Simon Ferrett Subject: 9.11.1-P2, 9.10.5-P2 - "key" option for also-notify/masters broken when using masters name [ISC-Bugs #45495] This appears to have been introduced in commit aa49af836, which added a correctness check to also-notify clauses that hadn't been there before. What I haven't worked out yet is whether the code is correct and that also-notify statement is invalid (in which case the doc should be fixed), or whether the also-notify statement is valid and the code is being overly restrictive. The fact that it was accepted by earlier versions of named doesn't necessarily mean it was working correctly at the time. I'll keep looking.