Mark Andrews schrieb:
You can do it either way or a mix. Which way you do it depends on
if you are assigning names or not. If you want all the client
machines to live in forward domains you choose then I would have
the DHCP server update both the forward and reverse zones. If you
let the client machines choose their own name then they should be
updating their own forward zones and the DHCP server updates the
reverse zone.
On the bind side you generate a TSIG key which you share with the
DHCP server. You then add allow-update clauses to the appropriate
zones to say that if named receives a update signed with that key
that it should accept it.
e.g.
key "dhcp-server-key" {
algorithm "hmac-sha256";
secret "xxxxxxxxxxxxxxxxxxxxxxxx";
};
zone "1.168.192.in-addr.arpa" {
type master;
...
allow-update { key dhcp-server-key; };
};
If the clients are updating the forward zone themselves then you
can distribute TSIG keys or use SIG(0) to allow them to update their
own records. For this I would use the finer grain controls in
update-policy.
e.g.
key "foo.example.com" {
algorithm "hmac-sha256";
secret "xxxxxxxxxxxxxxxxxxxxxxxx";
};
zone "example.com" {
type master;
...
allow-policy { grant *.example.com self . A AAAA; };
};
Because my Clients have a fixed Name, the only way is that they have to
request a Forward-Update by themeselves?
Therefore i need the <allow-policy> statement, but without key on the
client? Is that not risky? And how do i have to modify
/etc/dhcp3/dhclient.conf ?
Ok, and DHCP updates the Reverse-Zone automatically or when does he do
it? How will the Reverse-Zone Update be initiated in this case?
regards Markus
Do i have to give the
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
