Subject: Re: comments on dhcp-dns-09

From: Mark Stapp <[email-masked]>
Date: Tue, 6 Apr 1999 18:25:11 -0400 (EDT)

Edward,

Thanks very much for your comments. I will forward your message to the dhcp
list along with this reply, if that's all right. I've cc'd all of your ccs
in case they're interested but not subscribed to the dhcp list. My reply's
inline:

At 03:21 PM 3/30/99 -0500, Edward Lewis wrote:
>Here are some comments I have on the draft.  Other members of TIS Labs may
>add or refine these comments, so they are CC'd.  If the authors wish to
>forward these onto the DHCP mailing list, you may do so.  I am not on the
>list.
>
>Protocol related:
>
>If you add a two byte field for a DNS RR type, this structure can be made
>more general.  Not that this field would be used right away - fixing the
>value at 1 for now (the DNS type value for A) is fine.
>
>Adding this would enable experimentation into including other types (such
>as HINFO).  I recommend not pursuing that right now, but allowing for it
>would be a good idea.
>

Would you like to see a general-purpose option that clients would use to
tell servers which DNS records they'd like added to their names? I can
imagine that it would be useful for a server to offer the capability of
adding various kinds of DNS records as clients get leases, but that feels
like a server implementation feature, not a client feature. It sounds as if
you'd like to allow a DHCP client to be able to specify the kind and
contents of DNS records that a DHCP server would add on its behalf. I'm
loathe to resist generality, but that's a stretch from the existing draft.

The current option proposal doesn't specify a way to convey the RRDATA that
the client would like added, for example. Using your HINFO example, a
client would have to be able to describe itself, and the server would have
to know how to represent that description in the HINFO RRDATA. Would the
'flags' and 'rrcode' fields in the FQDN option be meaningful in the HINFO
example? I'm not sure that we want to specify that any server which can add
A and PTR records can also add any arbitrary resource record type. Is there
an application that you have in mind where this would be useful? Are there
others out there who'd like to see this capability? If so, does that
capability have to be part of this draft, or should it be a separate draft
on the more general problem? I see the existing issues as more limited, and
the existing draft is an attempt to address them.

>The last line of section 3.1 - the FQDN should be represented in the DNS
>protocol format (as opposed to the printed version).
>

Yes, several others have noticed this issue as well. There is a large
population of shipped clients (from MS) which have begun using this option
already, and which use an ASCII format. I'll propose offering the DNS
encoding as an option, and allocating one of the 'flags' bits to indicate
that that encoding is being used.

>Behavior related:
>
>o - Securing the update of a name's A (address) record is difficult for the
>server.  In the case where the dhcp server and the authortative zone are
>under one network administrative staff, it is conceivable that the dhcp
>server could hold a DNSSEC zone private key for signing the records.
>
>However, if the authoritative server and the dhcp server are not of the
>same organization (thus no sharing of a private key), then the server would
>have to send unsigned data.  In this case, a transaction signature is
>necessary, but that is something configured between a DNS server and a
>client (which would bt the DHCP server).  Even if this configuration is
>made to be automatic, e.g., an exchange like Diffie-Hellman, the DNS server
>may not be willing to accept updates from a remote DHCP server.
>

There is a significant interest in the dhcp community in supporting sites
which only allow dynamic updates from their DHCP servers. That reflects
several concerns, including the costs of per-client configuration and key
distribution, and the possibility that clients will be moved or deactivated
and will be unable to update or remove DNS records which they added. These
sites are generally large organizations where all updates are directed at
that organization's own DNS servers. Credentials for DNS updates to the
internal DNS servers only have to be distributed to the organization's DHCP
servers in that model.

The concerns of those sites may change over time, particularly if DNSSEC
becomes more generally deployed, and the current draft supports several
administrative models.

>o - There is a proposal in the DNSIND WG to add something called "deferred
>delete" which may be able to handle the removal of records when a lease
>expires.  This means that a DHCP server could issue a data update and a
>data removal in the same DNS message.
>

I have the draft (it's draft-ietf-dnsind-dddd-00.txt, for those dhcp list
members who haven't seen it), and it sounds great. This will certainly be
useful (if supported by DNS servers) if clients are performing updates. It
would mean, of course, that updaters would have to 'refresh' the
delayed-delete ttl when they renew leases. That additional work might well
be seen as worthwhile at sites which are concerned about orphaned or
incorrect records.

>o - A "Name collision" is an unfamiliar term to me.  If you are concerned
>that multiple dhcp clients will want the same domain name, this is not a
>problem for DNS.  It is relatively common to have a domain name have A
>records for many addresses, with these addresses being on different
>machines.  This is done, for example, to load balance across numerous web
>servers.  (Perhaps a farm of WWW servers could be using DHCP to get their
>addresses.)
>
>There is also the possibility that you are concerned about RR set
>collisions.  There may be other data already in existence at a name, such
>as a public key, and no address set.  In this case, there is a "name
>collision" (as in the name is already in DNS) but no other host is using
>the name.
>

What I think I meant (though I may not have said it clearly) is pretty
specific: if two clients _think_ they should be using the same domain name,
and if they both try to update DNS to associate their IP addresses with
that name (or ask DHCP servers to associate them with the name), they
conflict. That's not the same case as an administrator's intentionally
configuring round-robining for his or her web servers. In many DHCP
installations, having several DHCP clients attached to a single domain name
would be considered an administrative error. It's also common for large
DHCP sites to have several DHCP servers, all serving hosts in a few DNS
zones. If a DHCP client moves from one subnet to another, it may move from
one DHCP server to another: the second DHCP server needs to have a way to
distinguish this situation. The draft describes a way to detect collisions
and distinguish between hosts who have moved and new hosts whose names
collide with existing DNS names.

>o - The KEY RR is now defined in RFC 2535 (see section 3.4, near its end in
>your document).  The RFC mentioned in the draft has been obsoleted by 2535.
>

Thanks: I'll update this.

>o - IMHO, after thinking over my comments & thoughts (some of which are
>just on the paper copy), a DHCP server should not attempt to enter data
>into DNS on behalf of the client - with two exceptions.  One is the PTR
>record that needs to be updated as a result of the lease.  (The "reverse
>map" is a domain name pertaining to an address.  See my final paragragh.)
>The other is the situation in which the DHCP server has a private DNS zone
>key and acts as a surrogate DNS zone signer for its updates.
>
>A client that wants to use a certain domain name's information will likely
>be pre-configured with keys, corresponding to public keys in the DNS at
>than name.  Because of this, the client will be in a better situation for
>securing its updates.
>

The kind of client you're describing is supported by the 09 draft. That
client can set the flags in the fqdn option appropriately, the client's
network administrator can configure the DHCP server to allow the client to
perform its own A update, and the administrator can configure the client
and the zone's DNS server with appropriate credentials. There are many
clients, however, who cannot perform their own updates, or which are on
networks whose administrators have a policy which only allows updates from
the DHCP servers. That configuration is also supported. In addition, a
client which is allowed to perform its own updates can, by following the
protocol in the draft, cooperate with other DNS updaters.

>There is an important distinction between host name and (fully qualified)
>domain name.  A domain name is just a locator into the DNS data base, so
>what is stored at a given name may pertain to one host name, a group of
>(load sharing) hosts, an address (PTR record), or a non-host item like an
>email address.  This is perhaps the basis of my comments above.
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                       Network Associates/TIS
>Phone: +1 443-259-2352                             Email: [email-masked]
>
>Think globally, scope locally.
>"Trying is the first step to failure." - Homer Simpson
>"No! Try not. Do... or do not. There is no try." - Yoda
>
>Opinions expressed are property of my evil twin, not my employer.
> 

-- Mark

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Fri, 9 Apr 1999 16:21:23 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------
>in case they're interested but not subscribed to the dhcp list. My reply's

You can forward the comments.

Here are some brief responses...

>tell servers which DNS records they'd like added to their names? I can

Not in this draft, at least.  Perhaps you could place the DNS-opcode field
before the RCODE's, making the format look like:

  Code Len Flags OPCODE RCODE data OPCODE RCODE data ....

Where data is defined in a self terminating way per OPCODE.  (For A
records, this could be just a dname.  For more complex ones, length and
data would be in there.)

But I'd recommend against saying more than this for now.  Leave the door
open to the possibility and see if people are able to extend it later.
(Unless you think there's a problem controlling the changes.)  I hate
"mission creep" and "feature bloat," but I like extensiblity.

>conflict. That's not the same case as an administrator's intentionally

When two clients ask for the same name, is it a "decidable problem" to
determine whether the same name request is due to desired round-robin use
or an administrative error?  Would a DHCP server then need be told what
names are shared and which are unique?  I'm not certain the DHCP server can
make the distinction.

>The kind of client you're describing is supported by the 09 draft. That

The problem lies in paragrapgh 3 of section 3.3.  If the client asks the
server to not make updates, "the server MAY (at the determination of the
local administrator) update the A RR."  The word MAY has to become MUST NOT.