Subject: What is a type? I-D ACTION:draft-iab-dns-choices-00.txt

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 19 Jan 2005 11:48:05 +0100

The following may be of some interest to existing and future creators of
DNS-based "kitchen sinks" [I-D: draft-iab-dns-choices-00.txt]

What is a type?
===============
Consider the following sample definition from the Internet-Draft
draft-delany-domainkeys-base-01.txt (describing Yahoo's "DomainKeys"
proposal for improving e-mail security):

    brisbane._domainkey  IN TXT  "g=; k=rsa; p=MHww ... IDAQAB"

A popular view is that this is an example of "subtyping" the TXT type.
But this view is incorrect from a real-world perspective.  The data type
is actually "_domainkey" and nothing else.

So what's TXT then?  Well, all non-local data types need some kind of external
representation and the by far most common way to represent "config" data to be
administered by humans (and machines), is to use a textual representation.
TXT does that for you.  Yahoo would due to this, not had gained anything
(but troubles) by defining and registering a DomainKeys-specific text container.

Performance
===========
Since DNS lookups can be done with full granularity (*._domainkey.example.com
or brisbane._domainkey.example.com), it seems that there are no apparent
performance issues to solve.

A single remaining issue
========================
Although hardly a problem for DomainKeys, this definition actually makes
"_domainkey" a reserved word in an unmanaged global namespace.  If you scale-up
this type definition concept by some two or three magnitudes, you may see why
URIs and OIDs have rather become the norm for most other Internet standards.

In case anybody really is interested in solving this "potential problem in
the making", this is in fact absolutely trivial.  Assuming that DomainKeys
is defined by RFC 6789, you could use the RFC as the foundation for the
DomainKeys private data type by assigning it the IETF URN "urn:ietf:rfc:6789".
Running this URN trough a suitable  URI-to-DNS-label converter, you could
end-up with something like this:

  brisbane.urn_2ietf_2rfc_26789  IN TXT  "g=; k=rsa; p=MHww ... IDAQAB"

By using this somewhat ugly scheme, new DNS resource types can be safely
defined by various private and public communities, with no more central
control than required by any other Internet development.

Note: DomainKeys only served as an example, but the basic scheme applies to
a large class of other applications that could use DNS-based data objects.

Anders Rundgren
Principal Engineer, RSA Security

--
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: Edward Lewis <[email-masked]>
Date: Wed, 19 Jan 2005 10:59:32 -0500

>DNS-based "kitchen sinks" [I-D: draft-iab-dns-choices-00.txt]

(History soapbox comment)

This is defined in RFC 1034, section 3.6 (Resource Records) starting 
on page 11.  In particular, this is taken from page 12:

# When we talk about a specific RR, we assume it has the following:
#
# owner           which is the domain name where the RR is found.
#
# type            which is an encoded 16 bit value that specifies the type
#                 of the resource in this resource record.  Types refer to
#                 abstract resources.
# ...

*Redefining* terms has proven to cause more confusion than progress.

 From someone who's travelled down the wrong road to extensions 
(DNSSEC leading to RFC 2065), you have to work within the system to 
make progress.  The security experts involved then were more 
concerned about cryptography and chains of trust than figuring out 
how the DNS worked and shoring up the protocols real vulnerabilities. 
E.g., instead of deriving a DS RR as a manifestation of the 
delegation, they held fast to the notion that keys ought to be kept 
off-line.  (Then along came dynamic update and registries that update 
DNS many times an hour.)

Redefining terms and questioning the basic philosophy will only lead 
to a torpedoing of the entire effort, maybe even the base.

>A single remaining issue

Optimism. ;)
Couldn't resist.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 19 Jan 2005 18:03:41 +0100

>"Edward Lewis" <[email-masked]> wrote:

>to a torpedoing of the entire effort, maybe even the base.

"Redefining terms".  Rather documenting how things actually work.

"Questioning the basic philosophy".
Well, I cannot recall any other Internet-scale system which requires that
app-specific data types are defined by centrally maintained 16-bit integers.

I don't seriously believe that any consensus on this will ever occurr.  I'm
fully satisfied if the various communities creating applications, can agree on
some kind of "interpretation" of what they are doing, because then progress
can hopefully be made.

Anders Rundgren

---

From: Alex Bligh <[email-masked]>
Date: Wed, 19 Jan 2005 18:14:33 +0000

> app-specific data types are defined by centrally maintained 16-bit

Go look at the list of IANA registries. You will find rather
a lot of 16-bit (and indeed 8-bit) registries. Protocol numbers,
and well known ports off the top of my head.

Alex