[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] SLAAC and DDNS



On Fri, Feb 27, 2009 at 10:01:34AM -0600, Greg.Rabil at ins.com wrote:
> I think the only drawback to this solution is that doing DDNS updates from the client makes it difficult to secure the updates using TSIG, for example.  Distributing the TSIG key(s) to the clients is really not an option in most cases.  However, there is tremendous benefit to supporting DDNS in a SLAAC (stateless address auto-config) environment.  One option would be to require client to put their FQDN option in the Info-Request message sent to a stateless DHCPv6 server.  The source address of the Info-Request message is the client's SLAAC address, so the stateless DHCPv6 server would know the IP, and if the FQDN option were included, it would have enough information to update both the AAAA and PTR records.  The problem here is that a stateless DHCPv6 server will not know when the records should be removed from DNS, but stale records could be cleaned via some other "scavenging" mechanism.

The IPv6 source address of an Info-Request message is more likely a
link-local address, and using this field presumes the client has only
one address.  So you would have to specify that the client MUST select
a source address specifically not in keeping with the usual guidelines
for source address selection.  This isn't impossible, a client can
bind the socket.

You'd also have to specify the client MUST include a client identifier
option so that the server can manufacture a DHCID.  RFC 3315 states
this is a SHOULD for information-request, only a MUST if
authentication is in use.

But, this method raises a security concern.

The client does not have a TSIG key, but by using only the source
IPv6 address field and an FQDN option, it can ask a DHCPv6 server to
perform an update on its behalf.  This mechanism simply extends DHCP
to tunnel through DNS security, to bypass it.  Anyone can send that
packet, and they can ask the DHCP server to update the zone with
whatever contents they might have updated themselves - just limited
to AAAA and DHCID RRs.  This is not very different form simply leaving
the DNS zone wide open, or erecting access control on the DNS zone to
limit RR types.  There is for example a BIND 9 ACL command that
permits systems to update their own PTR records.

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

Attachment: pgpbDP55vC91g.pgp
Description: PGP signature