There is a corollary: If a future revision of .onion labels exceeds 63/256
boundary conditions, then it will change behaviour when presented in the
DNS. In the current situation, it will earn an NXDOMAIN and 'dtrt' in as
much as the return says 'this label is not in the DNS'
in future, if it exceeds the (1980s, we were all younger and wiser then)
proscribed field semantics for DNS, it will return FORMERR and other
replies which may tickle other behaviour than you (we?) expect.
I know I keep harping on about the DNS, and your main goal is to NOT BE in
the DNS. But we also realize the reality that these labels will be
presented to dns gethostbyname() and other packages (getDNS api?) -So the
s/w behaviours of systems have to be considered. A couple of postings in
the thread(s) of this discussion make it clear we all understand, the
labels are going to be seen in the DNS system/ecology, irrespective of if
we wish it or not.
I don't actually think any language has to change. You might just want to
document in TOR paperwork, that changes to the syntax of xxx.onion has to
be assessed against its behaviours in other name-lookup systems.
-G
PS
$ dig @8.8.8.8
123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net.
in a
; <<>> DiG 9.10.2-P3 <<>> @8.8.8.8
123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net.
in a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50749
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;
123456789012345678901234567890123456789012345678901234567890123.x.dashnxdomain.net.
IN A
;; AUTHORITY SECTION:
dashnxdomain.net. 0 IN SOA ns1.dashnxdomain.net. research.apnic.net.
2015072201 900 300 1 1
;; Query time: 496 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Aug 13 12:54:03 UYT 2015
;; MSG SIZE rcvd: 166
$ dig @8.8.8.8
1234567890123456789012345678901234567890123456789012345678901234.x.dashnxdomain.net.
in a
dig: '
1234567890123456789012345678901234567890123456789012345678901234.x.dashnxdomain.net.'
is not a legal name (label too long)
$
On Thu, Aug 13, 2015 at 11:17 AM, Nick Mathewson
<nickm(_at_)alum(_dot_)mit(_dot_)edu> wrote:
On Wed, Aug 12, 2015 at 4:49 PM, Alec Muffett <alecm(_at_)fb(_dot_)com> wrote:
On Aug 12, 2015, at 1:16 PM, Ted Hardie
<ted(_dot_)ietf(_at_)gmail(_dot_)com> wrote:
If you're willing to put a statement like it in the draft, that works for
me; it would need to include a slightly broader commitment (not to step
on
other syntax bits, like the IDNA prefix etc), but I think the broader
statement would go to exactly the same goal.
Given that this is about Onion Registration rather than about Tor
Project,
some wording like
“Onion addresses are [blah description blah] and which are consistent
with
DNS syntax limitations of 63 character labels..."
…which I think would impose a constraint whilst being aimed at the
supposedly correct target.
I’ll copy Nick on this to be doubly certain.
I think that's (broadly) a good solution.
The important thing here AFAIU is not to nail down the exact semantics
of current .onion addresses or post-revision .onion addresses or
25-years-from-now .onion addresses... but rather to carve out enough
space for this and future revisions.
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)".
But it it would be problematic to say something like ".onion addresses
are are exactly N characters long" or ".onion addresses have the
following structure" or ".onion addresses have exactly two labels" or
anything like that. So let's avoid those.
cordially,
--
Nick