Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-22 Thread Joe Abley 

Hi Stephane,

On 21 Sep 2015, at 11:20, Stephane Bortzmeyer wrote:


On Fri, Sep 18, 2015 at 12:19:26PM -0400,
Joe Abley  wrote
a message of 111 lines which said:


Whether or not we should call an onion or mdns name a "domain name"
or something else is just a detail. I don't think agreeing on the
answer is going to solve any of the problems that we actually have.


I disagree. RFCs are written with words and discussions at the IETF or
elsewhere use words. Agreeing on the "right" words is important. Words
are not innocent. (Refusing to call .onion names "domain names" was
also a way to refuse the registration of .onion.)


I suspect I didn't explain myself very well.

I am all in favour of an accurate and unambiguous lexicon, and I think 
there's a lot to like about Ed's draft.


However, the problem we are struggling with (which Ed spoke more about 
in a follow-up e-mail) is the conflict between different name resolution 
protocols that have namespaces similar enough for applications to treat 
the same.


I think we need to address the architctural issue that the last label in 
what applications (and Ed) call a domain name is in some cases a 
protocol selector token, and in other cases is not.


(We might wish that there was a better answer than this, perhaps has 
part of the URI spec or something else, but let's face it, that 
particular quadraped has long since departed his straw-strewn abode).



Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-22 Thread Edward Lewis 
On 9/21/15, 16:36, "DNSOP on behalf of hellekin"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>On 09/21/2015 11:50 AM, Edward Lewis wrote:
>> 
>> I think defining -whether- name.onion is a Domain Name will make us
>> re-think how Domain Names interoperate amongst protocols beyond the DN
>S.
>>
>
>Agreed, but why limit to .onion?  Can your example stretch to include
>.bit, .i2p, .gnu, .zkey, and why not .exit?

You tell me.  The draft is not necessarily comprehensive.  Examples are
not exhaustive lists.

The point of the draft is to move from a situation where we have a
hodgepodge of cases to one where we have a formal ontology.  From there,
the hope is that patterns will emerge that will increase determinism.

>In a recent private conversation it was suggested that as long as a
>domain cannot sell subdomains it could be interesting to consider
>(without affecting ICANN domain-name business).

This is a non-sequiter.  "Selling" is not one of the criteria.  OTOH,
whether names are centrally assigned (as in DNS) or uniquely spawned
(distributed hash tables) is a technical aspect, but even that doesn't
really matter - what matters is the method of converting the name into, as
appropriate, a location or other data value (key/cert for example).
(IMHO, just about any mention of ICANN is a red herring.)  The draft is
trying to forge a definition of Domain Names, with a better understanding
of how they function and interoperate amongst protocols.

>Earlier we've been discussing P2PNames and came to the conclusion that
>the term TLD should not be employed outside the DNS context, so I
>welcome your draft to clarify this aspect.

As mentioned in the draft, top-level names is defined very early on in the
evolution of the concept.  TLD has emerged, more so in the last 15 years,
to be a specific kind of entity within the management of DNS operations.

It is my suspicion/belief that the top-level name will retain special
status as we go on because - and this is belief talking and not anything
more mature - there needs to be some way to signal how the name "below"
(in the rooted tree sense) is resolved.  I.e., if I see "onion" I go to
Tor, "local" mDNS, a numeric value is treated as a literal or error, a
known DNS TLD to the DNS, and so on.  I'm not sure this observation will
be something that grows into the draft or not but is a central reason why
I think we have to start with a basic definition.

That list of examples can conceivably grow at the cost of complexifying[0]
software.

[0] yes, I know, not a word.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread hellekin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/21/2015 11:50 AM, Edward Lewis wrote:
> 
> I think defining -whether- name.onion is a Domain Name will make us
> re-think how Domain Names interoperate amongst protocols beyond the DN
S.
>

Agreed, but why limit to .onion?  Can your example stretch to include
.bit, .i2p, .gnu, .zkey, and why not .exit?

In a recent private conversation it was suggested that as long as a
domain cannot sell subdomains it could be interesting to consider
(without affecting ICANN domain-name business).

Earlier we've been discussing P2PNames and came to the conclusion that
the term TLD should not be employed outside the DNS context, so I
welcome your draft to clarify this aspect.

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJWAGo9XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9iGIQAJClr7YvbUsiO5JmcJaThpJO
pjyA3AzY/+iuasj8zO/gXPHd+4wkROkvIRaT3y7A0+d02H5nE3BkeMbqeQNMsYXN
XE95DBqpqH9IEUkdAGtKCHQ4z8wrwVT4Lv1fPjhUiX7LnsdH7Y65Ujchasxt/Cd0
DY4SmN4q6BErsBXSLwsLoIpK3IhvDBkIAD6EqMA+6UvoNWx4rPt0ZfmD7j4KyWSV
gIsLweoaQRJCZvdjroxt/CVOfEuybdrOlfmFsnpWiwZ7lVmldJ7yL9Yl1Ps3IbTd
9ikU3brsGrT2ZzpyQRhL39vSCB81bU/e2l1t66igoOKNZBh2JViEboGXcs6DQ3oj
kNc6BAEAKL5onCHFHMQdEs66OytQ+mJrStoqHHJACbLL104emeFGpl1H4G92cRG4
mXdI03ctJTCbzOFYgPcYwnsOUFzUiB8wpnSmc6KDOyI1azQIh31IGo19sx78UG9z
HSzUtJt65WJ3L+Hp7853Ma6id3KUVkNyrvCgXKKz6nztuNy0CnSjVOlXXMB/ecvF
EOWVh9216gNdUZRg0MRGpb4FYkH6M6V8sL0ADEi+EXebKqWzVUUO7+/DDeLaqBLI
UNUbtw17LZcZ4/d0eLGM1EJYAgnrUl1aPyiWqRCjcT28AggBdWfqd+tjArFbVRa2
OnPBACcyGruzljwAWHTW
=tJJg
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread Robert Edmonds 
Stephane Bortzmeyer wrote:
> If you want a nice example of a domain name which is not a DNS name,
> add in your /etc/hosts (or equivalent for your OS):
> 
> 104.20.1.85 
> veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
> 
> It is not a DNS name (first label is too long) but it works fine for
> several applications which expect domain names:

Those applications probably use the getaddrinfo() function for name
lookup, and specifications for that function [0,1,2] don't specify a
length limit for the 'nodename' parameter.

[0] http://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html

[1] http://tools.ietf.org/html/rfc3493#section-6

[2] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread Stephane Bortzmeyer 
On Thu, Sep 17, 2015 at 07:58:54PM +,
 Edward Lewis  wrote 
 a message of 145 lines which said:

> >Abstract:
> >This document states a definition of Domain Name beyond the use of
> >the term within the Domain Name System.

Very good document, IMHO, and useful. I appreciate that we have a
document explaining clearly the difference between a domain name and a
DNS name. I loved the history bit, with SMTP defining the domain name
:-)

Two remarks:

>  the ordering of the sequence, such as left-to-right or
> right-to-left,

You make a confusion between the ordering of the sequence and its
representation. You may mention the ordering (the most specific label
at the beginning, the root at the end) as long as you don't refer to
the representation (in english, the most specific label is on the
left, in arabic on the right).

So, I suggest, when describing domain names, to use only "first" and
"last" for the labels and never "left" or "right", which are
script-specific.

> What is excluded in this definition is [...] the designated
> separator character's representation,

Then, /etc/cups/ppd/Konicac.ppd is a domain name? I tend to regard the
dot as a sure sign that the character string is intended to be a
domain name.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread Stephane Bortzmeyer 
On Fri, Sep 18, 2015 at 12:19:26PM -0400,
 Joe Abley  wrote 
 a message of 111 lines which said:

> Whether or not we should call an onion or mdns name a "domain name"
> or something else is just a detail. I don't think agreeing on the
> answer is going to solve any of the problems that we actually have.

I disagree. RFCs are written with words and discussions at the IETF or
elsewhere use words. Agreeing on the "right" words is important. Words
are not innocent. (Refusing to call .onion names "domain names" was
also a way to refuse the registration of .onion.)

To quote Camus , "Naming
things badly adds to the misfortune of the world"

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread Tony Finch 
Edward Lewis  wrote:
>
> It seems to me that a new layer of software is emerging between the UI and
> the stub resolver, one that will need to know where to send a name
> resolution query.

What do you mean "is emerging"? The name service switch was introduced
over 20 years ago!

There are lots of alternate name resolution systems supported by NSS:
hosts files, NIS, WINS, mDNS, etc.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread Stephane Bortzmeyer 
On Thu, Sep 17, 2015 at 07:58:54PM +,
 Edward Lewis  wrote 
 a message of 145 lines which said:

> >Name:draft-lewis-domain-names
> >Revision:00

If you want a nice example of a domain name which is not a DNS name,
add in your /etc/hosts (or equivalent for your OS):

104.20.1.85 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com

It is not a DNS name (first label is too long) but it works fine for
several applications which expect domain names:

% ping -c 3 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
PING 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
 (104.20.1.85) 56(84) bytes of data.
64 bytes from 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
 (104.20.1.85): icmp_seq=1 ttl=58 time=2.10 ms
64 bytes from 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
 (104.20.1.85): icmp_seq=2 ttl=58 time=1.88 ms
64 bytes from 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
 (104.20.1.85): icmp_seq=3 ttl=58 time=2.27 ms

--- 
veryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongname.example.com
 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.887/2.089/2.273/0.166 ms

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread George Michaelson 
Your example has some problems for me.  Problems which I guess your
question was designed to draw out.

Firstly, *some* tor active clients operate by using bump-in-the-stack
methods based or analogous to SOCKS. So, there is an API which intervenes
on the normal operations and tunnels, and then its basically transparent.
Where this happens, and how this happens begs questions about the DNS
gethostby*() and getDNS*() api. -SOCKS does one set of things. the
TOR-SOCKS model (I hypothesize, but I do believe this exists) may do
something else.

Secondly, applications which don't use generic bumps in (application)
stacks, need to be re-coded to DTRT. So the .local example you gave, the
different OS's do a different job of implementing a set-aside into mDNS:
Its not uniformly available. "it depends" -And by analogy, one can expect
that .onion set-aside logic will not be uniform: if I took an apparent FQDN
x.onion on an SSH command line, and punched it into Opera, or Firefox,
or Chrome, or Safari, or curl, or ftp, I *might* get different behaviours.

I think the meta-question is a good question, but I don't think it only
faces one way (into DNS, and how we think about DNS) -It faces into the
problem space:

 "what is the set of mechanisms we have to hand, to try and do
name-to-locator mapping"

and some of them are domain names, and some aren't, and some have been
coerced into the domain name space so that other processes (X.509
certificate behaviour) can work, because of the SubjectName and
SubjectAlternateName being coerced into the dot-separated domain name form)

On Mon, Sep 21, 2015 at 11:50 AM, Edward Lewis 
wrote:

> On 9/18/15, 12:51, "DNSOP on behalf of Jim Reid"  on behalf of j...@rfc1035.com> wrote:
>
> >
> >On 18 Sep 2015, at 17:19, Joe Abley  wrote:
> >
> >> Whether or not we should call an onion or mdns name a "domain name" or
> >>something else is just a detail. I don't think agreeing on the answer is
> >>going to solve any of the problems that we actually have
> >
> >+1
>
> I'm a little surprised at this response and the plus one.
>
> Here's the problem I see.
>
> Lets say I want to write a very basic SSH client (just to make the story
> simple).  Someone can then type "eds-ssh computer-name" and open up a
> secured connection.
>
> If computer-name ends in .local, I open TCP to an IP address from the
> lookup in mDNS.
>
> If computer-name ends in .onion, I open TCP to an IP address I get via Tor
> (assuming that .onion supports remote shell).
>
> If computer-name ends in a digit, I suppose it's an address literal and
> open TCP accordingly.
>
> If computer-name ends in whatever is in the DNS root zone, I find the
> address in DNS.
>
> If computer-name ends in something not in the DNS root zone, I return an
> error.
>
> The gotchas include, what if the latter two are indistinguishable because
> the DNS resolver sent back a landing page - or the latter three if the
> redirection service didn't recognize .onion as special.
>
> What if, in a year from now, .carrot becomes yet another way to resolve
> names?
>
> What if, in the future, .alt is defined as having special meaning?  (Note
> - the fact that .alt is in an actual ID and .carrot is purely fictional
> means .carrot is closer to being an RFC. ;))
>
> It seems to me that a new layer of software is emerging between the UI and
> the stub resolver, one that will need to know where to send a name
> resolution query.  (Perhaps even amongst DNS stub resolvers on different
> interfaces.)  This emerging layer needs to know how to direct it's work
> flow.  The Special Use Domain Names Registry would be the place to start
> (but as it's written now, the emerging layer can't be future proofed).
>
> These are just TLD examples, perhaps a simplification.
>
> I see a fork in the codepath ahead regarding "whether the DNS is above
> Domain Names" (like .alt) or whether "Domain Names are broader than what
> was conveniently defined for a DNS".  It's important to know which of
> those two statements are true so we can get on with Special Use Domain
> Names, and perhaps to find ways to objectively assign new names for new
> uses.
>
> I think defining -whether- name.onion is a Domain Name will make us
> re-think how Domain Names interoperate amongst protocols beyond the DNS.
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-21 Thread Edward Lewis 
On 9/18/15, 12:51, "DNSOP on behalf of Jim Reid"  wrote:

>
>On 18 Sep 2015, at 17:19, Joe Abley  wrote:
>
>> Whether or not we should call an onion or mdns name a "domain name" or
>>something else is just a detail. I don't think agreeing on the answer is
>>going to solve any of the problems that we actually have
>
>+1

I'm a little surprised at this response and the plus one.

Here's the problem I see.

Lets say I want to write a very basic SSH client (just to make the story
simple).  Someone can then type "eds-ssh computer-name" and open up a
secured connection.

If computer-name ends in .local, I open TCP to an IP address from the
lookup in mDNS.

If computer-name ends in .onion, I open TCP to an IP address I get via Tor
(assuming that .onion supports remote shell).

If computer-name ends in a digit, I suppose it's an address literal and
open TCP accordingly.

If computer-name ends in whatever is in the DNS root zone, I find the
address in DNS.

If computer-name ends in something not in the DNS root zone, I return an
error.

The gotchas include, what if the latter two are indistinguishable because
the DNS resolver sent back a landing page - or the latter three if the
redirection service didn't recognize .onion as special.

What if, in a year from now, .carrot becomes yet another way to resolve
names?

What if, in the future, .alt is defined as having special meaning?  (Note
- the fact that .alt is in an actual ID and .carrot is purely fictional
means .carrot is closer to being an RFC. ;))

It seems to me that a new layer of software is emerging between the UI and
the stub resolver, one that will need to know where to send a name
resolution query.  (Perhaps even amongst DNS stub resolvers on different
interfaces.)  This emerging layer needs to know how to direct it's work
flow.  The Special Use Domain Names Registry would be the place to start
(but as it's written now, the emerging layer can't be future proofed).

These are just TLD examples, perhaps a simplification.

I see a fork in the codepath ahead regarding "whether the DNS is above
Domain Names" (like .alt) or whether "Domain Names are broader than what
was conveniently defined for a DNS".  It's important to know which of
those two statements are true so we can get on with Special Use Domain
Names, and perhaps to find ways to objectively assign new names for new
uses.

I think defining -whether- name.onion is a Domain Name will make us
re-think how Domain Names interoperate amongst protocols beyond the DNS.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Joe Abley 
Hi George!

On 18 Sep 2015, at 12:58, George Michaelson wrote:

> Ed wrote a draft whose purpose claimed to be definitional around what
> domain names are. In that context I replied. If you don't really care how
> we use words, thats fine too.

I don't think that's a reasonable summary of what I care about, for the record 
:-)

I understand the context. I was really talking to a wider context, which is the 
difficulty with words we're used to seeing in the DNS when they are used in 
other name resolution protocols -- I was trying to suggest that the wider 
context has more to do with the use of multiple naming systems than it does 
with the overloading of individual terms.

> I agree it won't alter anything and I want to stop here, since I suspect
> I'm already well on the way to hitting peoples kill file.

I don't have a kill file, George, but if I did the world would be a gloomier 
and more tedious place with you in it.


Joe


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread George Michaelson 
Ed wrote a draft whose purpose claimed to be definitional around what
domain names are. In that context I replied. If you don't really care how
we use words, thats fine too.

I agree it won't alter anything and I want to stop here, since I suspect
I'm already well on the way to hitting peoples kill file.

G

On Fri, Sep 18, 2015 at 1:51 PM, Jim Reid  wrote:

>
> On 18 Sep 2015, at 17:19, Joe Abley  wrote:
>
> > Whether or not we should call an onion or mdns name a "domain name" or
> something else is just a detail. I don't think agreeing on the answer is
> going to solve any of the problems that we actually have
>
> +1
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Jim Reid 

On 18 Sep 2015, at 17:19, Joe Abley  wrote:

> Whether or not we should call an onion or mdns name a "domain name" or 
> something else is just a detail. I don't think agreeing on the answer is 
> going to solve any of the problems that we actually have

+1

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Joe Abley 


On 18 Sep 2015, at 9:54, Alec Muffett wrote:

>> On Sep 18, 2015, at 14:16, George Michaelson  wrote:
>>
>> My private comment bears repeating in public.
>>
>> DOMAIN names is about the property of domains. Domains are encompassing, 
>> set-theory/venn-diagram style. A domain and a prefix are analogous concepts. 
>> One is expressed syntactically somehow, the other is a mathematical property 
>> of bounding in a number field but they have the same basic behaviour.
>>
>> the UK domain order in coloured book mails obeyed this property: it just 
>> used reverse semantics to the ARPA model.
>>
>> .onion is *not* a domain name inside the .onion part: as I 
>> understand it, the value is a hash, or other function which has no nesting 
>> properties expressed syntactically.
>
> Hi, my name's Alec, I work for Facebook and lead the engineering team for 
> Facebook over Tor.

This reminds me of the time I set down with a collection of people who would 
later turn into NZNOG, at a Uniforum meeting in Taupo. Since we were sitting in 
a circle, it seemed only natural to start things off with "My name is Joe, and 
I work for an ISP". Everybody else without missing a beat replied with the 
twelve-step "Hi Joe". We had a moment.

Hi Alec!

> You are certainly correct that the label immediately left of ".onion" is a 
> hash, and functions not unlike a layer-3 address; however, there may be other 
> labels leftwards of the hash, under (to some extent) other administrative 
> control.

I think that we are all guilty from time to time of trying to form elegant, 
general descriptions of things that are not actually elegant, or useful to 
generalise.

The DNS is frequently described has having three core concepts: (a) the servers 
and the wire-format protocols that they talk, (b) the data model (resource 
records, etc) and (c) the namespace. (a) provides the infrastructure for (b) to 
be retrieved using a key from (c).

There are other name resolution protocols that are not the DNS, but which use 
similar namespaces to (c) and perhaps similar (b) but different (a). Pertinent 
examples are multicast DNS and Onion/tor, and (arguably) the localhost 
"protocol" that simply maps the name localhost to the addresses 127.0.0.1 and 
::1.

The ugliness all rotates around the pragmatic decision to use the right-most 
label in a name as a resolution protocol selector. We can complain about that 
all we like, but reality is that we're going to have a hard time pushing those 
cats back into the bag. At the very least there will be injuries and bleeding, 
and you know the cats aren't going to like it.

It would be lovely if nobody had ever used the right-most label like this, and 
instead there was a standard and accepted way to specify a resolution protocol 
in a URI, and everywhere else that a name is used. But there isn't. Also, 
running code, etc.

Whether or not we should call an onion or mdns name a "domain name" or 
something else is just a detail. I don't think agreeing on the answer is going 
to solve any of the problems that we actually have.


Joe

signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread George Michaelson 
If they nest, then yes. if the x. under onion is hash denoted only for
other reasons, but otherwise is a truly encompassing domain, then yes. If
it has a SOA. and NS, and there is a clear zonecut, its not just a domain,
its a DNS domain. But we know that isn't how its going to work: this is a
domain name system outside of the DNS. the concept of a zone cut, of a
Serial, a TTL, NS of the zone, none of those properties of the system are
inherent givens. I beleive they might even be not-givens: they don't exist,
because the functional mapping behaviour lies in another model.

But if there is magic which means m.facebookcorewww. under 76543.onion is
deterministically known to be the same as m.facebookcorewww. under
123456.onion, without query into the zone to get state, then I am less sure
this should be considered a domain. Its not obeying strict nesting rules.
There is no implication of scoping.

-G

On Fri, Sep 18, 2015 at 11:51 AM, Bob Harold  wrote:

>
> On Fri, Sep 18, 2015 at 9:54 AM, Alec Muffett  wrote:
>
>>
>> On Sep 18, 2015, at 14:16, George Michaelson  wrote:
>>
>> ...
>>
>> .onion is *not* a domain name inside the .onion part: as I
>> understand it, the value is a hash, or other function which has no nesting
>> properties expressed syntactically.
>>
>>
>> Hi, my name's Alec, I work for Facebook and lead the engineering team for
>> Facebook over Tor.
>>
>> You are certainly correct that the label immediately left of ".onion" is
>> a hash, and functions not unlike a layer-3 address; however, there may be
>> other labels leftwards of the hash, under (to some extent) other
>> administrative control.
>>
>> The canonical example of this would be: www.facebookcorewwwi.onion versus
>> m.facebookcorei.onion
>>
> ...
>
>> - alec
>>
>>
> I would argue that "facebookcorewww" is a domain within the "onion"
> domain, and that the "www" and "m" here are within the "facebookcorewww"
> domain.
>
> I also think that the fact that the 'name' of the domain happens to be a
> hash is significant, it is merely the 'name' of the domain, and how the
> name is chosen is not what defines a domain.
>
> We might even say that the actual domain could be considered to be the
> private information that the hash is created from, or the service, or
> address (however Tor finds the resource).
>
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Bob Harold 
On Fri, Sep 18, 2015 at 9:54 AM, Alec Muffett  wrote:

>
> On Sep 18, 2015, at 14:16, George Michaelson  wrote:
>
> ...
>
> .onion is *not* a domain name inside the .onion part: as I
> understand it, the value is a hash, or other function which has no nesting
> properties expressed syntactically.
>
>
> Hi, my name's Alec, I work for Facebook and lead the engineering team for
> Facebook over Tor.
>
> You are certainly correct that the label immediately left of ".onion" is a
> hash, and functions not unlike a layer-3 address; however, there may be
> other labels leftwards of the hash, under (to some extent) other
> administrative control.
>
> The canonical example of this would be: www.facebookcorewwwi.onion versus
> m.facebookcorei.onion
>
...

> - alec
>
>
I would argue that "facebookcorewww" is a domain within the "onion" domain,
and that the "www" and "m" here are within the "facebookcorewww" domain.

I also think that the fact that the 'name' of the domain happens to be a
hash is significant, it is merely the 'name' of the domain, and how the
name is chosen is not what defines a domain.

We might even say that the actual domain could be considered to be the
private information that the hash is created from, or the service, or
address (however Tor finds the resource).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Alec Muffett 
>> So it's IMO fine to say ".onion addresses are case-insensitive and
>> will comply with existing DNS limitations for label lengths (63) and
>> maximum fqdn lengths (253ish)".
>> Which contradicts draft-lewis-domain-names-00
> 
> 
> So - and not to be pointed - but in your email I reference, should I ignore 
> that for the sake of this document?  I mean what the message says seems to 
> contradict what you are quoting from Mathewson - which is fine - but this is 
> something unclear to me.


Yes, you should ignore that text.

Nick is the engineer at Tor who implements the relevant code.

In the following, he provides the following undertaking:

https://lists.torproject.org/pipermail/tor-dev/2015-August/009275.html 


> The examples in Proposal 224 are a mere 53 characters long leaving 10 to
> play with for padding-hyphens and possibly checksum characters.
>
> Nick: Is this likely to need to change? Or might there be a need to encode >
> 315 bits / 63 chars total?

I don't anticipate this changing.

If there were ever a need to encode more than that number of bits,
we'd add an extra label.

So, .onion addresses will stay within DNS bounds.  :-)

- alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread George Michaelson 
I think its possible I'm arguing off to the side Ed. But, there was a
scoping quality in domain, as applied to domain names, which is pretty
"big" in my opinion. Its analogous to the ordering issues in fully
qualified (relative) distinguished names in X.500. The order of elements of
Surname= Given= Generational-Qualifier= were perhaps moot, but the nesting
qualities of C= and O= and OU= were not. It was pretty clear (mistakenly?)
to me that you might be able to re-order the S/G/GQ elements in a wildcard
match inside some O=/OU= local context, but searching for all CN=*Smith* at
the C= level was going to be a hard ask.

So this quality of the word 'domain' is not in my mind, just hand waving.
Its innate. The decision to make the dot separator function as both a label
boundary, and potentially a zone-cut, has consequences. a putative FQDN is
like a Relative Distinguished name, except you can't know where the
zone-cut is a-priori, until you get some information back.

AppleTalk names were interesting, structured. They got some ideas from VMS
(or seemed to) which I suspect also were ideas out of Tops-10 and other
places about how you name things according to symbolic types and syntaxes.
DNS names were almost syntax free, with just three rules of significance
here

1) they order L to R. They nest.
2) the dot is a boundary, but not all dots are zone-cuts
3) there were limits on length

Does anyone else find themselves reaching into long term storage over
things like symbolic links with computed values? SunOS and the architecture
${cpu} in the symlink so it was computed on-the-fly to find your
/usr/local/${arch}/bin path in NFS?

DNS didn't do that. there is no my.dom.$intermediate.ain capability in the
name model.

And that kind of quality, rule 1) -they nest, is what the "D" in DNS means.

To me, its not incidental. Its core. If they don't obey the nesting
functions of Domains, they aren't domain-names.

On Fri, Sep 18, 2015 at 11:04 AM, Edward Lewis 
wrote:

> On 9/18/15, 9:54, "Alec Muffett"  wrote:
>
>
> I feel this may need clarification in your section on Tor addressing.
> Perhaps it's not **really** domain-naming, but it **looks** much more like
> it.
>
>
> The first point of the document is to allow us to answer that "perhaps" -
> without a definition of Domain Names, we don't know.  The question includes
> - are "Domain Names" just things that look like something  or are they
> things that have a lot of baggage (such as means of assignment [which is
> different between DNS and distributed hash tables]).
>
> I'm not disagreeing, just underlining that until the definition is in
> place, it's hard for me to be in complete agreement.
>
>
> Also, there is some information which requires correction:
>
> According to an email message, ".onion" names may (in the future)
>
> exceed the length limits of a label imposed on DNS domain names,
> reaching 64, 80, or more bytes. [DNSOP1]
>
>
> Per this e-mail:
>
> https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html
>
> ...from Nick Mathewson at Tor, he says:
>
> So it's IMO fine to say ".onion addresses are case-insensitive and
> will comply with existing DNS limitations for label lengths (63) and
> maximum fqdn lengths (253ish)".
>
> Which contradicts draft-lewis-domain-names-00
>
>
> So - and not to be pointed - but in your email I reference, should I
> ignore that for the sake of this document?  I mean what the message says
> seems to contradict what you are quoting from Mathewson - which is fine -
> but this is something unclear to me.
>
> (I wasn't aware of Mathweson's message, I'm not subscribed to that list.)
>
>
> Also, my name's not "Alex" :-)
>
> - alec
>
>
> I got 75% of the name right. ;)  Sorry about that - I don't read all the
> letters on a page.
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Edward Lewis 
On 9/18/15, 9:54, "Alec Muffett"  wrote:
> 
> I feel this may need clarification in your section on Tor addressing.  Perhaps
> it's not **really** domain-naming, but it **looks** much more like it.

The first point of the document is to allow us to answer that "perhaps" -
without a definition of Domain Names, we don't know.  The question includes
- are "Domain Names" just things that look like something  or are they
things that have a lot of baggage (such as means of assignment [which is
different between DNS and distributed hash tables]).

I'm not disagreeing, just underlining that until the definition is in place,
it's hard for me to be in complete agreement.
> 
> Also, there is some information which requires correction:
> 
> According to an email message, ".onion" names may (in the future)
> exceed the length limits of a label imposed on DNS domain names,
> reaching 64, 80, or more bytes. [DNSOP1]
> 
> Per this e-mail:
> 
> https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html
> 
> ...from Nick Mathewson at Tor, he says:
> So it's IMO fine to say ".onion addresses are case-insensitive and
> will comply with existing DNS limitations for label lengths (63) and
> maximum fqdn lengths (253ish)".
> Which contradicts draft-lewis-domain-names-00

So - and not to be pointed - but in your email I reference, should I ignore
that for the sake of this document?  I mean what the message says seems to
contradict what you are quoting from Mathewson - which is fine - but this is
something unclear to me.

(I wasn't aware of Mathweson's message, I'm not subscribed to that list.)

> 
> Also, my name's not "Alex" :-)
> 
> - alec

I got 75% of the name right. ;)  Sorry about that - I don't read all the
letters on a page.





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Alec Muffett 

> On Sep 18, 2015, at 14:16, George Michaelson  wrote:
> 
> My private comment bears repeating in public.
> 
> DOMAIN names is about the property of domains. Domains are encompassing, 
> set-theory/venn-diagram style. A domain and a prefix are analogous concepts. 
> One is expressed syntactically somehow, the other is a mathematical property 
> of bounding in a number field but they have the same basic behaviour.
> 
> the UK domain order in coloured book mails obeyed this property: it just used 
> reverse semantics to the ARPA model.
> 
> .onion is *not* a domain name inside the .onion part: as I understand 
> it, the value is a hash, or other function which has no nesting properties 
> expressed syntactically.

Hi, my name's Alec, I work for Facebook and lead the engineering team for 
Facebook over Tor.

You are certainly correct that the label immediately left of ".onion" is a 
hash, and functions not unlike a layer-3 address; however, there may be other 
labels leftwards of the hash, under (to some extent) other administrative 
control.

The canonical example of this would be: www.facebookcorewwwi.onion 
 versus m.facebookcorei.onion versus… 
well, anything.you.like.sixteencharshash.onion.

With onion addressing it's all a matter of whether the layer 7 protocol honours 
the symbolic name that it has been given (eg: www.facebookcorewwwi.onion 
) and passes it to the server via metadata 
(eg: HTTP "Host:" header) rather than a delegated and differentiated address 
lookup.

I feel this may need clarification in your section on Tor addressing.  Perhaps 
it's not **really** domain-naming, but it **looks** much more like it.

Also, there is some information which requires correction:

According to an email message, ".onion" names may (in the future)
exceed the length limits of a label imposed on DNS domain names,
reaching 64, 80, or more bytes. [DNSOP1]

Per this e-mail:

https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html 


...from Nick Mathewson at Tor, he says:
So it's IMO fine to say ".onion addresses are case-insensitive and
will comply with existing DNS limitations for label lengths (63) and
maximum fqdn lengths (253ish)".
Which contradicts draft-lewis-domain-names-00

Also, my name's not "Alex" :-)

- alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Edward Lewis 
On 9/17/15, 17:03, "DNSOP on behalf of Darcy Kevin (FCA)"
 wrote:

>Ed,
>   I find the document useful, and illuminating, but that it suffers from
>one glaring omission -- no substantive discussion of the relationship
>between domain names and URIs (the related term "URN"[1] is mentioned in
>Section 1.2, but never expanded upon). To be sure, while the "Authority"
>component of a URI is not *always* based on a DNS name (or a "domain
>name", as distinguished in your Draft), it _usually_ is, and RFC 3986,
>aka STD 66, makes the relationship quite explicit:

Thanks.  I'm stuck in the 90's, what's that web thing?

Seriously, the pointers will help.

>"However, a globally scoped naming
>system, such as DNS fully qualified domain names, is necessary for
>URIs intended to have global scope. URI producers should use names
>that conform to the DNS syntax, even when use of DNS is not
>immediately apparent ..."
>
>So, names in URI "Authority"s should *look* like DNS-style FQDNs, even if
>some other "Authority" resolution-and/or-uniqueness-guaranteeing
>mechanism underpins the particular Scheme.

The issue that gets me here is the so-called .onion names and the
statement (which I've only seen in email) that the labels may exceed DNS
limits someday.  And this is probably why I waffled when digging into the
URI and Domain Names issue.

What I need to reconcile is - "yes" to what you quote and "but" he
descriptions of the Tor Project documents on how Onion routing avoids the
DNS while ... based on some "explicitly implicit" in-band signal.

>Since URIs are so commonplace in modern communication mechanisms
>(including one little app called web browsing :-), I think the tie-in
>between URIs and domain names should at least be mentioned in a
>comprehensive "domain names" document.
>
>   
> - Kevin
>
>[1] As per STD 66: "Future specifications and related documentation
>should use the general term 'URI' rather than the more restrictive terms
>'URL' and 'URN'".

Noted.  I've been confused on that myself, URN vs. URL.  At one time I was
scolded for using URL where URN was deemed more appropriate, but I suspect
that was a long time ago.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread Edward Lewis 
On 9/18/15, 9:16, "George Michaelson"  wrote:

>My private comment bears repeating in public.

That's good...

>DOMAIN names is about the property of domains. Domains are encompassing,
>set-theory/venn-diagram style. A domain and a prefix are analogous
>concepts. One is expressed syntactically somehow, the other is a
>mathematical property of bounding in a number field
> but they have the same basic behaviour.
>
>the UK domain order in coloured book mails obeyed this property: it just
>used reverse semantics to the ARPA model.
>
>.onion is *not* a domain name inside the .onion part: as I
>understand it, the value is a hash, or other function which has no
>nesting properties expressed syntactically.
>
>This quality of domain names, the concepts of domains, is a distinct
>property which bears thinking about.
>
>HOST.TXT was not a domain system, it was a linear map. Honey Danber had
>some qualities of domain-ness. Usenet groups after the great mod.*
>reordering became more domain like.

So, it's true that the word "domain" has other meanings, it wasn't coined
for the use evident in RFCs (and other documents).

I went through a similar discussion early in the preparation of RFC 4594
"The Role of Wildcards in the Domain Name System".  Initially it was
"Clarifications on Wildcards" which ran into the question of "if you have
to redefine them, it's not a clarification."  Next the objection was that
I'd initially written that Wildcards was the way to do record synthesis in
the DNS.  The objection was well founded, Wildcards are *a* way to do
record synthesis, and the only possible means unless we ditch or seriously
alter AXFR.  (That discussion began my interest in that topic.)

There have been other things called domains before, and domain names.
It's clear from reading the old (pre-1000) RFCs that there was "science"
going on that was unrecorded in the RFC series.  This document is by no
means able to capture that - yet, until I get some reference material.

So - look at this document as trying to define "Domain Names" as they
appear in IETF, RFC-documented protocols.  With the document about the
interoperability of the IETF's use of "Domain Names."  Perhaps the title
should be "IETF(tm) Domain Names". ;)

In summary, your point is taken that there's a wider scope to the topic.
There has to be, I don't think anyone had a nightmare one night and the
DNS was born.  The goal here is to establish a basis for how we extend the
way Domain Names appear in Internet technologies - not just IETF, but
hopefully one in the same even if there's a lag.  From experience I won't
set as a goal a way to unify how all protocols use Domain Names - that has
long since passed, the protocols are working fine, there's no need to
restructure code for the sake of documentation.  But there's a need to
look at the forward path.

Ed

PS - My work is based, except where noted, on what is recorded in the
RFCs.  I know that the RFCs aren't all encompassing but I wasn't "in the
room" so have no other input to add.  (I know this from being "in the
room" and seeing the resulting RFC lacking some important detail.)  If
others were in the room and have other points of data to supply, please do
so - preferably with a citable reference.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-18 Thread George Michaelson 
My private comment bears repeating in public.

DOMAIN names is about the property of domains. Domains are encompassing,
set-theory/venn-diagram style. A domain and a prefix are analogous
concepts. One is expressed syntactically somehow, the other is a
mathematical property of bounding in a number field but they have the same
basic behaviour.

the UK domain order in coloured book mails obeyed this property: it just
used reverse semantics to the ARPA model.

.onion is *not* a domain name inside the .onion part: as I
understand it, the value is a hash, or other function which has no nesting
properties expressed syntactically.

This quality of domain names, the concepts of domains, is a distinct
property which bears thinking about.

HOST.TXT was not a domain system, it was a linear map. Honey Danber had
some qualities of domain-ness. Usenet groups after the great mod.*
 reordering became more domain like.



On Thu, Sep 17, 2015 at 4:58 PM, Edward Lewis 
wrote:

> Don't know if this will be posted to DNSOP some other way.
>
> (I've gotten one private comment, so it's been announced somewhere,
> someway.)
>
> On 9/17/15, 13:50, "internet-dra...@ietf.org" 
> wrote:
>
> >Name:  draft-lewis-domain-names
> >Revision:  00
> >Title: Domain Names
> >Document date: 2015-09-17
> >Group: Individual Submission
> >Pages: 13
> >URL:
> >https://www.ietf.org/internet-drafts/draft-lewis-domain-names-00.txt
> >Status:
> https://datatracker.ietf.org/doc/draft-lewis-domain-names/
> >Htmlized:   https://tools.ietf.org/html/draft-lewis-domain-names-00
> >
> >
> >Abstract:
> >This document states a definition of Domain Name beyond the use of
> >the term within the Domain Name System.  The document includes a
> >survey of the diverse ways Domain Names have been interpreted within
> >various protocols over time.  The purpose of this is to give a solid
> >foundation for work on Domain Names across all protocols making use
> >of Domain Names.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-lewis-domain-names-00.txt

2015-09-17 Thread Darcy Kevin (FCA) 
Ed,
I find the document useful, and illuminating, but that it suffers from 
one glaring omission -- no substantive discussion of the relationship between 
domain names and URIs (the related term "URN"[1] is mentioned in Section 1.2, 
but never expanded upon). To be sure, while the "Authority" component of a URI 
is not *always* based on a DNS name (or a "domain name", as distinguished in 
your Draft), it _usually_ is, and RFC 3986, aka STD 66, makes the relationship 
quite explicit:

"However, a globally scoped naming
system, such as DNS fully qualified domain names, is necessary for
URIs intended to have global scope. URI producers should use names
that conform to the DNS syntax, even when use of DNS is not
immediately apparent ..."

So, names in URI "Authority"s should *look* like DNS-style FQDNs, even if some 
other "Authority" resolution-and/or-uniqueness-guaranteeing mechanism underpins 
the particular Scheme. 

Since URIs are so commonplace in modern communication mechanisms (including one 
little app called web browsing :-), I think the tie-in between URIs and domain 
names should at least be mentioned in a comprehensive "domain names" document.


- Kevin

[1] As per STD 66: "Future specifications and related documentation should use 
the general term 'URI' rather than the more restrictive terms 'URL' and 'URN'".

-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Edward Lewis
Sent: Thursday, September 17, 2015 3:59 PM
To: dnsop
Subject: [DNSOP] draft-lewis-domain-names-00.txt

Don't know if this will be posted to DNSOP some other way.

(I've gotten one private comment, so it's been announced somewhere,
someway.)

On 9/17/15, 13:50, "internet-dra...@ietf.org" 
wrote:

>Name:  draft-lewis-domain-names
>Revision:  00
>Title: Domain Names
>Document date: 2015-09-17
>Group: Individual Submission
>Pages: 13
>URL:
>https://www.ietf.org/internet-drafts/draft-lewis-domain-names-00.txt
>Status: https://datatracker.ietf.org/doc/draft-lewis-domain-names/
>Htmlized:   https://tools.ietf.org/html/draft-lewis-domain-names-00
>
>
>Abstract:
>This document states a definition of Domain Name beyond the use of the 
>term within the Domain Name System.  The document includes a survey of 
>the diverse ways Domain Names have been interpreted within various 
>protocols over time.  The purpose of this is to give a solid foundation 
>for work on Domain Names across all protocols making use of Domain 
>Names.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop