Re: [dhcwg] SLAAC and DDNS

[Olafur Gudmundsson <ogud at ogud.com>]

At 06:41 12/03/2009, Ralph Droms wrote:

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?

Then it is not "random DHCP server" :-) and hopefully there is
trust relationship between the DNS and DHCP server.
 

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.

Yes, the reverse tree there should belong to the ISP operating
that hotspot and it can do what ever it wants:
        put in a "static" dyn-name
        put in a name supplied by the dhcp client
        not have reverse tree entry

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?

Microsoft has a solution based on GSSAPI that works quite well
there needs to be more work done by DNS people to enable automated security
handshakes
        Olafur

> - 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
>
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg