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