Subject: RE: IPv6 and Dynamic DNS

From: "Peter Ford (Exchange)" <[email-masked]>
Date: Tue, 10 Aug 1999 19:17:32 -0700

Can't the router update the DNS?

peter

From: Paul A Vixie [mailto:[email-masked]]
Sent: Tuesday, August 10, 1999 2:05 PM
To: [email-masked]
Subject: Re: IPv6 and Dynamic DNS 

It seems to me that DNS (dynamic or not) can't address what seems to be a
basic flaw in the basic model of stateless address autoconfiguration.  We,
in the person of Yakov and Susan, designed DNS UPDATE with an eye toward
DHCP (v4 and v6).  Our assumptions were all based on there being an agent
on the LAN (meaning the DHCP server) who had permission to update that LAN's
inverse DNS entries (meaning IN-ADDR.ARPA and IP6.INT).  If stateless auto-
configuration doesn't work the same way (meaning there's no agent on the LAN
who has permission to update the inverse DNS entries for that LAN and who
knows about new address assignments) then stateless autoconfiguration needs
some work.  Is namedroppers really the place where this work should occur?

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 10 Aug 1999 19:23:44 -0700

> Can't the router update the DNS?

if the router knows when a new address has been assigned with stateless
autoconf, and if the router knows the "forward name" to be associated with
the address just assigned, and if the router can know a TSIG shared secret
or some other private key that protects the in-addr.arpa or ip6.int PTR's,
then sure.

however, i think we're dealing with a more fundamental problem.  microsoft
avoided something similar by using GSS TSIG.  what's needed is an opaque
and somewhat anonymous and short lived permission blob, that's only useful
for updating one particular thing at one particular time.  TKEY to the
rescue?  donald, are you still listening, and can you chime in?

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 11 Aug 1999 09:53:57 -0400

Well, I haven't been paying that close attention to this, but here is
my take.

If a guest machine auto-configures on some net, it will presumably
have a key that gives it authority to update its forward address
record.  This could be a TSIG secret key shared with the primary
server of its forward name zone, but, since this is an infrequent
operation so efficiency is not that important, I would think the
higher security of using a public key and signing the update of the
forward address RR(s) with a SIG is the way to go. Or, of course, you
can just use TKEY to set up a temporary TSIG key securely based on the
public key although this adds at least one round trip.

Now we get to updating the inverse zone.  There is basicly the
non-crypto and the crypo say of going about it.

Non-Crypto is to pretty much trust unsigned local updated based on
indicita like the packet source address, checking against an address
retrieval under the name (would be nice if the forward zone were
secure), and whatever else you can think of.  This just doesn't seem
that bad to me.  While a malicious machine could try to fill up the
inverse zone or something, having a malicious machine on your LAN is
likely to lead to other problems and you should probably have some
background process to delete inverse entries by guest machines that
seem to have disappeared from your net anyway.  Or/and maybe you
should be checing when a PTR is entered in an inverse zone by doing an
inverse query for the name and auto-deleting any PTR for that name
under a different address unless there are actually multiple addresses
under that name in the foward zone.  (But, of course, a malicious
host can easily arrange to have control of zillions of names.)

In the first Crypto way to do it, the inverse zone server could
require that the update by signed by the key for the forward name.
This is pretty much impossible or a severe security risk if you are
just using secret TSIG keys directly.  If the inverse zone server
doesn't know the secret key, it can't veryify the signature.  If it
doesn, suddenly this random server on some net you are visiting can
forge signatures on your behalf.  On the other hand, if you are
building from public keys, TKEY can be used to set up a secret key
with the inverse zone server which only the mobile host and that
server know.  But, if the forward zone is secure, this is not much
better that just checking the forward address records.

The second Crypto way to do it assumes a key that specifically
authorizes update for the local inverse zone is somehow set up on the
mobile host.  This could be a secret TSIG key shared with the inverse
zone server or a public key that is used to directly SIG update or is
used with TKEY to derive a temporary secret key to TSIG update.  This
has the advantage that you no longer need access to the forward zone
or server. But this just begs the question.  What administrative
system is going to be giving this key to a miscellaneous mobile host
that is visiting and on what basis and what is to stop a host from
getting 10 or 10,000 such keys?  If you have a human being do it, that
rate limits you pretty well but is obviously a pain.  You would want
to have some feature where you knew that this inverse update
authorizing key was only good for entering a single inverse entry and
if it tries to enter a second one, the first goes away.  Sometimes
this second crypto way would be better but it seems to me that
whatever administrative system give out this locally authorizing key
could just as well accept and authorize the update itself, sending it
on to the inverse server.  Maybe visitors could be given a smart card
or something with a time limited key...

TKEY does have modes where the client can just send a key to the
server or the server can just send a key to the client, authenticated
by SIGs under the name of the client or server, but this doesn't help
particularly.

I don't believe that GSS-TSIG solves any of this.  It just pushes the
whole thing off on GSS which has the same problem that you can't trust
an unknwon guest mobile host not to act maliciously.

If you are not worried about malicious actions but just want to be
sure it has authority for the name it is putting in the inverse zone,
Crypt method one above should be fine.

Hope I haven't missed so much of the conversation that my comments
are not applicable.

Donald

From:  Paul A Vixie <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
In-reply-to:  Your message of "Tue, 10 Aug 1999 19:17:32 PDT."
	                  <[email-masked]> 
Date:  Tue, 10 Aug 1999 19:23:44 -0700

---

From: Andrew Brown <[email-masked]>
Date: Wed, 11 Aug 1999 12:11:38 -0400

>public key although this adds at least one round trip.

which makes sense, and i was about to come up with that.  :)

>non-crypto and the crypo say of going about it.

(hoping that i'm not just summarizing an earlier posting) presumably
the dhcp server would have authority (via a shared key, etc.) to
update the inverse zone...

given that, if, once the mobile host (a) has acquired an address an
(b) has updated its forward zone, could it not then tell the dhcp
server what it wanted its name to be?  then the dhcp server could
check for the forward mapping to see if it matched the address it just
handed out, and, upon a match, update the reverse.

of course...it might involve a little cache busting on the part of the
dhcp server's forward query if the mobile host is moving around a lot.

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."