force DDNS update

[Carl Karsten]

Simon Hobson wrote:
> Carl Karsten wrote:
> 
>>  >> But that will cause dhcp to remove an A record and allow the 
>> dhcp request that
>>>>  you describe: someone could name their client "server"...
>>>  Except that very few people use dynamic DNS updates to put their
>>>  important services into DNS - except Windows of course which seems to
>>>  live off DNS updates !
>>>
>>>  Even if you give servers their address by DHCP, it would normally be
>>>  a fixed address which by default would not trigger DDNS - hence
>>>  manually adding teh DNS records.
> 
>> So even more reason to add an option that turns off the "safety feature"
> 
> No, the point is that normally you would put fixed records into DNS 
> for your servers - and DHCP will NOT replace these.  If your user set
> their client name to "server" then the DDNS update would fail because 
> there would NOT be the correct key (TXT record) to go with the 
> existing A record.
> 
> The client could only take over DNS records for a client with 
> Dynamically set DNS records - as you've figured, fake a release 
> packet from the other device, set your client name to be the same as 
> the other device, go get a lease.
> 
> If you are really clever AND the other device doesn't respond to 
> pings, request the address you've just has released and take the 
> other device offline completely. If the other device does reply to 
> pings, I think you can do two discovers, one results in the address 
> being abandoned, the second will get it issued to you I think (just 
> going from something that came up recently).
> 

Um, you have drifted from your original scenario:

 >>> This is a
 >>> safety feature - otherwise someone could name their client "server"
 >>> and the DHCP server would happily replace the A record for you
 >>> important server of the same name with one that points to the client,
 >>> with the obvious effects on the network !

What I am saying is the safety feature can be worked around pretty easily:

Box1: hostname:server - DHCPREQUEST, gets 10.1.1.1, ddns sets server=10.1.1.1

other boxes resolve 'server" to 10.1.1.1 which is Box1

Box2: (rouge malicious) clone Box1's mac, hostname:server - DHCPRELEASE.  This 
causes ddns to remove the server=10.1.1.1 entry.

Box2: sets mac back to real mac, hostname:server - DHCPREQUEST, gets 10.1.1.2, 
ddns sets server=10.1.1.2.

other boxes resolve 'server" to 10.1.1.2 which is Box2.

So only Box1 has 10.1.1.1, but the dns entry not maps "server" to Box2's IP.

I do understand that "safety feature" is not security, it just helps keep 
missconfigured boxes from screwing up the rest of the network.

Carl K