Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

Philip Homburg <> Sun, 29 November 2015 13:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 81E781ACDED for <>; Sun, 29 Nov 2015 05:10:19 -0800 (PST)
X-Quarantine-ID: <KBnVBySkF6TF>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KBnVBySkF6TF for <>; Sun, 29 Nov 2015 05:10:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D2CE71ACDEC for <>; Sun, 29 Nov 2015 05:10:17 -0800 (PST)
Received: from (localhost [::ffff:]) by with esmtp (Smail #91) id m1a31k6-0000HVC; Sun, 29 Nov 2015 14:10:14 +0100
Message-Id: <>
From: Philip Homburg <>
References: <> <> <>
In-reply-to: Your message of "Sun, 29 Nov 2015 12:38:18 +0000 ." <>
Date: Sun, 29 Nov 2015 14:10:12 +0100
Archived-At: <>
Cc: Mark Nottingham <>, George Michaelson <>, Jacob Appelbaum <>
Subject: Re: [DNSOP] Some thoughts on special-use names, from an application standpoint
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 29 Nov 2015 13:10:19 -0000

>> The purpose of the domain name system is to name things. We have IP
>> addresses and we want to refer to them using names. We do the same thing
>> with mail domains, etc.
>That is not the sole purpose - we use DNS for keys, for time stamps,
>for data of all kinds.

In a well designed system, names are only used to name things.

>From the good old days, telnet and ftp are clear examples.
After looking up the name in DNS, you don't need the name anymore.
All you need are the addresses that were returned in the DNS lookup.

SSH with SSHFP also has that property. Lookup the SSH fingerprint in
the SSHFP record, lookup an address, connect, and verify the fingerprint.
No need for the name after the lookup.

(Storing other stuff in a naming system is not a problem, it is just a
big distributed database).

>From day one however, this principle was violated. SMTP does use the
domain name after the name lookup.

With the interduction of the http host header, http also violates this
principle. With the introduciton of SNI, TLS violates it.

However, SMTP, HTTP, and TLS have one in common, from the
network point of view, the name is not used for routing.

It is only later, at the application layer that the name is used again.

It is here that .onion goes one step further. Onion 'names' are derived from
public keys. So instead a name being independent of an address, the .onion
name is the address.

Unlike, TLS or SSH, where a network connection is set up and then the
crypto runs on top of it, in TOR this all integrated. For good reason,
however that make the .onion 'name' an address.

>> In goes a name, out comes some lower level entity.
>> In this context an onion address should have been an 'IN ONION', i.e,
>> might have an 'IN ONION' address for use with TOR.
>And that would also require special handling...

Yes, but in a way that doesn't abuse the model.

If an 'IN ONION' would be stored on the host as a 'struct sockaddr_onion'
then all code can be cleanly adapted to support TOR hidden services.
Instead of adding pattern matching hacks to name resolution.