[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] SLAAC and DDNS
inline...
On Mar 2, 2009, at 11:54 AM 3/2/09, Olafur Gudmundsson wrote:
At 06:07 28/02/2009, Ralph Droms wrote:
I think we could use a little DNS expertise in this conversation.
The
thread (it's not terribly long) starts at:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg09635.html
What are your thoughts on using DHCPv6 Information-Request to update
DNS RRs for a host that uses SLAAC?
It is real important from DNS perspective that people be clear if
the updates being requested are in the reverse tree or in a zone that
is in "forward" tree.
A random DHCP server SHOULD/MUST NOT be allowed to update in a any
random
zone.
If a client wants to update its "home" name AAAA/A records it SHOULD
have a TSIG or SIG(0) relationship with its home DNS master (full
stop).
Point taken. The DHCP service in Starbucks has no trust relationship
with the DNS service at cisco.com.
What about the common case in which a host is attached to its "home"
network; i.e., a network for which the DHCP service belongs to the
same administrative domain and the DNS service for the host's domain?
And, what about the reverse zone? Is it OK for the DHCP service in
Starbucks to update the PTR record that belongs to Starbucks based on
the contents of the DHCP message exchange? Otherwise, there needs to
be some kind of trust relationship between the host and the Starbucks
DNS service that will be hard to scale.
The issue here is how to make it easier to create these security
relationships and maintain them.
I have been thinking about how to make this easier.
Assumption #1:
default scope for updates of TSIG/SIG(O) transactions
based on the name of the secret/key. (this needs to be
defined)
Assumption #2:
Trust gets established while client is on home network or
out-of-band.
Assumption #3:
This should be no harder than SSH trust establishment.
Outline of proposed protocol : TSIG
Client issues a TKEY request for client defined TSIG secret,
Server accepts or rejects based on its policy.
Both parties must treat this secret as a long term secret.
Based on the name of the secret the client is given authority to
update a
single name in zone.
Example: client asks for TSIG with name of nn.client_name.zone
where nn is a version number.
All dynamic updates from this key are allowed to update only the
corresponding name and possibly service names below the name.
Outline of protocol: SIG(0)
Client generates an public key and has it inserted into the 'home'
zone as KEY RR.
The client signs all updates with SIG(0) and server accepts updates
to the same name as used to sign the update.
These solutions all seem to be in DNS space. Are any of them under
development?
- Ralph
On Feb 27, 2009, at 11:01 AM 2/27/09, <Greg.Rabil at ins.com> <Greg.Rabil at ins.com
> wrote:
There has been some discussions on the ISC DHCP mailing list about
folks wanting to perform DDNS in an environment where clients are
doing stateless address auto-config. One solution offered is that
the client perform the update after it gets the DNS server(s) and
domain(s) from a stateless DHCPv6 server.
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.
http://www.ietf.org/rfc/rfc2930.txt section 4.5 is the way to go and
it is not that hard to implement.
The main issue is that the client SHOULD only start this
process when on the home network.
Section 4.4 could also work but it is putting work in the wrong place,
as the server has less of a knowledge if the particular device is
going
to be "mobile" or static. The server could have the policy that any
dynamic update without TSIG or SIG(0) will start a TKEY exchange
before
it is accepted, but the clients need to be aware that the TKEY
exchange
can start in an answer packet that rejects the dynamic update.
Buy using client assigned TSIG it requires the client to start the
process, which is
where the burden of effort should be IMHO.
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.
Is there any interest in this approach? If so, I would consider
writing a draft to include the FQDN option in Info-Request messages.
Most DNS servers in the forward tree will not accept updates from
random
entities, thus the approach is doomed.
With the approach proposed above there is no need to "scavenge"
records as the client
can only update a single name, and in theory it can delete the
records before it turns
off. The client that is jumping between networks (or just renumbering)
MUST remember or discover what the current registration is before
issuing a new
dynamic update to the home DNS server and delete the old records as
appropriate.
DNS server can have the policy that it will delete any updated RRset
that is older than
x hours/days, forcing client to issue refresh updates each time it
gets new
lease or ever so often.
Olafur
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg