Multiple subnets across different vlans

[Simon Hobson]

Joshua Beard wrote:

>Another question, if I may ask without starting a new topic, and I 
>think I already know the answer.  Along with DHCP, I migrated DNS 
>from a Windows server to a Linux box running BIND.  I did a zone 
>transfer for this migration.  Things seem mostly happy, but a lot of 
>clients produce this in the dhcpd logs:
>
>Jul  9 01:38:06 ns1 dhcpd: Forward map from 
>MS40102S44572.dsdk12.schoollocal. to 172.30.133.41 FAILED: Has an A 
>record but no DHCID, not mine.
>
>Obviously, they were leased with the old dhcp server and their A 
>records were migrated in the zone transfer.  I'm using dynamic dns 
>updates here, and from what I've seen, these clients fail to get an 
>address if there's already a DNS record for them.  FWIW, this is a 
>k-12 school district and most everyone's gone for the summer, so if 
>I have to, I can just remove all of the DNS records for the dynamic 
>hosts.  Any suggestions here?

They will get an address, but won't get DNS records.

As a safety feature, the ISC server marks any records it creates by 
adding a TXT record with a hash of some information. When it comes to 
do an update, it will check the presence of this TXT record as a 
prerequisite, eg if it needs to update foo.bar.com to 1.2.3.4, it 
does :

If exists foo.bar.com TXT <some hashed value>
Then
   delete foo.bar.com A
   delete foo.bar.com TXT
   insert foo.bar.com A 1.2.3.4
   insert foo.bar.com TXT <some hashed value>
If <the above step worked>
   delete 4.3.2.1.in-addr.arpa
   insert 4.3.2.1.in-addr.arpa PTR foo.bar.com.

There have been requests occasionally to be able to turn off this 
safety test - but no-one has wanted it enough to sponsor making it 
happen. It would have to be configurable, since most people would 
want to keep things safe. Without it, a client could name their 
desktop "important-server", and next time they lease an address, the 
A record for your important-server would get changed to point to 
their machine. Even if they don't then use this for malicious 
purposes, it's still made the real important-server disappear from 
the network as far as clients are concerned.

The easy answer is to remove all the existing A records and wait for 
them to be repopulated. The tricky bit is that if there are clients 
that have had A records added by the ISC server, you'd need to edit 
their leases so that the server will re-add them at the next lease 
renewal.

>As far as the 'wrong network' goes, it sounds like I need to just 
>wait it out to clean itself up.

If your server is authoritative AND the setup matches your network, 
then it should be sending DHCP Nacks to the clients. It may be worth 
looking at a packet dump and see what is actually happening here.
Otherwise, the clients will sort themselves out as their leases 
expire and they are forced back to broadcasting DHCP Discovers.

On that, you haven't mentioned your network topology - in particular 
how the DHCP server is connected. Is it connected to a trunk, with a 
VLAN interface for each VLAN; or is it connected to one VLAN with a 
DHCP Relay Agent somewhere (possibly in the switch) to get DHCP 
packets from/to the other VLANs ? It is possible to misconfigure 
stuff so that a machine sees traffic it shouldn't and/or appears to 
be on the wrong VLAN.

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