Re: [DNSOP] back to: Some distinctions and a request

[Hugo Maxwell Connery <[e-mail]>]

Hi Mr Lewis, and list,

I believe that you are making a category error here.  The key
point is that the softwares that are using the domain name (dot
separated network identifier) labeling system do not wish to
use the DNS architecture for name to address resolution, at all.

However, they may wish to use the excellent transport mechanisms
that IETF have defined over the years, including the latest version(s)
of TLS.  I come back to this below when considering the failure
mode of communication to a URI.

Additionally, they wish to protect the privacy of their users by
having the DNS reject to resolve these names.

We have a mechanism which reliably translates www.example.org
into some on-the-wire byte representation and works.  This does not need
to change, or even be investigated.

Here is what I believe the non-DNS resolution softwares want:

1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu)
within the root zone as "not a domain".  i.e if anyone asks the
answer for anything in or under that pTLD the answer is NXDOMAIN.

2. Iterative resolution software to also be aware of this, such that
they have a permanent in cache response to hand out NXDOMAIN
without bothering the root zone's resolvers (and exposing the query).

3. qname minimisation to be approved and implemented.  In this case,
if 2. is not achieved the exposure of the end user system is dramatically
limited.

All of the above is "worst case usage" from these softwares.  Normal
operation is that the DNS architecture does not even see these name
resolutions happening -- they use whichever mechanism they have
designed and implemented -- the end user is satisfied (assuming their
mechanism works) and the DNS knows nothing.

Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/

When entered into the Tor browser, the DNS sees absolutely no traffic, at all,
irrespective of whether the "domain name" exists.  E.g if asdfasdfasdfasdf.onion
is not defined within the Tor network, still the DNS sees nothing.
However, some configuration of a recently defined TLS transport is used (https).

When opened with a regular browser, the use of the Tor network is
exposed, as described above.  The communication will fail, as
the asdfasdfasdfasdf sub-domain is not registered (and hopefully
not registerable).  We are talking about *how* it fails, and reducing
the leaking of information in that process.

All of these on-list discussions are about point 1. above; Negative registration
in the root zone via RFC6761.

Steps 2 and 3 are, I expect, also on the agendas for these overlay networks,
because they care about the privacy of their community.

If point 2 could be universally achieved, points 1 and 3 are moot.
But, that is never doing to happen, thus the current approach.

Sincerely,  Hugo Connery

NB: I am not a member of the community for any of these networks, and
I certainly dont speak on their behalf.  I do use Tor regularly.
________________________________________
From: Edward Lewis [[e-mail]]
Sent: Thursday, 2 July 2015 14:51
To: Hugo Maxwell Connery; Andrew Sullivan; [e-mail]
Subject: Re: [DNSOP] back to: Some distinctions and a request

On 7/2/15, 6:02, "DNSOP on behalf of Hugo Maxwell Connery"
<[e-mail] on behalf of [e-mail]> wrote:

>Hi,
>
>I think that Andrew's effort to distinguish between a domain name and
>a DNS name is useful.  It gives us some clear terminology to use to
>discuss domain names that wish to use a non-DNS name resolution
>method.

Until this message, I wasn't clear on Andrew's distinction - we have been
talking off-list for the past few days too.

To me a domain name is: a sequence of bits that, when rendered in hex
notation, can look like this:

0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00

That is what is sent over the wire, through ports and is deposited in
memory of name servers.  Note the lack of dots.  And this is why I can't
see a difference between domain names and DNS names.  To me, they are one
in the same.

This dates back to a discussion had while the labs I was in was developing
DNSSEC code.  Our boss (Russ Mundy) made the statement that there are two
versions of a domain name, on-the-wire and in-the-file and it was the
on-the-wire format that mattered.  Later in my career I worked with a firm
that developed it's own DNS code based on some legacy stuff from it's
start-up days.  The start-up operated on the in-the-file format,
converting to and from on-the-wire format constantly.  This was not a good
approach.

So when I hear "domain name" I think of the format that includes an octet
with flags and a number and then that number of octets of data,
terminating with a null octet.  What is seen in files is just a
transliteration of that, "abc.example." is just a conventional way to
represent the domain name above.

Now, if times have changed and a broader audience thinks "abc.example." is
a domain name, there's a need to document that.  In an old RFC there are
rules for representing a domain name in a file, rules that are
inconsistently understood and applied.  Maybe it's not times, it's
perspectives.  I'm coming up through the DNS, I didn't come across the DNS
from application space.

What I mean by rules inconsistently applied is a case of apparently
mis-aligned RFCs on ENUM.  In one RFC, domain names were presented as
conversions to ASCII and the other following the rules of the old RFC for
escaping characters.  Specifically, a back-slash was the issue, in one RFC
it was bare, in the the other escaped, and this difference caused
implementers of ENUM code headaches.

(I should look this up.  I lost the notes on that incident, but probably
can try to dig up the references.)

I'll ask this, are these (thought to be) domain names:

\097\098\099.example.  { 97 is the decimal equivalent of 'a' in RFC 20's
ascii table }

\a\b\c.example.

example.中国. {latter two characters are Chinese, meaning the country of
China}

现在我跟老婆住华盛顿可是以后我飞到IETF.练习 { a sequence of Chinese
charaters, IDNA2008 code
says label too long }

The latter is a placeholder for names that would be "too long" for the DNS
but otherwise look like, in a file, a domain name.  This is said to be
true in Tor's use.

I am not asking to be facetious.  I have had to deal with these questions
over the years.  The latter I have code to test because I'd been asked to
look at official names of geographic regions and whether what would
'appear' to be a domain name from that could possibly be carried across
port 53.

If there is a distinction to be made between domain names and DNS names,
the former needs to be defined first. What are the rules in an http:// or
ftp:// URL?  Colloquially I think the first name is a 'domain name' but I
have never been able to trace that down.  I doubt that the 'domain name'
there is ever processed in on-the-wire format (as I started with) until
the DNS stub resolver accepts the request and spits out something to a
recursive server at port 53 somewhere.

(This omits the other under-worldly distinction of what names are eligible
for registration, etc., which is a distinction I've had to deal with.  In
a world where one can write in any script with any kind of pen or pencil,
you have to know where do, um, draw, the line.  IDNA2008?  Punycode?
Different rules for different systems?  And, is the "domain" of the
problem all code, all protocols, or what's in common use on the global
public Interent?)