force DDNS update

[Carl Karsten]

Simon Hobson wrote:
> Carl Karsten wrote:
> 
>>  > 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.
> 
> No, go back and read what I wrote !
> 
> IF (and only IF) you allow your servers DNS records to be done by 
> DDNS then this is true.

That is what you wrote, and it seems to be the only case for the safety feature. 
        The 'better way(s)' that you describe are not subject to the problem, 
and so the feature is of no use to those cases.   my point is the safety feature 
that causes grief may not be helping anyone.

> However, I think very few are likely to do 
> that - I certainly would not.

agreed.

> 
> If you assume that critical things like the DNS record for "server" 
> are done manually then it will NOT be possible to hijack it this way. 
> At my last job I didn't even allow dynamic updates to the zone 
> containing the server records - I had a separate zone 
> "clients.somedoamin.com".
> 

agreed.

> 
> So yes, if you are daft enough to use DDNS for critical records then 
> you leave yourself open to such attacks, if you don't then you don't. 
> This is not the only reason, there are others I can think of.

I can only speak for my case: the only attack would come from me misconfiguring 
something.  currently when I have a problem I just use the IP.  eventually 
things get worked out, and the problem goes away.  I am hoping to replace that 
problem with a smaller one that may not be a problem to me at all.  This may be 
the case for the others that had a similar situation.

Carl K