Dynamic Update Policy.....

Chris Buxton clists at buxtonfamily.us
Sun Mar 31 03:23:04 UTC 2013


On Mar 28, 2013, at 4:03 PM, Gary Greene wrote:

> I'm trying to get bind to use ddns updates for our environment, however I'm getting errors in the logs on the system that the host is being denied from making the changes.
> 
> Currently, I'm only allowing certain hosts to update their records, as a test.
> 
> The stanza for update-policy follows:
> 
>     zone "minervanetworks.com" {
>         type master;
>         notify yes;
>         update-policy {
>             grant ggreene-imac$@MINERVANETWORKS.COM ms-self * A;
>             grant cvallejo-w7-lt$@MINERVANETWORKS.COM ms-self * A;
>             grant cvallejo-test-w7-lt$@MINERVANETWORKS.COM ms-self * A;
>         };
>         file "/etc/named.d/minervanetworks.zone";
>         check-names ignore;
>     };
> 
> The error I see in the logs:
> Mar 28 15:57:29 ns1 named[11482]: client 10.5.1.11#52418: view internal: update 'minervanetworks.com/IN' denied

That log message is normal.

If you want to use GSS-TSIG, that's not going to work. I don't have a complete step-by-step of what's required, but at a minimum:

- Don't use ms-self.
- Do create a user account in AD with a service principal name that matches the hostname of the master name server as advertised in the SOA and NS records, prefixed by "DNS/". For example, "DNS/ns1.minervanetworks.com at MINERVANETWORKS.COM". Without this, GSS-TSIG will not be attempted.
- Do not be concerned by the denied update. Every attempt to update will go something like this:

1. SOA query for name to be updated, to recursion server.
2. Address lookup for server listed in SOA record, to recursion server.
3. Insecure DDNS update message to server listed in SOA record. [denied]
4. TKEY query to server listed in SOA record, to establish a single-use shared key.
5. Signed update message to server listed in SOA record. [approved or denied, according to policy]

> The reverse zones work, as they are setup to allow dhcpd to make the changes (and they work correctly), however the forward zone does not.

At a guess, you're not using GSS-TSIG for reverse record updates, correct?

Is there a reason not to have DHCP update the host records as well as the reverse?

Chris Buxton
BlueCat Networks


More information about the bind-users mailing list