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

From: Steve Gonczi <[email-masked]>
Date: Mon, 25 Oct 1999 11:36:04 -0400 (EDT)

Gretings,

I like the idea of creating a Client id / MAC address mapping in DNS. 
This makes a lot of sense. I would, however, like to see the format and
exact content defined in the draft. This is the right place for it.

The alternative is to create yet another short draft, just to nail this
down.
aRRGH...

Steve Gonczi

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 1999 14:23:41 -0400 (EDT)

> As we've been running an internal automatic DNS update mechanism which uses
> MAC addresses as a way to denote ownership of a DNS entry, I'd like to
> review what's been said and would like to know where the archives are.

The archives aren't publically available - it was a private discussion
between me and some of the BIND developers.   The basic issue is that
the use of the client MAC address in IPv6 local address discovery has
been flagged as a "privacy" issue, and much fuss made about it.   So
I'm leery of trying to advance a proposal that not only makes this
information globally visible while it's being used, but actually
stores it in a database.   I'm hoping that people can tell me whether
for their purposes a "CREATOR" record would do as well as a
"CLIENT-ID" record.   I think for DHCP it would.

Your case is a specific solution, and you've obviously already decided
there's no privacy issue, so that's fine, but the standard protocol
has to run the gauntlet of public opinion, and I think public opinion
will frown on this use of the MAC address.

> As for the "publicly searchable" issue, and keeping in mind that I haven't
> been paying attention, it seems like this field could be made to only
> distribute to selected servers.

There's no such mechanism in the DNS.   If it's published, it's
published, and anybody can read it.   If you run split-horizon DNS,
your users may be somewhat protected, but we can't assume that this
will be the case generally, particularly since there are plenty of
people who consider split-horizon DNS a mistake.

> Another option would be to encrypt the MAC address on the DNS server.

I don't see why we should bother with this.   I don't really see the
value of storing this information in the DNS in the first place.

			       _MelloN_

---

From: "william.wells" <[email-masked]>
Date: Mon, 25 Oct 1999 14:21:48 -0400 (EDT)

I have to apologize that I've not been paying much attention as I'd like due
to various other "fires" but I triggered on "MAC".

As we've been running an internal automatic DNS update mechanism which uses
MAC addresses as a way to denote ownership of a DNS entry, I'd like to
review what's been said and would like to know where the archives are. Our
locally written mechanism is probably in the 5-10 year old range and doesn't
use DHCP; all IP reservation information is maintained in DNS which allows
redundant servers to provide the same information for existing systems.

In our case, when a PC needs an IP address, we see if the DNS entry
corresponding to the PCs existing IP address matches on MAC address and is a
valid IP address for the sub-net the PC is on. If so, we use whatever IP
address (and name) is currently assigned. If not, we search DNS for the MAC
and if it belongs to an IP address on the sub-net the PC is on, we use that
one. Otherwise, we assign a new IP address according to various rules and
remove the old from the old sub-net.

We allow multiple subnets on a network segment (192.168.16.x and 172.24.x.x,
for example). As we use IP address for validating some types of accesses, we
normally assign out of a pool (much like DHCP) but also allow a manual
assignment to an IP address outside of the pool to "stick". Yet, if the
assignment expires (weeks here) or the system gets moved to another address
space, a new IP will be assigned in the default pool.

As for the "publicly searchable" issue, and keeping in mind that I haven't
been paying attention, it seems like this field could be made to only
distribute to selected servers. This would keep the "public" to the systems
which are performing the IP address assignments (or validation), not the
entire Internet. If you are going to allow valid existing assignments of IP
addresses outside the pool managed by a particular DHCP server to "stick"
(redundant servers), then you need more than who created the IP address, you
also need to know the MAC address.

Another option would be to encrypt the MAC address on the DNS server. If the
systems which are looking for a MAC address performed the encryption prior
to asking for the MAC (all using the same key), then the DNS server wouldn't
need to decrypt the information in order to locate the entry. In this case,
a 1-way encryption algorithm could be used. Indeed, the DNS server wouldn't
necessarily need to even know the algorithm.

Again, I apologize for jumping into the discussion "cold" and will be glad
to read the archives someone could point them out.

> -----Original Message-----
> From:	Ted Lemon [SMTP:[email-masked]]
> Sent:	Monday, October 25, 1999 11:49 AM
> To:	Multiple recipients of list
> Subject:	Re: Domments on draft-ietf-dnsind-dhcp-rr-00.txt 
> 
> 
> 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.
> 
> 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?   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.
> 
> 			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 1999 12:48:50 -0400 (EDT)

_MelloN_

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 25 Oct 1999 15:24:08 -0400 (EDT)

> stores it in a database.

Please note that the use of MAC addresses in the public DNS for
identifying clients is specified in draft-ietf-dhc-dhcp-dns-10.txt,
not in draft-ietf-dnsind-dhcp-rr-00.txt.  The DHCP RR is simply
intended as a mechanism of storing whatever client identifiction
draft-ietf-dhc-dhcp-dns cares to specify.  I am not trying to say what
information DHCP servers should store in the DNS, or even whether they
should store anything at all.  All I'm saying is that if something is
stored, it should use a unique record type instead of overloading KEY.

If you feel the use of the MAC address is inappropriate, you need to
take it up with the authors of draft-ietf-dhc-dhcp-dns-10.txt.  If the
dhcp-rr draft does not advance, it does not mean that the MAC address
is not published in the DNS - it just means that it is published in a
KEY record rather than a DHCP record.  That would hardly be an
improvement.

Pre-00 versions of the dhcp-rr draft in private circulation did
contain a reference to the specific MAC based form of client
identifiers described in the current version of the dhcp-dns draft,
but in response to criticism, I removed that reference before
submitting the draft for publication.  Thus, the dhcp-dns draft could
be changed not to use the MAC, without having to change the dhcp-rr
draft.

> value of storing this information in the DNS in the first place.

This, too, is a draft-ietf-dhc-dhcp-dns issue.
-- 
Andreas Gustafsson, [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Oct 1999 16:41:41 -0400 (EDT)

> This, too, is a draft-ietf-dhc-dhcp-dns issue.

No, not really.   Yes, the DHCP-DNS draft does specify using the MAC
address, which I think is wrong, and I am indeed referring to that
draft when I ask people on this mailing list whether or not they think
this is necessary.

But the option proposed in the dnsind-dhcp-rr draft _is_ DHCP-
specific, and the only DHCP option that it would make sense to store
would be the MAC address or client identifier, both of which have the
problem I described.  This is why I'm suggesting a CREATOR RRtype
would be better.  I think we should decide what we want to store in
the DNS before trying to advance a DHCP-specific draft describing a
new DNS record.  I think you're right to be trying to create a better
way to do this, but I think we need to decide what we need before you
advance a draft providing it!   :')

			       _MelloN_

---

From: Nathan Lane <[email-masked]>
Date: Mon, 25 Oct 1999 16:44:08 -0400 (EDT)

> Sent:	Monday, October 25, 1999 1:24 PM
	[Nathan Lane]  It really goes deeper than that...and the overloading of the KEY resource record is of specific concern to us.  It was brought up last April by members of our team.  In our opinion, the owner of the DNS record is specifically NOT the client, but the CID from the client stored in the DNS is useful for us.  A "creator" concept may help the superfluous updates that could occur under certain failover conditions as well.  (And, the use of CID vs. MAC vs. GUID vs. whatever is really heating up.  What should be used to identify the client???  Pretty soon the client will have more ID's than a quick change artist in the former Soviet Union!)

	(Also, note that the MAC is not necessarily globally unique.)

	I like the current use of the TXT record to store the CID associated with a DNS PTR.  It works enterprise-wide without having to upgrade even our oldest, most catankerous servers.  Our server doesn't let us turn this feature off...it would be nice if it did, so we would have the choice.  Given the option, we'd probably continue to use it.  It's a LOT easier to look in DNS for a TXT record than to go to a switch and find the MAC.  I really hate introducting new "views" into the DNS space - user A can see SRV records, but user B cannot see SRV records, etc...a new RR Type will have a lag, in our environment, of about three to five years.

	A copy of an initial discussion is below:

-----Original Message-----
From:	Diana Lane 
Sent:	Tuesday, June 08, 1999 1:27 PM
To:	[email-masked]'
Subject:	RE: Dynamic v. static entries 

Olafur Gudmundsson wrote:
	"Cricket Liu" writes:
	 > Hi, folks.
	 > 
	 > I just got back from a customer who's planning an extensive Windows 2000
	 > rollout, and I'm beginning to see just how important it'll be to have a
	 > feature in BIND to make part (i.e., certain domain names or RRs) of a
	 > dynamic zone static.
	 > 
	 > We found that the Microsoft DHCP Server in Windows 2000 will just delete A
	 > RRs attached to a name if it wants to add an A RR to the name.  Here's an
	 > example:  You boot DHCP client foo, and foo gets IP address 192.168.1.2.
	 > Unfortunately, you've already got a server in the zone called foo.  Whether
	 > you've given the DHCP client or the server responsibility for adding DHCP
	 > client foo's A RR, server foo's A RR gets deleted.  Yuck.

	I see two problems with this behavior, 

	This is a protocol violation. 
	DHCP server SHOULD/MUST NOT delete data that it is not the source of. 

	This is a serious security risk, any dynamically configured machine can 
	now take out a series of servers by simply 
	changing it's hostname and doing DHCP DISCOVER. WOW!!!

In the case of a workstation's data replacing that of an industrial device such as a conveyor belt, it is also a serious safety risk.

I sent some comments regarding this topic to the dhcp-v4 list about two months ago.  I have read draft-ietf-dhc-dhcp-dns-09 and I realize that it proposes a KEY RR to protect an existing entry from modification; however, that approach requires support for RFC 2065.  In an enterprise the size of Wal-Mart, it is highly improbable that all name servers will be upgraded to this level in less than two years.  I apologize to those for whom this is repetition, but I believe those comments remain relevant:
Given a zone on a server that supports dynamic updates, where some names in the zone belong to statically addressed servers performing business-critical functions, one does not want one's DHCP server(s) to blithely send updates that replace those servers' A records and PTR records with those of a DHCP client that happens to send the same hostname as the server in its DHCPREQUEST.  That would be a Bad Thing.
[...specific method deleted...involved using TXT records to protect important servers through the use of an update prereq...]
There are some caveats associated with this approach:  The initial DNS lookups and prerequisite queries need to be performed before the DHCPOFFER so that any policy-specific options can be included in the DHCPOFFER.  The actual update, if any, may be performed after the DHCPACK is sent in order to avoid updates for incomplete transactions. In addition, Windows NT clients complain loudly via an obnoxious dialog box if they are sent options they did not request.  This may be considered desirable as it will almost certainly result in the user opening a trouble ticket (which will lead to the client name being changed to something acceptable).
I have seen two other approaches to the problem of name collisions.  Neither meets my needs in supporting my customers.  One approach is to disambiguate the name a client sends by appending extra characters if the name sent in the hostname option field is the same as an existing domain name.  This has a rather nasty tendency to break certain applications that rely on a specific PTR record being returned.
Another approach is to replace any existing resource record by that domain name with the new domain name and data, regardless of any other factors.  This approach provides no protection against server names being usurped by PCs, printers, whiteboards, or other DHCP clients.
Thanks!

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

	-Nathan Lane
	Wal-Mart Stores, Inc.
	(501) 277-3177

---

From: "william.wells" <[email-masked]>
Date: Mon, 25 Oct 1999 19:26:12 -0400 (EDT)

There is some differences in approaches between our solution and DHCP. In
our case, the DNS table contains all information related to IP address
assignments (but not the algorithm for assigning IP addresses); that is, the
DNS table is "the" IP assignment table. Hence, the allocation software scans
DNS to determine free slots and such. When it wants to allocate an IP
address, it actually asks the IP manager to update DNS with a new IP for
this MAC/hostname. This is like DHCP in that there is a IP manager but
unlike DHCP which uses separate tables. Please remember that ours predated
the availability of DHCP on PCs so our approach was different. DNS was
readily available so we used DNS to hold information and since DNS is where
systems (firewalls, for example) go to determine the IP addresses of other
systems.

We put the DNS information in TXT records as others in this thread have
mentioned but these aren't published outside since all of our internal
systems use the "internal only IP addresses"; we have different DNS servers
for the Internet. The main reasons for storing the MAC address, my
perspective, is to validate ownership of the IP (but may be unnecessary in a
true DHCP world)and to allow an easy mapping of MAC address to IP address.
Once you have a MAC address, you can use other network tools to determine
which hub/switch/port, etc the system is on.

You are correct in that our solution works in our environment and hasn't
needed to be reviewed publicly. I'd love to dump ours in favor of DHCP/DNS
but, last I checked, DHCP didn't support our environment well. I'm looking
forward to when it does.

It seems to me that allowing only the original "creator" to modify/delete an
entry would make redundant DHCP servers which serve the same address pool
difficult; especially if the original server which allocated the IP address
was unavailable. However, defining a creator pool (multiple server IP
addresses which you define as working as a unit) would work assuming that
the multiple DHCP servers coordinate their information.

It would also seem to make it difficult for a second DHCP server to 'yank'
the IP address from the first DHCP server if the system crossed server
network boundaries (and therefore used different servers). In environments
where changing IP addresses for any reason other than a network switch is
considered to be a bad thing, I think you need to use long lease times. If
you wait for the long lease to expire, you may fill a class C network with
systems which no longer exist. Of course, 'yanking' an IP address assignment
is somewhat scary if you can't control who and when....

I've just gotten the mail from Mark Stapp so will go read that and learn
more.

> Sent:	Monday, October 25, 1999 12:58 PM
> To:	william.wells
> Cc:	Multiple recipients of list