Dynamic update to the wrong DNS zone file - Bind View - dhcp-client-identifier - multiple network cards with multiple differents subnets

Simon Hobson dhcp1 at thehobsons.co.uk
Thu Apr 21 15:19:56 UTC 2011


>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";
>		}

Sorry, but I'm completely lost on what you are trying to achieve 
here. It appears you are confusing the use of a zone declaration to 
enable secure updates with the location of the zone declaration to 
control access.
I can't see any reason all your zone statements shouldn't be in the 
global scope and let the dhcp service work out which zone to update.

That is something separate to setting the domain name by scope.


>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;
>		};

Ditto, I'm not sure what you are trying to achieve here.


>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.

Sorry, but I really cannot follow that.

I'm going to take a bit of a stab in the dark and guess that you are 
trying to run three separate realms (for want of a better word), and 
have a different DNS view updated depending on the client that's 
connecting or it's location ?
If that is the case, then I cannot see any way you'd do that with one 
server. Zone definitions aren't dynamic.

I don't think you can use client access controls on the DNS server 
since all the updates will be coming from one address.

My suspicion is that you'd have to run multiple instances of DHCP - 
one for each realm.

But it would help enormously if you stated what you want to happen, 
not how you've tried (and failed) to do it.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.



More information about the dhcp-users mailing list