On-going work on DHCP project : RFC4361 support

David W. Hankins dhankins at isc.org
Fri Mar 19 19:09:50 UTC 2010


On Fri, Mar 19, 2010 at 10:43:49AM +0100, Thomas PEGEOT wrote:
> The problem is directly related to the use of a hash function (MD5) in TXT
> records. MD5 is a one-way cipher, which means that we can't decrypt this MD5
> hash in order to extract the identifier. From that moment on, I don't really
> see how this conversion could be done.

Yes, to perform a TXT->DHCID exchange, you would need to replay they
information from the lease structure.  I did not intend to imply
translating the TXT to DHCID format as that is impossible, but rather
to convert a standing installation from one to the other.

Since client-identifier or chaddr contents are stored on the lease
structure, leases with TXT records noted on binding scopes could be
converted to use DHCID.

The open question is how to do this in a way that is seamless to the
operator while still involving the operator's conscious decision
because many do have multiple DHCP services running in parallel, so
different versions of software.  Coexistence?  Upgrade tools?

One minor user interface note in moving forward in this, right now we
have;

    ddns-update-style interim;

And the old ad-hoc code that hopefully no one uses anymore.

So when adjusting DHCP to do updates using DHCID RR's instead of
TXT RR's it may be desirable to change 'interim' to e.g. 'standard'
or etc for that mode of operation while retaining the old mode.

Then it wouldn't need a compile-time flag for example.  Old
installations with 'interim' configured would continue to work
without flaw, and new installations could be encouraged (in manpage
etc) to use the new standard format in cut-and-pasteable config
examples.

What remains then is tools to assist with migration, because we do
not want to support 'interim' ddns forever.  Whether to do that at
dhcpd or dhclient runtime or to provide some tool or script...I am
not clearly decided.

> Is removing every TXT record in DNS databases a suitable solution? Even this
> would imply a security issue (no more identification records), this would
> make transition easier: if there is no more TXT record, a client, through
> the DHCP server, would be able to add a DHCID record to its A or/and AAAA
> records. 

No, that is incorrect.  First, TXT could be used for other purposes
(which is why we don't want to use TXT RRs).  Second, the standard
FQDN resolution protocol requires that the updater place a PREREQ that
the name is not in use on the first attempt to update, and if that
fails a PREREQ for a matching DHCID (or our stand-in TXT) on the
second attempt to update, and if both those fail then no update is
performed.  So in that case the clients actually won't update DNS.

In this approach it is more proper to "start over" on the DNS zone,
removing essentially all RR's and clearing the DHCP server's state
so that new updates are performed (or turning off
'update-optimization').

> A DHCPv4 client is now able to send a DUID-based client identifier. Actually
> it is RFC4361 compliant [2]. 
> This type of client identifier is very useful for dual stack clients,
> because it contains among others things the client's DUID which can be
> extracted to compute the same DHCID (TXT or the real one) than the DHCPv6
> client (identified by its DUID). In that way, a dual stack client will be
> able to have these A and AAAA records associated with a single FQDN. 

Excellent.

Thank you for spending time on this. :)

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-workers/attachments/20100319/fc9eada5/attachment.bin>


More information about the dhcp-workers mailing list