Re: New I-Ds on ftp.bucknell.edu

[[e-mail]]

Yakov,

Regarding draft-ietf-dhc-dhcp-dns-00.txt

I have no real technical issue with the strategy but some comments on
"use" and the effects to "policy".  Under the Applicability to IPv6 the 
wording needs some work, as DHCPv6 and IPv6 bring new capabilities and
technical assumptions to the issues.  I will propose the wording below.

Who updates what/when/which:

I believe if a client can update A records it will also be able to
update PTR records.  

If the client uses the server for one record it will in most cases use
the server for all records.  This is how I believe net admins will use
the protocols (dynDNS/DHCP).

I see nothing in the draft that prohibits this behavior.

Under Discussion:

Discussion #1 Configure server to perform IP to FQDN mappings:

If the client owns the mapping the client does the update.

Discussion #2 Duration of Lease reflected in DNS updates:

We cannot set the TTL in this manner.  The TTL reflects the caching for
an address not a policy for time of use for an address.  In BIND the TTL
is used to optimize the propogation of locating addresses quickly.  It is
not mean't to be used for a "policy" for how long an address is used
for by a "node".   Also if the lease is infinite we don't want infinite
TTLs.  If we want lease times associated with DNS they need to be new
DNS records.  But I don't see their use for control of address expiration
and this should be left to the server or client.

Discussion #3   Server deleting a PTR record:

Regarding the server deleting the PTR record.  This needs much WG
discussion.  The issue is should a server delete anything but addresses for
a client?  I think the client always must initiate the DNS update
(meaning change too).  But I think implementations should be able to
configure the policy needed if this is to be done by a server.  

My input to the WG is as follows.  This gets into an issue of "policy".
What we should do now is state the mechanisms that can be used to
implement different policies for changes to the DNS per addresses
expiring or being renewed.  Users will want this done in different
manners depending on their particular philosophy for their distributed
network environment.

Also I think any deletions must occur after the address is invalid not
during the deprecated state because if the address is renewed the DNS
will not change, unless the client wants a new name.  This is more of an
IPv6 issue but could be applied to the T1/T2 timer fields in DHCPv4.

Here are the possibilities off the top of my head:

  1.  Client owns all updates.  Server not needed.  This is the easy
      case for the server.

  2.  Client owns update of A records but Server owns update of PTR records.

      A record expires:  

        CASE 1:
        In this case the client owns the A record so if they delete
        it they need to inform the server this has happened. The server
        then deletes the PTR record.

        CASE 2:
        A policy exists that when an address expires the server is
        to delete the PTR record.  This policy can be set when
        DHCP is configured or in an option for each client.  
        I personally believe it will be determined by users at 
        each subnet.

  3.   Server owns both updates of A and PTR.

       CASE 1:
       Client controls server operation with msg types or options.

       CASE 2:
       Server uses policy as in CASE 2 in #2 above.


Discussion #4  Server terminates lease before lease expires:

This gets into the lack of robustness in DHCPv4 when a server wants to
terminate a lease before its time expires.  There is no way to
communicate to the client unless a transaction is in process initiated
by the client, as DHCPv4 clients don't listen on a port for any server
initated messages.  In DHCPv4 I don't think we should just delete A or
PTR records in this case as its very rude and I don't think users will
want such a policy.  For example I am running an application that
verifies its address with DNS like rlogin and the connection breaks
without any knowledge to the client.  We fix this in DHCPv6.

Applicability to IPv6:

FIRST: Do you need to send this to the DHCPv6 list its different than
the DHCPv4 list?

I would state the following (if my co-author Charlie Perkins agrees):

---------------------------------------
The procedures described in this document are applicable to an IPv6
client, but as the DHCPv6 protocol is different the exact mechanisms may
be different, and new capabilities may exist in DHCPv6 that are outside the 
scope of DHCPv4.  The procedures should be documented and inherent in the
DHCPv6 specification as a new protocol.

Add a reference to Bound/Perkins DHCPv6 spec (which will be out soon but
you can use the present ID for reference if you cannot wait)
---------------------------------

The DHCPv6 architecture is completely different and the scope and
capability of that protocol also deals with addresses leases completely
differently.  We have also added new capabilities directly because of
the new features in IPv6.  I think the above wording covers the changes.
The spirit of what your proposing is fine for DHCPv6 but it will be done
differently as you will see in our next draft to be presented at the
L.A. IETF meeting.

ALso in IPv6, DHCPv6 could be used as a server to update stateless
addresses on DNS and in that case we don't want the server to do
anything with DNS it has not been told to do by the client in most
cases.  As those addresses are generated from IPv6 ND RAs.

But overall I don't disagree with your objective and glad someone is
addressing this important issue.

thanks
/jim