------ Original Message ------
From: "Mark Andrews" <ma...@isc.org>
To: "Adrien de Croy" <adr...@qbik.com>
Cc: "Robert Edmonds" <edmo...@mycre.ws>; "dnsop@ietf.org"
<dnsop@ietf.org>; "Paul Hoffman" <paul.hoff...@vpnc.org>
Sent: 3/04/2016 4:47:20 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
In message <em8bf94e58-4db5-4277-86ce-c0c5c0dc893f@bodybag>, "Adrien de
Croy" writes:
that's correct. It looks in that document like a quote from the IAB,
but if you're saying it's not, I then would have to challenge the
logical conclusion asserted in that second paragraph.
I don't see why it necessarily follows that having a single tree with
a
single root creates a requirement for support for multiple resolution
protocols.
Because the only other way to be able to distingish between a onion
address and a DNS name would be to have onion use labels with a
wire representaion that are longer that 63 octets or with overall
lengths greater that 255 wire octets
It looks like you're talking about making a name that can't be encoded
on a DNS packet and so therefore can't be looked up with DNS, but that's
not necessarily going to achieve any specific distinction between DNS
any any other specific name space, it's just a broken (in a DNS-centric
POV) name, rather than onion name specifically.
or you have to prefix all names
with DNS and ONION to identify the resolution namespace.
Prefixing with some kind of protocol identifier is what is done with
URIs. There's pretty good recognition out there for that kind of thing?
Almost
any string of characters will form a valid DNS name.
as long as it's only alphanumerics and -.
This was my signature back in 1995. Note you had to NAME the
NAMESPACES.
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: ma...@syd.dms.csiro.au
UUCP: ....!uunet!syd.dms.csiro.au!marka
None of us grey beards want to go back to those days.
We could have added "*.onion 604800 IN NULL" to the root zone and
fixed all the resolvers to stop searching on NOERROR but that does
not stop the fact that you want to use TOR alone with who you want
to talk to leaking unintentionally.
OK this is the nub of it. You want to connect to a global privacy
network and from there privately access services. Fundamentally you're
still connecting over IP, so you need to resolve an IP address of the
network entry point. This is still a DNS name. You then connect to
that.
Once you're connected, you're talking your own protocol, and then you
can resolve names within your system any way you please, even LDAP. I
don't see why DNS has to even be involved there.
Or is the problem about antispam doing lookups on onion names embedded
in emails? What about a URI format?
The thousands of authors of other protocols and systems don't seem to
have had too much trouble so far just using DNS where required, and
putting resolution into their own protocols outside the tree. Why
break
the whole tree for some nebulous result which surely in all cases can
be
worked around with a smaller consequence than having to deploy new
DNS
to the entire world.
Even a DSL/NAT box does DNS forwarding, do we expect all those cheap
router box vendors to patch out the firmware for this any time soon?
No. The expectation is that future boxes that they ship will
implement the protocol and not pass on the leaked name. The
expectation is that any update issued will also address this.
I wouldn't be surprised if the people making these boxes are mostly
unaware of this added requirement on them.
The RFC allows DNS only resolvers, proxies and recursive servers
to all generate NXDOMAIN responses in the event of a leak. This
will result in SERVFAIL in some cases as the validation of the
response will fail but it will still prevent the leak spreading.
The proposed deployment methods make me uneasy as well.
For example. Some smart DNS developer, looks at special use names, sees
that there's now a sanctioned mechanism to get new root namespaces into
the DNS, and figures hey I should check some central location
occasionally for a list of root level domains I should return NXDOMAIN
for.
Someone hacks that list to include .com
Since there is no machine-readable repo for this, vendors will make
their own, and those may/will be hackable.
Maybe would be better if just the root servers returned NXDOMAIN, but
the leak is already occured by that stage.
In any case I think it's foolhardy to rely on there being no leak, and
TOR would have done better by its customers to whom it is promising
privacy, to not rely for privacy/security on changes being made to a
system which has a vast inertia.
And that inertia means we should avoid at all costs any new feature
which means we have to change out all DNS. Not create new mechanisms
for it.
Adrien
Adrien
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
