Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

From: Peter Koch <[email-masked]>
Date: Tue, 09 Jul 2002 17:36:28 +0200

> Let's say I have a host, toccata.fugue.com, with sshd running on it.   So 
> what's wrong with having an APPKEY hanging off of sshd.toccata.fugue.com?   

While applications nicely fit into the hierarchical model (as well as
e.g. interface names) ...

> We don't currently use subdomains of hostnames - what's the conflicting use 
> that we're ruining by doing this?

... you can't tell for sure what a host is. How do you find the SSH key
for the host "fugue.com" in your example? How do you find the "WWW" or "FTP"
key?

-Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Robert Elz <[email-masked]>
Date: Wed, 10 Jul 2002 19:38:29 +0700

Date:        Tue, 9 Jul 2002 10:16:34 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | We don't currently use subdomains of hostnames - what's the conflicting use 
  | that we're ruining by doing this?

Says who?   We currently put "hostnames" anywhere in the DNS tree that
we like.

[email-masked] said in a different message:
  | No offense, Elz-san, but this is sounds like "the way I think it
  | should be  used," which isn't very constructive, since you are not the
  | only one on the  planet who uses it.   My  server's hostname is not a
  | delegation.   It's in  the namespace.   What do you mean, "the way it
  | was intended to be used?"    

If the namespace was delegated to you, it should be your choice how you
use it.   If you don't want your server's hostnames to be delegated, or
to have delegated sub-domains, or whatever, that's your choice, as it
should be.

Just stop trying to tell everyone else that they're required to assign
names, and perform delegations in the way that you believe it should be
done - every domain name owner gets to decide this for themselves.

And that includes sticking _'s anywhere in any domain name that they like.
And almost any other character.

The only restrictions are that the names not violate the rules of the
protocols in which they're used (the DNS's rules relate to lengths, and
no more, other protocols have other rules).

If I want to do

	example.com.		IN	MX	_sshd.example.com.
	_sshd.example.com.	IN	NS	some.random.other.site.

Then that's what I should be allowed to do (regardless of how stupid
that you believe it is, it is legal, and there are reasons for doing
just this - if perhaps not that particular name).

No-one should be defining away the namespace to make that cause things
to fail.

kre

---

From: Derek Atkins <[email-masked]>
Date: 10 Jul 2002 11:31:55 -0400

> No-one should be defining away the namespace to make that cause things

Nobody is proposing any such thing.  Nobody is making restrictions on
what you _can_ do.  However, this is a proposal just that "if you want
to do FOO, do it _this_ way" in order to be compatible with everyone
else.  This is NOT the same thing.

If the proposal for "if you want to store an SSHD key in DNS, you
should prepend _sshd to the hostname" goes through, you can still do
what you want as your suggest, but you just will not be able to store
SSHD keys in DNS following the convention.  But that is perfectly
within your right as a zone operator to not follow conventions.  It
just means your zone wont play with existing applications that use
those features.  If you don't want to provide those features, you are
well within your rights to make that choice.

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com