Dynamic update to the wrong DNS zone file - Bind View - dhcp-client-identifier - multiple network cards with multiple differents subnets
Kevin Darcy
kcd at chrysler.com
Thu Apr 21 21:15:28 UTC 2011
On 4/21/2011 10:17 AM, Flex Banana wrote:
> hello list,
>
> I use dhcpd-4.2.1 with bind-9.7.3 on a SuSE system.
>
> I have 3 network cards with under 700 differents subnets declared in the dhcpd.conf.
>
> eth0 = 10.1.1.50
> eth1 = 172.16.1.50
> eth2 = 192.168.1.50
>
>
> We use Dynamic DNS update with the dhcp-client-identifier option to set settings to my different clients.
> We also use Bind View to differentiate all differents zones with differents subnets (we have almost 90 zones)
>
> This is a part of our dhcpd.conf file:
>
> if substring (lcase (option dhcp-client-identifier), 1, 9) = "marketing"
> {
> option domain-name "marketing.example.com";
> option domain-search "marketing.example.com";
> zone marketing.example.com. { primary 10.1.1.50; key OUR_KEY; }
> }
> elsif substring (lcase (option dhcp-client-identifier), 1, 6) = "design"
> {
> option domain-name "design.example.com";
> option domain-search "design.example.com";
> zone design.example.com. { primary 10.1.1.50; key OUR_KEY; }
> }
> else
> {
> option domain-search "publisher.example.com";
> }
>
>
> Another part of dhcpd.conf with subnet declarations:
>
> subnet 10.1.1.0 netmask 255.255.255.0
> {
> option routers 10.1.1.1;
> range 10.1.1.20 10.1.1.199;
> option subnet-mask 255.255.255.0;
> option domain-name-servers 10.1.1.50;
> zone 1.1.10.in-addr.arpa. { primary 10.1.1.50; key OUR_KEY; }
> }
> subnet 172.16.1.0 netmask 255.255.255.0
> {
> option routers 172.16.1.1;
> range 172.16.1.20 172.16.1.199;
> option subnet-mask 255.255.255.0;
> option domain-name-servers 172.16.1.50;
> zone 1.16.172.in-addr.arpa. { primary 172.16.1.50; key OUR_KEY; }
> }
> subnet 192.168.1.0 netmask 255.255.255.0
> {
> option routers 192.168.1.1;
> range 192.168.1.20 192.168.1.199;
> option subnet-mask 255.255.255.0;
> option domain-name-servers 192.168.1.50;
> zone 1.168.192.in-addr.arpa. { primary 192.168.1.50; key OUR_KEY; }
> }
>
>
> This is a part of the named.conf file:
>
> view "10.1" {
> match-destinations { 10.1.1.50; };
> match-clients { 10.1.1.0/24; };
>
> zone "marketing.example.com" in {
> allow-update { key OUR_KEY; };
> allow-transfer { none; };
> file "dyn/marketing.exemple.com_10.1";
> type master;
> };
> zone "design.example.com" in {
> allow-update { key OUR_KEY; };
> allow-transfer { none; };
> file "dyn/design.example.com_10.1";
> type master;
> };
>
> view "172.16" {
> match-destinations { 172.16.1.50; };
> match-clients { 172.16.1.0/24; };
>
> zone "marketing.example.com" in {
> allow-update { key OUR_KEY; };
> allow-transfer { none; };
> file "dyn/marketing.exemple.com_172.16";
> type master;
> };
> zone "design.example.com" in {
> allow-update { key OUR_KEY; };
> allow-transfer { none; };
> file "dyn/design.example.com_172.16";
> type master;
> };
>
> view "192.168" {
> match-destinations { 192.168.1.50; };
> match-clients { 192.168.1.0/24; };
>
> zone "marketing.example.com" in {
> allow-update { key OUR_KEY; };
> allow-transfer { none; };
> file "dyn/marketing.exemple.com_192.168";
> type master;
> };
> zone "design.example.com" in {
> allow-update { key OUR_KEY; };
> allow-transfer { none; };
> file "dyn/design.example.com_192.168";
> type master;
> };
>
>
> The problem is that when i use a client in the others subnets than 10.1.1.0/24, all dynamics updates harent writed to the zone (marketing.example.com or design.example.com) with the primary address of 10.1.1.50 and a message of "Forward map from .... FAILED: Has an address record but no DHCID, not mine."
> And when you read the forward zone (e. g with nano or cat) the A adress is entered but from the wrong subnet.
>
> Example for the file desing.example.com_10.1 (zone dedicated
>
> laptop A 172.16.1.17 // updated dynamically
>
>
> The solution, i think, is to test the client (with dhcp-server-identifier ?) when DHCPDISCOVER message appaers and modify the statement "{ primary 10.1.1.50; key OUR_KEY; }" with { primary 172.16.1.50; key OUR_KEY; } and { primary 192.168.1.50; key OUR_KEY; } before DHCPREQUEST.
>
> How a do that ?
>
You have match-destinations *and* match-clients. Do you really need
*both*? Check your logs to see what the source address(es) of the
Dynamic Updates are.
- Kevin
More information about the bind-users
mailing list