Subject: Re: Comments on draft-ietf-dnsind-dhcp-rr-00.txt

From: Mark Stapp <[email-masked]>
Date: Mon, 25 Oct 1999 18:37:03 -0400 (EDT)

Ted,

At 12:49 PM 10/25/1999 -0400, Ted Lemon wrote:
>One objection that's come up with this draft is that MAC addresses are
>considered by the paranoid to be "private," which means that if we
>stuff them in the DNS, where they're publically searchable, somebody
>might freak out.

The issue about what kind of information is to be added to the DNS to 
support the decision-making I've tried to describe in the dhcp-dns draft is 
completely separate from the issue of what RR type carries the information. 
If there is an objection about adding client-ids or MAC addresses into the 
DNS in some form, we'll have to address it whether we use the KEY RR or 
some other RR type. "Paranoid" or not, this is clearly a real concern at 
several levels in the ietf. For those who haven't heard about this, see:

http://playground.sun.com/ipng/ipv6-address-privacy.html

>I'm actually wondering if just having a DNS RRtype that says who
>created the name would be enough - e.g., instead of storing the client
>MAC address, you have a CREATOR record that contains the IP address of
>the DHCP server, or even just to a unique, locally-defined token.
>
>Can anybody comment on whether or not a CREATOR record like this would
>be enough?

Unfortunately, the point of associating client information with A records 
(and possibly other types) is that it's the association with the client 
that's interesting, not necessarily an association with the entity that 
performed the update. The case is one where, for example, a company has two 
buildings, and has a dhcp server in each building. Suppose a laptop user 
gets an address from server A, and the user has a windows client that 
suggests a hostname that the user would like to have associated with the 
laptop. Server A adds an A RR embedding that hostname into one of the 
organization's zones. If the user goes over to building B and boots there, 
server B will find that an A RR already exists on the laptop's domain name. 
If information exists in the DNS that allows server B to determine that the 
name is modifiable via DDNS, and to determine whether the record is 
associated with the current DHCP client or with some other client, server B 
can be configured to do some very useful and valuable things. Server B can 
replace the existing A RR, since the client is now using a new IP address. 
If another client boots, and this second client has been configured with 
the same hostname as the first client, server B can be configured to 
replace the existing A RR on that domain name, or not to replace it. If 
server B notices that a client's suggested domain name already has RRs, and 
it does not have the DHCP-DNS form of the KEY RR, the server might be 
configured to conclude that the records were added by an administrator, 
rather than through DHCP activity. The server might avoid modifying that 
name in any way, assuming that the administrator's static DNS configuration 
shouldn't change without his or her own explicit activity. It's the 
information about the client that allows a decision to be made, not 
information about the server.

>    The reason this draft got proposed is that the DNS guys
>*really* don't like the DHCP-DNS use of the KEY record, and we'd like
>for there to be an alternative.

That's an interesting statement - I wish some of "the DNS guys" who've sent 
me comments over the last year had mentioned their objections. I've had 
comments, some extensive and some brief, from all of the DNS WG chairs, 
among others who regularly contribute in DNSIND. Until now, I have not 
supposed that the use of the KEY RR for this purpose appeared particularly 
controversial. The KEY RR is explicitly specified (it has 'protocol' and 
'algorithm' fields which are available for assignment by iana) to support 
extensibility. I don't believe that I've proposed an "overloaded" form of 
the KEY RR; I've just proposed extending it in the way that it supports.

There are, unfortunately, two problems with a new RR type:

1) it creates a significant deployment barrier for any installations with 
pre-9.0 BIND servers (I'll assume that 9 could be taught about a proposed 
new RR type). I don't think that the opaque information that will be 
contained in the KEY RR associated with a DHCP-DNS update poses a threat to 
the operation of DNS servers which understand the KEY type, or to any other 
DNS client that understands other forms of KEY RR. The number of sites that 
will have difficulty deploying the current proposal is much smaller. Using 
the KEY RR would allow the DHCP community to begin deploying useful 
functionality promptly.

2) it creates a dependency between the dhcp-dns draft and a brand-new draft 
that has to make its way through the DNS WG.

-- Mark

---

From: Mark Stapp <[email-masked]>
Date: Tue, 26 Oct 1999 11:55:02 -0400 (EDT)

>stuff them in the DNS, where they're publically searchable, somebody

I wonder whether a one-way hash option might be enough to address this at 
sites where this kind of privacy is a concern. Administrators who wanted to 
cloak the client-ids would need to configure the DHCP servers with a shared 
secret. The servers could then store the client-id info. in encrypted form 
in the DNS RR. I don't think there's a reason to try to involve the DNS 
server at all. As long as the DHCP servers could reliably make the 
client-domain name association, the rest of the decision-making would be 
unaffected. The mechanism to encrypt client-id data would be specified in 
the draft, but as an optional capability. This would be a capability that 
implementations SHOULD support, but which would be disabled by default.

Is there anyone in the WG who's familiar enough with the 'MAC privacy' 
issue to be able to tell us whether this might be a reasonable response? 
Ralph or Tom maybe? Anyone have a favorite encryption method - SHA1 OK?

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Oct 1999 13:14:25 -0400 (EDT)

Hm.   I see your point WRT seperate servers, and I think a hash is the
right solution for obfuscation.   Unfortunately, this still means we
need to fix the DHCP RRtype.

> me comments over the last year had mentioned their objections.

Sigh.   This may be partially my fault - I objected to the use of the
KEY record, and mentioned it verbally on a number of occasions,
possibly even within your earshot, but never wrote up a formal
counterproposal.   I also didn't point it out to the ISC DNS hackers,
so they may not have been aware of it until recently - I'm not sure.

> I don't believe that I've proposed an "overloaded" form of the KEY
> RR; I've just proposed extending it in the way that it supports.

I think maybe Andreas should respond to this.   Your use of the KEY
record seems incorrect to me, but I'm by no means the expert.

> new RR type).

Adding RRtypes is not difficult.   Given that DNS update support
wasn't even available until BIND 8.2, which is a very recent release,
I don't think this should be considered a major impediment.   I can't
see why this can't be available in the next release of BIND 8
(although having said this may elicit flamage from my colleagues in
BIND-8-land... :')

> The number of sites that will have difficulty deploying the current
> proposal is much smaller. Using the KEY RR would allow the DHCP
> community to begin deploying useful functionality promptly.

I think doing things the right way is better than doing things the
expedient way.

> that has to make its way through the DNS WG.

That's true, but doesn't mean that a new RRtype is the wrong way to
go.

Andreas?

			       _MelloN_

---

From: Mark Stapp <[email-masked]>
Date: Tue, 26 Oct 1999 14:42:13 -0400 (EDT)

Ted,

>record seems incorrect to me, but I'm by no means the expert.

I guess I still don't understand what your objection is. I thought your 
first mail said that it was the "DNS guys" who objected. This message 
suggests that no one else objected until you objected. But you also ask 
Andreas to respond with the details of the objection, saying that my 
proposal merely "seems incorrect" to you.

Never mind the "formal counterproposal": if you're the one who objects, you 
should state your objection clearly so that we can evaluate it and respond 
to it. I've stated pretty clearly that the chapter and verse that defines 
the KEY RR supports extending it, and that that's all I think we should do: 
we should use the RR the way that it's specified. Do you read the 
specification differently? Why add extensibility to the KEY RR if no one's 
allowed to extend it?

>(although having said this may elicit flamage from my colleagues in

You can't add new RR types without requiring that the sites that want to 
use them upgrade all of their BIND servers. That's not a flame, but it is 
an impediment to deployment. This is a well-known problem, and the only 
solution is a BIND transplant. That's why flexible, extensible RRs like the 
KEY RR are useful: new uses can be found that are backwards-compatible (at 
least back as far as 4.9.5 or maybe 4.9.2), and that can be deployed promptly.

>I think doing things the right way is better than doing things the

Frankly, I don't think that I've made an "expedient" proposal. I've made a 
proposal that complies with the DNS protocol specifications for the KEY RR, 
and that's a practical solution to the need we have.

>That's true, but doesn't mean that a new RRtype is the wrong way to

Certainly: but using the KEY RR suffers no demonstrated disadvantages, 
works technically, and can be deployed readily. I'd like to see from you 
why a new RR must be deployed to support the dhcp-dns draft. Just because 
we can initiate the process of inventing a new RR doesn't mean that we have 
to do so in order to provide the capabilities that the dhcp-dns draft 
describes. Please state your objection to the proposal that's on the table, 
and let's see whether there's consensus in the WG that it's insurmountable.

-- Mark

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 26 Oct 1999 14:45:19 -0400 (EDT)

> record seems incorrect to me, but I'm by no means the expert.

The KEY record is clearly intended specifically for cryptographic
purposes.  RFC2535 says "These resource records represent the public
keys of entities named in the DNS and are used for key distribution."
DHCP client identifiers are not public keys.  The "protocol" field in
the KEY record is there to support the storage of public keys for
cryptographic protocols other than DNSSEC, not to support non-crypto
protocols.

Using the KEY RR for non-crypto purposes will work, but that does not
mean it is appropriate.

> Adding RRtypes is not difficult. [...] I can't

Adding support for the DHCP RR to name servers (including BIND 8) is
trivial thanks to its similarity to the existing NSAP type.  The
factors limiting the prompt deployment of the DHCP RR are elsewhere:

1. Getting an RR type number assigned by IANA.  This is one reason why
I chose to make the DHCP RR proposal a DNSIND WG draft - I believe this
is the fastest route to getting a number assigned.

2. Getting existing name servers upgraded, especially secondary name
servers that may not be under the control of the organization wishing
to use the DHCP RR.
-- 
Andreas Gustafsson, [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Oct 1999 14:47:09 -0400 (EDT)

> proposal merely "seems incorrect" to you.

No, that's not true - the DNS guys who objected did so when they
independently read the draft, not when I prompted them to take a look
at it.  The above statement makes it sound like I am trying to
instigate trouble here, which is not the case.   I simply think this
is an incorrect usage of the KEY record, but am deferring to those who
understand DNS better than I to explain why in detail.   I've already
apologized for my failure to call this to their attention and complain
more vociferously earlier.   I'm sorry I wasn't able to come to IETF
in Oslo, but Oslo was just too hard for me to get to - unfortunate,
because I had wanted to bring this up there.

If you read rfc2065 where it describes what keys are for, it's quite
clear that it intends that keys be used for signing transactions on
zones.   Nowhere does it suggest that the key record implies some kind
of ownership, or that it be used as an identifier.   Your proposed use
of the KEY record goes directly against the intended purpose of the
KEY record.   This is why I object to it.   I don't know what
Andreas's objection is, which is why I asked him to state it.

I am concerned that in using the KEY record the way you have, you will
confuse programs that are using it in the intended way.  In addition,
I am concerned that by using a record type which has a seperate use,
you may create a situation where the KEY can't be properly used as an
update prerequisite.  Finally, I am concerned that your usage will box
us into a corner later on when we try to extend the uses of the KEY RR
in ways that are relevant to its intended use.

> I've stated pretty clearly that the chapter and verse that defines 
> the KEY RR supports extending it,

..to different public key signature algorithms...

>  and that that's all I think we should do: 
> we should use the RR the way that it's specified.

With this, I agree completely.

> Do you read the 

Extensability is intended in the sense that if the current signature
algorithm is found to be flawed in the future, a different one can be
chosen without breaking the protocol.   It is not, in my reading,
intended to allow the KEY record to be used for something entirely
other than authenticating DNS transactions.

> use them upgrade all of their BIND servers.

You can't use the DHCP-DNS update protocol without upgrading your DHCP
server, either.   If you want new functionality, sometimes you have
to, well, deploy it.   I agree with you that this is an impediment,
but I think doing the right thing now is better than having not done
the right thing will be later, and I'm sorry, but despite your
insistence to the contrary, using the KEY record in this way is not
the right thing, and it says so right there in black and white (er,
white and blue :') in the RFC!

I think that if you actually consider a real deployment strategy,
you're really not talking about a lot of DNS servers that would have
to be upgraded - it's not like caching DNS servers are ever likely to
see these records, for example, because resolvers will never ask for
them.  So in all likelihood you have to upgrade your internal
primaries and secondaries, and if your DHCP server is on a different
system, you have to at least install a DHCP-RRtype-aware resolver on
that one system.   IMHO, it's worth it.   I'm only sorry I didn't make
a fuss about this sooner.   Sigh.

			       _MelloN_

---

From: "william.wells" <[email-masked]>
Date: Tue, 26 Oct 1999 16:02:10 -0400 (EDT)

The link provided in one of the previous mail messages provided a good
description of the privacy issues. To overly simplify, the issue was that
people could use a system name, IP, or MAC to determine a system. Hence, the
document described periodically changing these values so that tracking
things back would be more difficult. However, having said that, rather than
trust my summary, read the document.

Within a business, the privacy issues are less important but their issues
have some validity, especially when it comes to ISP connections from homes
where things aren't hidden behind firewalls. Its similar to software vendors
stamping documents or software with a code which uniquely identifies the
system where a document was prepared and then registering that system ID in
a world-wide database. There are cases when freedom of speech can be
hindered if you know that someone can track a document back to you by some
hidden code.

As far an encrypting the MAC, I agree with your approach. Indeed, for
privacy concerns, the encrypted result could change every time the IP was
renewed (which addresses some of the privacy issues) providing that all the
other DHCP servers in the "group" could decode it (a public key algorithm
with random 'stuff' added to the MAC?). 

The previously mentioned documents recommended using MD5 since that is
apparently already required by the standards.

> -----Original Message-----
> From:	Mark Stapp [SMTP:[email-masked]]
> Sent:	Tuesday, October 26, 1999 10:58 AM
> To:	Multiple recipients of list
> Subject:	Re: Comments on draft-ietf-dnsind-dhcp-rr-00.txt 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Oct 1999 17:04:00 -0400 (EDT)

> with random 'stuff' added to the MAC?). 

I think the record has to have a predictably constant value.
Probably TRT is to hash the client MAC with some shared secret key and
stuff the output of the hash in the DNS.

			       _MelloN_

---

From: Diana Lane <[email-masked]>
Date: Tue, 26 Oct 1999 18:21:27 -0400 (EDT)

Mark,

While I'm not a DNS "guy," ;-) we had a discussion back in June (there was also a discussion on another list in April) in which I was concerned about the ramifications of the following type of environment:

zone master for "example.com" runs BIND 8.x, supports KEY RR, etc.
zone slaves for "example.com" run BIND 4.x, do not understand KEY RR, etc.
zone master accepts dynamic updates from DHCP servers, which use KEY RR to distinguish the "owner" of a name

What happens to the slaves when they go to do a zone transfer?

Your response was, in a nutshell, that the number of organizations with many servers to upgrade and a long upgrade cycle was too small for this to be a global concern, and as I saw only one or two other people voicing the same concern, I dropped this, for the time being focusing on home-grown protections.  Your assertion that your proposal does not involve "overloading" the KEY RR but rather "extending" it leaves me nonplussed, however.  How does overloading differ from extending?  If you have time, I would like to be enlightened (this can be offline if it is inappropriate online).

However, in the same vein, I would not like to be dependent on a new RR type that does not yet exist, such as has been proposed.  That would put both standardized protection and server level-setting even farther into the future.

Thanks!

Diana Lane
IP Research & Development
Wal-Mart Stores, Inc.
501/277-3177
Be gentle to all, and stern with yourself. - Teresa of Avila

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 26 Oct 1999 23:52:29 -0400 (EDT)

>Ted,
In order to get this out, I have not had enough time to check my writing
I apologize for any overly strong comments and muddled arguments that
may be in here, but some of us can not write as well and fast as Ted ;-)

>>so they may not have been aware of it until recently - I'm not sure.

This is also my fault, I knew about the work and disagreed with it
but did not forward you my comments, sorry. 

>>record seems incorrect to me, but I'm by no means the expert.

Key is for Public Key material, you want to stick arbitrary binary (or
some other data) into it.  BAD!

>proposal merely "seems incorrect" to you.

Well before we start throwing rocks at each other, if you re-read the
Abstract of your Internet draft (the June version) there is NO 
indication that the draft defines new a DHCP options OR proposes 
overloading of existing DNS records. 

In the process of figuring a bigger mess, that is Dynamic update and
secure dynamic update in DNS (mainly in the context of Bind-9) 
Andreas, Ted, me and few others talked about the issues involved. 
DHCP is not the only customer of Dynamic update, and things must be looked at
in a global sense as well as local one, one of the important issues that
needs to be addressed is how will this fit in with the security mechanism 
selected for DNS dynamic update, if mechanism selected is friendly to
the requirements of DHCP then that changes things. 

The DHCP-DNS draft has been around for a long time and been updated many 
times but one of the problems it has run up against is that most people do 
not know or agree on all the  requirements from both DNS or DHCP 
perspectives.

I (as the DNSIND working group co-chair) encouraged Andreas to 
document his ideas and put them forward, because of his experience in
implementing both DNS and DHCP servers.
My hope was to start an intelligent discussion on the topic and help us
all come to an agreement faster, by having a counterproposal on the table 
it is easier to judge the merits of the two proposals.

>specification differently? Why add extensibility to the KEY RR if no one's 

Ted and Andreas are not the only one's arguing but even if they where the
only ones that in my opinion is enough to take a step back and think, 
neither one of them is an troublemaker. 

At this point I'm not allowing any drafts to enter as official DNSIND working
group documents that in any way extend or modify the KEY, SIG and NXT records
unless the change is deemed beneficial to DNS and DNSSEC. 
Overloading of KEY record with random data is not beneficial. 
The KEY record is extensible to accommodate NEW KEY algorithms, 
not random data, the SINK record is for that. 
Side bar: SINK record is now in WG last call, so far all the comments received
have been against advancing that proposal.

>> > There are, unfortunately, two problems with a new RR type:

There are the same problems with any solution.

>least back as far as 4.9.5 or maybe 4.9.2), and that can be deployed promptly.

If you check the code you will notice that bind-4.9.x and Bind-8.1 and
Bind-8.2.x will not load KEY algorithms that they do not know. 
Thus such servers can not be used as primary or secondary for zones 
with DHCP overloaded KEY record. Thus your argument is not valid.

>and that's a practical solution to the need we have.

I beg to differ, we need to think about the semantics of record that 
is used by DHCP, can there be one and only one record of this kind, or
can there be many ? 
If the requested semantics are one and only one then mucking with the KEY
record or any other existing record will not achieve your goal. A new type
for DHCP specific use on the other hand can have the right semantics 
attached to it. 

>>That's true, but doesn't mean that a new RRtype is the wrong way to

The dependency exists any way as some draft will have to explain how
to store the data in the key record that draft would have to be processed
by the DNS working group. 
The DNS working group can process drafts of new types in short order.
The only thing I can not guarantee is the result up or down.

>and let's see whether there's consensus in the WG that it's insurmountable.

The object of the exercise is to DO THE RIGHT THING, not do what seemed 
like a good idea at some point. The whole ID process it to foster 
ideas and allow differences to be evaluated. 

I stated my objections and technical reasons above,
in addition I want to point out the following:
Your draft as it is now uses an appendix to hint at the use of the KEY 
record and has algorithm as TBD. To get any reservation will require 
interaction with the DNSIND working group or it's successor. 
Your document will have to go through IETF last call at some point, 
it is better to get the dialogue over with now, than during IETF last call. 

I hope we can discuss and resolve this issue before the end of the IETF. 

	Olafur (speaking as the DNS??? WG chair)
----------------------------------------------------
Olafur Gudmundsson - NAI Labs (443)-259-2389 
the Security Research Division of Network Associates, Inc.
3060 Wasthington Road, Rt 97, Glenwood MD 21738
[email-masked]  [email-masked]  Private: [email-masked]

---

From: Mark Stapp <[email-masked]>
Date: Wed, 27 Oct 1999 09:49:28 -0400 (EDT)

Yes, any 'randomness' would have to be generated identically among all the 
parties who needed to transform a given client-id in order to compare it to 
RR contents. That's probably more complication than is necessary.

-- Mark

---

From: Mark Stapp <[email-masked]>
Date: Wed, 27 Oct 1999 12:23:06 -0400 (EDT)

Olafur,

Thanks for your extremely direct and clear response: you've nothing to 
apologize for in the effective email department. If anyone deserves an 
apology, it sounds as if it's Ted and Andreas. I didn't mean to dismiss 
anyone as a idle troublemaker, to try to end-run around issues that are the 
responsibility of DNSEXT, or to avoid the right thing. I didn't understand 
Ted's original objection, not having been party to the discussions that 
have clearly been taking place. I thought that I'd proposed something that 
was reasonable, and that enough folks had reviewed that proposal over the 
last year to have revealed any fundamental mistakes. The objections you 
raise to the use of KEY *are* fundamental.

If the current dhcp-dns draft (there is a new one, but it hasn't cleared 
customs yet this week) doesn't use the right RR, I'll revise it to refer to 
the new DHCP RR. That won't be published before Washington, obviously, but 
I'll bring it along and see if I can post it somewhere. I'll also add a 
section describing the MAC/client-id privacy issue, and an optional method 
for encrypting that data.

Andreas: could we chat about the DHCP RR's RDATA format? I think it might 
need to include a version, and it probably should be composed of binary 
data that's CLVs so it can be extended in the future. The section of 
dhcp-rr titled "DHCP RDATA Format" suggests that the format of the RDATA 
might need to be specified in the DHCP RR draft, but it also says that DNS 
software should consider it opaque. May I send you some sample words? Or 
can your draft just reference the DHCP-DNS draft, and leave the 
specification of the RR's contents to a draft or RFC that is in the DHC group?

Thanks,
Mark

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 27 Oct 1999 15:21:32 -0400 (EDT)

> data that's CLVs so it can be extended in the future.

I also think it should be extendable.  When using the DHCP RR to store
multiple kinds of DHCP information , I would prefer to use multiple
DHCP records rather than a single DHCP RR containing multiple
key-value pairs.  That's the traditional DNS way, and it also makes
the explicit LENGTH field unnecessary.

I don't think an explicit version field is necessary, either.  
An RDATA format like this one should suffice:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   SUBTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                    DATA                       /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The interpretation of DATA depends on the value of SUBTYPE
(or CODE, if you prefer that terminology).  E.g.,

  SUBTYPE = 0000 (hex)

      Reserved, not to be allocated.

  SUBTYPE = 0001 (hex)   

      Hashed client identification.  DATA is the 16-byte MD5
      hash of the client-id DHCP option data received from the
      client, excluding the code and length bytes.  [This section 
      should also specify the method used to synthesize a client-id 
      option for clients that did not send one.]

  SUBTYPE = 0002 ... FFFF (hex)

      To be allocated by IANA in cooperation with the DHC
      Working Group.

Any kind of CLV or SUBTYPE scheme will of course require a nontrivial
"IANA Considerations" section in whatever draft/RFC it is specified
in...

> The section of 

I would prefer to leave the detailed specification of the RDATA format
to a DHC WG draft; you may consider the above RDATA format suggestion
input to that draft.

In any case, the RDATA format should remain opaque to the DNS server.
No matter what internal structure the DHC WG defines for the RDATA
field, its text representation in DNS server zone dumps must continue
to be a single hexadecimal string, so that the implementation of the
DHCP RR in DNS servers does not have to change as the specification
evolves or is extended.
-- 
Andreas Gustafsson, [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Oct 1999 17:20:52 -0400 (EDT)

> key-value pairs.

OTOH, I think it would really be better to just say what the RR is
for, and leave it at that.   It should just be an opaque hunk of data,
chosen by the DHCP server.   Either the DHCP-DNS or the DHCP RR draft
should say how the server computes this hunk of data, but otherwise it
should be left alone, because this data needs to be usable in an
update message as a prerequisite, and if the DHCP server has to do a
query to see what the value is first in order to see what to put in
the prerequisite, you've kind of defeated its purpose.

I guess I could hang with a version number, because the default
version could be set in the DHCP server configuration, but I really
don't like the idea of being able to store multiple arbitrary hunks of
data in the RR that's being used by the DHCP-DNS draft, whatever RR it
is that gets used.   I don't see any reason for a special DHCP record
for storing other client-specific data in the DNS - if people want to
store client-specific data in the DNS, the TXT record already does
that.

			       _MelloN_

---

From: "william.wells" <[email-masked]>
Date: Thu, 28 Oct 1999 11:10:57 -0400 (EDT)

My initial response was that having DHCP update the TXT record would
conflict with my usage of the TXT record. But, if DHCP is going to be the
thing which created the record in the first place, I wouldn't really have
any need to use the TXT record.

-- Different/related topic

One usage of putting a end-system identifier (ex: encrypted MAC) is the
ability to determine if the IP currently assigned really "belongs" to the
end-system. For us, this would allow us to manually assign an IP address
outside of the normal DHCP pool (perhaps in a "manually assigned" pool known
by DHCP but which DHCP leaves alone) and have the server return the manually
assigned IP address on a DHCP request from the end-system. Perhaps this
capability already exists in some servers.

If I can do the manual assignment via a DHCP server, then it could scribble
the necessary information into the TXT record; otherwise, I'd need to need
to add the information by hand. If done by DHCP, I assume DHCP would
allocate one from the pool instead of specifying the entire IP address (?).

Note that this is different than using a "BOOTP" style static assignment. If
the end-system changes building, DHCP would need to reassign a dynamic IP
address as the network changed. All the static assignment algorithms I've
seen will continue to deliver the now incorrect IP address.

The other big advantage I see of the end-system identifier lies with
multiple DHCP servers (redundancy). If one server can look in DNS and
determine that the end-system has an existing valid assignment from another
DHCP server, it may be possible for the failover DHCP server to renew the
least of the original IP address even though its outside if its normal
allocation pool. If this were done, it would probably be wise to require
that the failover DHCP server(s) know about the allocation pools of the
other server(s) and perhaps even that one of the other server(s) allocated
the IP address in the first place.

> From:	Ted Lemon [SMTP:[email-masked]]
> Sent:	Wednesday, October 27, 1999 4:21 PM