BIND 8.2.x interaction with DHCP servers

joecwell at us.ibm.com joecwell at us.ibm.com
Tue Jun 27 19:40:03 UTC 2000


Andreas ...

> >
> >  My understanding is that the few people who are doing this put
> > both DHCP and BIND on the same machine, and disallow updates from
> > anywhere else.  This allows them to do them "relatively" securely,
> > even though the protocols themselves are inherently insecure.
>
> The problem of authenticating the dynamic update requests between DHCP
> servers and DNS servers should be solved by using TSIG, which is
> supported by both BIND 8 and BIND 9.
>
> The DHCID RR is intended to solve a different problem.  Its purpose is
> to identify the DHCP client that requested the dynamic creation of a
> given domain name, to allow the DHCP server(s) to distinguish the case
> where a DHCP client requests a domain name that is already taken by
> another client from the case where a client just re-requests the name
> it already has.  It is not a security mechanism, just a mechanism for
> distributed bookkeeping among the DHCP servers.

I agree with your response to Brad's note that running DHCP
and DNS on the same server does nothing to prevent the
problems that DHCID RR is intended to prevent. But, I'm not
sure saying that it is not a security mechanism is correct.
Fooling DHCP is a very convenient back door to stealing someone
else's host name and routing their traffic to your machine.

Since the BIND TSIG updates are secured at a zone level,
a DHCP server is given that zone key and can therefore update
any RR in the zone.  And then consider that a DHCP server
gets the client's host name by using whatever the client
tells it.  You now have the DHCP server acting like a
building janitor with a master key letting people into
any apartment they want just because they tell him/her it
is their apartment.  The DHCP server will now update,
without question, any A RR a client tells it to.

Having some other RR tied to the A RR, where DHCP can store
some kind of 'client-identifier' (usually the mac address
of the actual client hardware) when the host name is given
out for the first time, provides something that DHCP can
query as a 'prereq' to any further update of the A RR.

Unless I'm mistaken, the DHCID RR is supposed to act as this
extra security check for the DHCP server to use itself (ie.
not a check that the DNS would enforce) so that it could
avoid being fooled.

Personaly, I don't care if it's a DHCID RR, or a 'hacked'
use of a KEY RR (which was proposed prior to the DHCID RR),
or any other RR I can use for this purpose.  In fact, since
DHCID doesn't even exist yet, if anyone is doing anything
about this problem today with BINDv8, they must be 'hacking'
some other RR ... I'm just trying to find out which one(s).
Since it is a common security hole, I had just thought
maybe the BIND community had some kind of recommendation
(even if only temporary until a standard like DHCID is set)
on how to plug it using some existing BINDv8 construct.

I'll also try some DHCP discussion groups to see if they
have any ideas.

Thanks -
Joe
---------------------------------------------------------------
Joe Caldwell, IBM Corporation, AS/400 Division
1701 North St., Dept GZVA, Endicott, N.Y. 13760
Internet e-mail: joecwell at us.ibm.com
---------------------------------------------------------------





More information about the bind-workers mailing list