8.2.3-REL dynamic updates

[shawn.ohail at firstunion.com]

That all make sense. Thanks for the reply...

shawn.ohail at firstunion.com wrote:

> I really hope this hasn't been asked too many times. I've searched the
> archives and found nothing relevant to 8.2.3-REL (Sol7)
>
> I'm trying to get dynamic updates to work with a stealth master and
> TSIGs...
>
> updates work when the master _is_ listed in the NS records, but fail when
> removed.

BIND 8 nsupdate only uses the SOA and NS records for the zone to determine
where to send the update.

> I thought the client was suppsed to send the update to the server listed
in
> the SOA? Instead I'm seeing it get sent to one of the
> slaves.

What the RFC (2136) expects is that the requestor "know the name of the
zone
they intend to update and [] know or be able to determine the name servers
for
that zone". It also specifies that "If the requestor has reasonable cause
to
believe that all of a zone's servers will be equally reachable, then it
should
arrange to try the primary master server (as given by the SOA MNAME field
if
matched by some NS NSDNAME) first to avoid unnecessary forwarding inside
the
slave servers.".

BIND 8's nsupdate only implements the "determine[s] the nameservers for
[the]
zone" of the RFC by doing SOA and/or NS queries. If your master isn't in
the
NS records, BIND 8's nsupdate can't find it.

Note that in BIND 9's nsupdate you can explicitly specify the server to
which
to send the update.

> When the slave is not configured with the KEY and allow-update clauses it
> returns a NOTAUTH

That's correct behavior, per the TSIG RFC (2845). Note that RFC 2845
"redefines" NOTAUTH to mean "not authorized" in this context, instead of
its
usual meaning of "not authoritative". Grrrrrrr......

> When configured with KEY and allow-update, returns NOTIMP.

That's because update forwarding is not implemented in BIND 8. If you need
update forwarding, you'll need BIND 9. Although, I'm not exactly sure how
update forwarding would work with a hidden master (does it use the contents
of
the master { } clause or what?)

> I'm assuming that to allow the slave to forward updates to the master it
> needs KEY and allow-update.
>
> MASTER config:
>      key foobar.com   { algorithm hmac-md5; secret "XXXX"; };
>
>      zone "foobar.com" in {
>              type master;
>              file "primary/foobar.com";
>              notify yes;
>              allow-update { key foobar.com; };
>      };
>
> SLAVE config:
>      zone "foobar.com" in {
>              type slave;
>              masters { 192.168.1.36; };
>      };

No, if update forwarding worked, then the slave shouldn't need the TSIG
key.
It's just passing the request onto the master, and passing the response
back.
It's up to the master to validate the signature.


- Kevin