| Subject: | [PATCH] allow-notify does not take key (TSIG) IDs into account and refuses NOTIFY |
| Date: | Thu, 20 Feb 2014 07:35:57 -0500 (EST) |
| To: | bind9-bugs@isc.org |
| From: | Tomas Hozza <thozza@redhat.com> |
Hi.
Recently one of our customers run into a problem when trying to
configure allow-notify on slave server using a key ID (TSIG).
Even though the documentation says that the allow-notify statement
takes address_match_list [1], which enables the user to specify
"a key ID, as defined by the key statement", the key is ignored
in case of allow-notify and the NOTIFY is refused with:
Feb 20 09:10:05 client.example128.com named[1060]: zone example128.com/IN: refused notify from non-master: 192.168.122.1#14610
Feb 20 09:10:05 client.example128.com named[1060]: client 192.168.122.1#14610/key rndc-key: received notify for zone 'example128.com': TSIG 'rndc-key'
It happens on 9.9.4, but from what I checked in the source it should
happen also on 9.9.5.
[1] http://ftp.isc.org/isc/bind9/9.9.5/doc/arm/Bv9ARM.ch06.html#address_match_lists
I used configuration as follows (simplified):
1. master server with zone "example128.com",zone transfer allowed to "*"
and IP of 192.168.122.97
----------------------------------------------------------------------
2. slave #1 named.conf:
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; };
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
key "rndc-key" {
algorithm hmac-md5;
secret "RrOfPl0zTrLKkhChIsRV+w==";
};
zone "example128.com" IN {
type slave;
masters { 192.168.122.97; };
allow-notify {
key "rndc-key";
};
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
---------------------------------------------------------------
3. the slave #2 named.conf:
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
rate-limit {
responses-per-second 5;
window 10;
};
};
logging {
category query-errors {
info-log;
};
channel info-log {
file "data/info" versions 10 size 10m;
};
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
key "rndc-key" {
algorithm hmac-md5;
secret "RrOfPl0zTrLKkhChIsRV+w==";
};
server 192.168.122.225 {
keys { "rndc-key"; };
};
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
};
zone "example128.com" IN {
type slave;
masters { 192.168.122.97; };
notify explicit;
also-notify { 192.168.122.225; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
--------
slave #2 rndc.conf:
key "rndc-key" {
algorithm hmac-md5;
secret "RrOfPl0zTrLKkhChIsRV+w==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
When I call
# rndc notify example128.com
on slave #2 server, the slave #1 receives the NOTIFY, but refuses it with
the error message stated earlier.
The problem seems to be caused by the following code part in zone.c:11934
if (i >= zone->masterscnt && zone->notify_acl != NULL &&
dns_acl_match(&netaddr, NULL, zone->notify_acl,
&zone->view->aclenv,
&match, NULL) == ISC_R_SUCCESS &&
match > 0)
{
/* Accept notify. */
} else if (i >= zone->masterscnt) {
UNLOCK_ZONE(zone);
dns_zone_log(zone, ISC_LOG_INFO,
"refused notify from non-master: %s", fromtext);
inc_stats(zone, dns_zonestatscounter_notifyrej);
return (DNS_R_REFUSED);
}
when calling the dns_acl_match() and passing NULL for "reqsigner" (2nd argument).
I'm attaching a patch for zone.c that fixes the problem and enables allow-notify
to also accept key IDs. I tested it with previously described configuration and
it enabled the slave #1 to accept NOTIFY from slave #2 when the correct key was
used.
I'm looking forward for your response on this.
Thanks in advance.
Regards,
Tomas Hozza
Message body is not shown because sender requested not to inline it.