Re: IPv6 and Dynamic DNS

[Robert Elz <kre@MUNNARI.OZ.AU>]

    Date:        Mon, 02 Aug 1999 13:43:39 -0400
    From:        Jim Bound <bound@zk3.dec.com>
    Message-ID:  <199908021743.NAA0000032040@quarry.zk3.dec.com>

  | Well right now thats kind of how it must work.

Yes, and that's what I was asking about, as in general, that's not
a satisfactory method.  Or not for the kind of dynamic information
that is involved here (getting manually configured with a key is
fine for the forward zone, as the name changes rarely, and this is
easily possible - having to do the same for the address is beyond
reasonable as a burden).

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

No, not necessarily, but it can usually be worked out, and this is the
assumption that has generally been made, and which I think underpins the
relevant DHCP options.   That is, while there isn't necessarily a
relationship between the admin of the DHCP server (who is allocating the
addresses to various objects on the net) and the zone file maintainer
for the in-addr.arpa (or ip6.int) zone file, who is publishing the
assigned addresses, in most cases these two entities are likely to work
closely together, and have arranged the mechanisms to do so - and if that
involves allowing the DHCP server to dynamically update the zone file,
then that will usually happen.

For IPv4 this (or manually having an adress assigned, and having the
zone file manually updated at the same time usually) are the only options.

For IPv6 we have this alternate, and much simpler, mechanism.   But it isn't
going to be a viable mechanism unless we also have a way to get the DNS info
updated - and right now I'm seeing nothing (not even any attempt) to find that
method.

Note that this really has nothing whatever to do with key exchange per se, 
though that may become a component.  It is a question of authorisation, and
where that comes from.  Keys are just a method to demonstrate that
authorisation exists, they don't provide it in the first place, and it is
that first step that I don't see here.

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

No, and this has nothing whatever do do with the question.

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

Yes, I know, and if that method (any such method) is in use, then the
problem I forsee doesn't arise.  All the others you're alluding to are
still there, but those are at least known, and being worked upon, so I'm
not so worried about them.

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

This has nothing to do with the problem.

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

I'm not sure what this means, but I suspect it is also missing the point.

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

Fine, but I still see nothing at all which addresses the problem here.

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

No, nothing like that at all.

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

Yes, they do.   The question is still how and where is the authorisation
to use whatever security measures exist is granted.   If a server is doing
the update, this is easy, as the existence of the server is known, it can
be allowed to use (via whatever mechanisms are appropriate) whatever it
needs to get its job done.    Since clients just appear, and the IPv6
autoconfig is supposed to let them just start running (assuming the net admin
allows that, and remember I am assuming that here) I don't see how they're
going to be authorised to do anything at all (related to the address).

So we have no server (dhcp type server - this is the assumption) and
unauthorised clients (not clients without a key - unauthorised clients).
But we still have the ip6.int zone file to get updated, somehow.

  | Also there is nothing to prevent an IPv4 DHC client to upate DNS without
  | even going to the DHCPv4 server.

No, of course not, assuming the authorisation exists.   I believe that the
general assumption is that it won't normally do that for the in-addr.arpa,
since it isn't expected to have any a priori knowledge of what address
it is going to be given, it also can't be expected to have any authorisation
to make the update - however circumstances can be odd, and in some
circumstances the client may be able to perform the update.  The same would
be true for IPv6 in similar circumstances.   But this uninteresting case
does nothing to solve the general problem.   We get no closer to solve the
problem by pointing out the cases in which the problem doesn't exist, unless
you're also able to show that those cases cover all the relevant cases,
and here, I don't believe that is possible.

  | I would argue there is no difference between either zone file once you have
  | the credentials at the client

Of course.   The question is where those credentials came from.   I thought
I had made that clear in the last mesage, if not in the first one.   Perhaps
I have this time?   And once again, this has nothing to do with any kind of
key distribution protocol - any of those must still require some kind of
authentication before blindly handing out any key that some random client
chooses to ask for.   Its at that level that the problem arises here.

kre