<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi list.</p>
<p>I've been trying to understand whether it is necessary for the
NOTIFY request (i.e. sent from primary to secondary server) to use
TSIG, in the case where the secondary server specifies a key in
its zone's "primaries" option?</p>
<p>For example, assume the following set-up:</p>
<p>The primary server (192.0.2.1) specifies the following
configuration:</p>
<blockquote>
<pre>key "secret-key.example.com" { ... };
zone "example.com" {
type primary;
file "/etc/bind/db.example.com";
notify yes;
allow-transfer { key "secret-key.example.com"; };
};
</pre>
</blockquote>
<p>And the secondary server (192.0.2.2) specifies:<br>
</p>
<blockquote>
<pre>key "secret-key.example.com" { ... };
zone "example.com" {
type secondary;
file "db.example.com";
<b>primaries { 192.0.2.1 key "secret-key.example.com"; };</b>
notify no;
};
</pre>
</blockquote>
<p>And if the zone file db.example.com (on the primary server)
contained:<br>
</p>
<blockquote>
<pre>$TTL 3600
@ IN SOA server1 root.server1 1 86400 7200 2419200 1800
@ IN NS server1
@ IN NS server2
server1 IN A 192.0.2.1
server2 IN A 192.0.2.2
</pre>
</blockquote>
<p>In this case when the zone is changed on the primary server, it
will send an <i>unsigned</i> NOTIFY to the secondary server. The
question I was trying to answer was: <i>With the configuration
above, will the secondary server accept the unsigned
notification?</i></p>
<p>I was hoping to find an RFC that answered this question, but
didn't have any luck Googling. However the BIND documentation for
"allow-notify"
(<a class="moz-txt-link-freetext" href="https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify">https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify</a>)
contains the following text:</p>
<blockquote>
<dl>
<dt class="sig sig-object namedconf"
id="namedconf-statement-allow-notify"><b>allow-notify</b><br>
...<br>
Defines an address_match_list that is allowed to send NOTIFY
messages for the zone, in addition to addresses defined in the
primaries option for the zone.<br>
...<br>
If not specified, the default is to process NOTIFY messages
only from the configured primaries for the zone. allow-notify
can be used to expand the list of permitted hosts, not to
reduce it.<br>
</dt>
</dl>
</blockquote>
<p>My interpretation of the above was that if a key is specified in
the "primaries" option, then the secondary would require the
NOTIFY to be signed by the same key? However when I tested this
theory, I found the secondary did accept (and process) the
unsigned NOTIFY.</p>
<p>While I understand (and agree) that this behaviour makes the most
sense, given my confusion based on the documentation, I wonder if
the documentation could be made clearer? E.g. Add the sentence:
"In the case where the primaries option specifies a TSIG key, it
is not necessary for the received NOTIFY to be signed by the same
key."<br>
</p>
<p>Thanks,</p>
<p>Nick.<br>
</p>
</body>
</html>