force DDNS update

Simon Hobson dhcp1 at thehobsons.co.uk
Tue Apr 24 18:40:04 UTC 2007


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. However, I think very few are likely to do 
that - I certainly would not.

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


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.


More information about the dhcp-users mailing list