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

"Anders Rundgren" <anders.rundgren@telia.com> Wed, 19 January 2005 10:48 UTC

From: Anders Rundgren <anders.rundgren@telia.com>
Subject: What is a type? I-D ACTION:draft-iab-dns-choices-00.txt
Date: Wed, 19 Jan 2005 11:48:05 +0100
Lines: 59
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Wed Jan 19 11:55:10 2005
Return-path: <owner-namedroppers@ops.ietf.org>
To: namedroppers@ops.ietf.org
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418071956.2560.82141.ARCHIVE@ietfa.amsl.com>

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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>