Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 5 Apr 1999 13:50:07 -0400 (EDT)

Mark--

first of all, Thank You Very Much! for taking the lead in advancing this
draft....  some of us have been Waiting a Very Long Time....

Instead of interspersing all of my comments in the previous strings of
messages, I'll summarize them here, and then add some context if the point
requires it....

On the issue of encoding names:  we briefly touched on this in Orlando, only
getting so far as to agree that it was an issue we needed to resolve in
general for all of the DHCP options.  Robert raises the very good point that
any name [and I think, any fragment of a name, such as option 12] that can
be/is used with DNS probably ought to be encoded such that it is directly
usable.  Having said that, I also believe that we must solve the general
problem, which we cannot do in a single Internet-Draft for one specific
option.  I am neutral about using a flag to be interpreted as "DNS encoding"
because I haven't thought through how many cases we might be likely to be
required to cover.

Regarding local administrative policies as to which party (DHCP client or
server) ought to update the A records, I only want to ensure that the draft
does not preclude an administrator from saying, "In our case, clients will
never be permitted to directly update DNS:  only the servers will."  It
seems to me that if such a policy were in force, the DHCP server would not
need to explicitly tell a client of this policy, but merely operate
transparently to the client.  If the client in such a case were to include
the FQDN option in a request message, the server could still respond as if
it had acted on behalf of the client to update the A record.

Would it be appropriate for the draft to specify appropriate client behavior
if the server asserts its authority?  In this case, I believe the client
should just quietly accept that the server did so, rather than declining or
releasing the address lease, or starting the discover cycle again.  Still,
this comes down to a question of how to coordinate the dialogue between the
two parties.  Also, consider the case where the server is an early adopter
of DNS dynamic updating, but the clients lag several weeks or months behind.
It may not be a good idea for the server to return this option to the
client, filled-in with appropriate status info, to a client which did not
include the option directly or in its parameter request list, even if that
means the client is then ignorant of DNS update activity occurring on its
behalf.

--Barr

> ----------
> From: 	Mark Stapp[SMTP:[email-masked]]
> Sent: 	Monday, April 05, 1999 7:30 AM
> To: 	Multiple recipients of list
> Subject: 	RE: draft-ietf-dhc-dhcp-dns-09.txt
> 
[ ... stuff deleted ... ]

> Second, you describe very clearly one of the administrative situations in
> which the DHCP server has a role that's central to the maintainance of DNS
> information. As you describe it, dhcp administrators do not want to give
> access to DNS to arbitrary clients, and do not want to oversee key
> distribution to every 'trusted' client. They'd even prefer not to
> distribute complete domain names to their DHCP clients manually, relying
> instead on DHCP replies to tell the clients about the domains they're in
> dynamically. The more centrally managed servers are the authoritative
> source for DNS updates, and may even be the authoritative source for
> clients' hostnames. Since the servers are 'on' all of the time, they are
> less likely to leave orphaned DNS names. That's a model that must be
> supported by the draft.
> 
> Under the policy you describe, DHCP servers need to be able to tell
> clients
> that the servers will perform A and PTR updates, since the servers know
> that the clients do not have the appropriate credentials to do so. 
> 
--As I said above, it may be a better choice for the server to simply do so
without informing the client, unless the client includes the option in it's
request message. [Barr]

> In addition, the DHCP servers need to be able to inform clients of the
> domain
> name that will be representing the client. 
> 
--If I may interpret, you are suggesting that in such a case the server
SHOULD or MUST return the FQDN as registered.  Okay, but what if the server,
by local policy decision, just updates DNS without the client requesting?
Should the server then (1) return the FQDN option completed as seems to be
appropriate, or (2) return BOTH options 12 and 15 to the client.  There is a
third possibility:  the client might include the FQDN option in their
parameter request list but not as a separate option.  I think we agree that
informing the client as to actions taken on their behalf may be a very good
idea, but should we do so if the client didn't request the appropriate
option(s) for the information?  In my own implementation, there is one
specific case where I stuff option 12 into messages to the client even if
they did not request it or include it in their request of the server, so I'm
comfortable with the server doing so in another situation.  But is that
always the right thing to do? [Barr]

> I think both of those properties are in the current draft, in that the
> server can use the option's flags to indicate to the client that the
> server will perform both DNS updates. I will try to make the 'local
> policy' case clear, and I will make explicit the possibility that the
> server may return an fqdn option (and/or
> host-name+domain-name option pair) that is meant to tell a client what DNS
> name it has, rather than just echoing the client's choice.
> 
> A few more comments inline:
> 
> At 11:08 AM 4/2/99 -0800, HIBBS, BARR (PB) wrote:
> 
[ ... stuff deleted ... ]

> >> From: 	Mark Stapp[SMTP:[email-masked]]
> >> Sent: 	Friday, March 26, 1999 4:17 PM
> >> To: 	Multiple recipients of list
> >> Subject: 	Re: draft-ietf-dhc-dhcp-dns-09.txt
> 
[ ... stuff deleted ... ]

>--true, but what about the more recalcitrant clients/users?  Can we
> >generically specify a means to surmount this problem?  For example, can
> we
> >tell DNS the lifetime of the resource records? (Robert, I defer to you
> about
> >this...)  Should we specify client behavior that does a reverse lookup
> >before changing its name, deleting the old A record as a pre-condition
> for
> >adding a new one?  Or is there some mechanism by which the DNS server 
>itself purges dangling names? [Barr]

> There has been a proposal for 'expirable' DNS records, but I don't know
> how
> far it has gotten. There's an important trade-off here: if the records
> don't expire, the updaters don't have to refresh them as the clients'
> leases are extended, and that saves work and complexity. If clients are
> going to perform updates, and if we believe that clients may be shut down
> or moved frequently, then expirable records will be very useful.
> 
--this is a matter that needs more thought, and probably the concurrence of
the DNS folk... [Barr]

[ ... stuff deleted ... ]