8.2.3-REL dynamic updates

shawn.ohail at firstunion.com shawn.ohail at firstunion.com
Sun Mar 25 06:18:49 UTC 2001

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
> 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
they intend to update and [] know or be able to determine the name servers
that zone". It also specifies that "If the requestor has reasonable cause
believe that all of a zone's servers will be equally reachable, then it
arrange to try the primary master server (as given by the SOA MNAME field
matched by some NS NSDNAME) first to avoid unnecessary forwarding inside
slave servers.".

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

Note that in BIND 9's nsupdate you can explicitly specify the server to
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
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
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 {; };
>      };

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

- Kevin

More information about the bind-users mailing list