Re: IPv6 and Dynamic DNS

[Jim Bound <bound@ZK3.DEC.COM>]

>  | If the issue is authority then that is TSIG initially and then DNSSEC.
>  | Then its a matter of getting the key.
>
>Yes, exactly.   That small matter.   Does this imply that if I come visit
>you one day, you're going to hand over the key to your zone file to my
>laptop?

Well right now thats kind of how it must work.  There is no key exchange
that I am aware of we have agreed to for TSIG.  For DNSSEC I believe we
assume a PKI but don't quote me on that as I await that too.  But
sneaker net is in fact the mechanism.

>  | For BIND folks this is in the 8.2
>  | release and works with Dynamic Updates to DNS implementation APIs.
>
>Right now, I'm not concerned with the software to make this work, I know
>that's on the way.   It is how it is supposed to be all glued together so
>it can work in practice.

Well its working in practice now in a sense with the DHCPv4 servers but
as you say at least there is some "implied" authorziation btw the DHCPv4
server and the client.  But not necessarily any real authority btw the
DHCPv4 server and the DNS master of the zone.  So I think the inherent
problem is exchange of keys for DNSSEC.  If we know what the answer is
for that generically we know the answer for IPv6 and IPv4 IMO.  For TSIG
we will use what we can for our customers.  


>  | Maybe I am missing your issue as I don't see it?

>The point is where my node gets the authority to do the update (assuming
>that DHCPv6 isn't being used, if it was the server would just do the
>update, as for v4, that's easy to arrange to work).   But we haven't
>moved to mandating DCHPv6 yet have we, autoconfig is still an option, right?
>So assuming that autoconfig is what my node does (and is what I do in fact
>do as I have a router which is sending out the RAs I need for this), where
>does my node manage to find the key to update some random network it happens
>to be connected to today?

1.  I would like to point out that because a DHCPv4ORv6 does the update
does not mean its secure in DNS.  

2.  There is an M bit in stateless addr conf which right now the only
solution being proposed is DHCPv6.  

3.  Right now in addrconf in the case of BIND there are mechanisms to
build the key but we are just testing this now in 8.2.

4.  As far as the IETF ruleset for authentication I am hoping thats in
DNSSEC but I can't find it now.  

5.  It appears us vendors will deploy per #3 above and not wait for the
issues with #4.

So maybe the result of your mail is we need to define key exchange
mechanisms as a standard for dyn upds to DNS?

If so then I think its irrelevant if the update is done by the client or
the server?  Both need the same security measures.

Also there is nothing to prevent an IPv4 DHC client to upate DNS without
even going to the DHCPv4 server.  We build rfc2136 so there would be no
hard dependency on an intermediate (e.g. DHCP, SLP, etc) server for dynamic 
updates to dns.

>It can easily update the forward zone, as its domain name doesn't change,
>no matter where it connects, so configuring it with a key to permit that
>update is easy.   But for the reverse zone file this doesn't look like quite
>such an easy problem (and it certainly can't be swept under the floor by
>saying "you should use DHCPv6 if you need to do that").

I agree it should not be swept under the rug either nor did I suggest
that in mail Sir...........

I would argue there is no difference between either zone file once you have
the credentials at the client (whether that be a dhcp server or a node
that is just a client) you have the proper permission to speak with the
server and the server knows the different btw name->address map updates
and address->name updates.  

/jim