8.2.3-REL dynamic updates

[Kevin Darcy]

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