Subject: [DNSOP] Tor frustration

From: Hugo Maxwell Connery <[email-masked]>
Date: Fri, 17 Jul 2015 15:00:07 +0000

For those who are trying to provide their comments to the 
6761 discussions, I highly recommend:

1. go to https  torproject org  and download the client
2. Have wireshark / ethereal
3. Start 2 and then 3 and see what happens on the wire.

You can also access all of the design discussion and materials
and source code for Tor at torproject org.

And their funding and so much more.  They are a model of transparency.

(Sorry; there have been many comments which displayed a lack
of understanding of Tor from persons whose comments seem deserving
of respect but seem under-informed).

/Hugo

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 17 Jul 2015 18:39:11 -0700

Moin!

> 3. Start 2 and then 3 and see what happens on the wire.
Can you for us uninformed please elaborate what happens.
That way I don't have to go to all that. Am I right that
there is leakage of dns requests with .onion TLDs? If
so isn't that a bug in their software?

Looking from a purely DNS perspective this draft says,
alter all your DNS clients, resolver and even authoritative
servers (who never would get a request for .onion anyway)
to do something different then what is in the protocol
specs. Seems a bit broad to me. But most of the discussion
seemed to focus on OSI layers above DNS (mostly above 7), 
so I didn't follow it to much.

> of respect but seem under-informed).
This is the dnsop working group, so I'm not sure if I have
to know TOR to participate here. I assume that people in here
have a basic understanding of the dns protocol (knowledge in
operating DNS servers also might help as it is an ops group), 
and that everything else has to be explained in the draft. If 
my understanding of the problem (leakage) is incorrect than 
it hasn't done a good job there. I'm ok with .onion being 
a special name, but we should just do that by normal DNS
mechanism. What's wrong with answering REFUSED?. Answering
NXDomain is much harder in a DNSSEC world.

So long
-Ralf

---

From: hellekin <[email-masked]>
Date: Fri, 17 Jul 2015 23:28:13 -0300

On 07/17/2015 10:39 PM, Ralf Weber wrote:
>
> Am I right that there is leakage of dns requests with 
> .onion TLDs? If so isn't that a bug in their software?
> 
*** Almost:

1) .onion is not a TLD (sorry, I made the mistake myself to abuse TLD,
although I had defined pTLD for that purpose--as in: pseudo-TLD, but for
consistency we're using Special-Use Domain Name there)

2) yes, leakage of requests for .onion names to the DNS is one of the
problems we're facing.

3) No, it's not a bug in the software, it's due to broken configurations
of the local resolver and applications wrongly sending .onion requests
to the DNS (e.g., Web browsers' pre-fetching feature)

> authoritative servers (who never would get a request for .onion anyway)
>
*** They could if there's no RFC to forbid it. Actually they could even
with such a document, but other actors would then rightfully decline
their non-NXDOMAIN response.

> to know TOR to participate here.
>
*** But to participate in a discussion related to Tor (not TOR), it's
useful. I refrain to participate in discussions where I don't know what
I'm talking about: I already have difficulties with the topics I think I
master. That said, participating is the best way to learn :)

> I'm ok with .onion being  a special name, but we should just do
> that by normal DNS mechanism. What's wrong with answering REFUSED?.
>
*** Refused does not mean that you're dealing with a non-existent name
(3 Name Error), especially one that is NOT in DNS.  It means that the
server refused to perform the request, but does not inform you of the
"specialness" of this particular .onion Special-Use Domain Name (RFC 6761).

> Answering NXDomain is much harder in a DNSSEC world.
> 
*** Well, Tor is not in the DNSSEC world, it's not even in the DNS
world, that's the point of Name Error in that case, and of the draft in
question.

Regards,

==
hk

---

From: Edward Lewis <[email-masked]>
Date: Sat, 18 Jul 2015 06:28:59 +0000

On 7/18/15, 3:39, "DNSOP on behalf of Ralf Weber" <[email-masked]
on behalf of [email-masked]> wrote:
>I'm ok with .onion being

If "onion" is not delegated in the root zone, then DNS servers will answer
NXDOMAIN for it - without change.

$ dig something.onion A

; <<>> DiG 9.8.3-P1 <<>> something.onion A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55221
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;something.onion.		IN	A

;; ANSWER SECTION:
something.onion.	15	IN	A	92.242.140.2

;; Query time: 14 msec
;; SERVER: 68.105.28.11#53(68.105.28.11)
;; WHEN: Sat Jul 18 02:26:34 2015
;; MSG SIZE  rcvd: 49

Oh, wait, oops.  My ISP's recursive name server likes to substitute
landing pages. ;)

Sigh.  This wasn't something I had thought of.

(Seriously, this isn't to make a point.  It's another wrinkle.)

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 18 Jul 2015 00:27:19 -0700

Moin!

> their non-NXDOMAIN response.
RFC don't have the power to forbid anything on the Internet. Especially
if you are dealing with DNS on the recursive side you see RFC violations
every day.

> master. That said, participating is the best way to learn :)
I know which I up to now have not participated in that discussion up to
now. My day job is helping people running DNS servers and the bandwidth
beside that is limited, but for the purpose of that discussion I think
I understood the motivation for a special name is the leakage of
requests and the possibility of getting certs as I was told and I
understand that.

> "specialness" of this particular .onion Special-Use Domain Name (RFC 
Well one of the domains defined in RFC6761 is invalid. So lets see how
that is handled today by the authoritative name servers. Here is what is
happening when I ask the root servers

dig blafasel.invalid +dnssec +norec @k.root-servers.net

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> blafasel.invalid +dnssec +norec 
@k.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46004
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;blafasel.invalid.		IN	A

;; AUTHORITY SECTION:
international.		86400	IN	NSEC	investments. NS DS RRSIG NSEC
international.		86400	IN	RRSIG	NSEC 8 1 86400 20150727170000 
20150717160000 1518 . 
eK2BLKY9FDf+0iPm3ycygrSkjB6qRRUkPUtDt+TJhTmQXGJ0gXXZK5jD 
FPrYWcSbJnGTyxJQRLnyXc9cItUGHv5I1PIzC9dZYwBuvBd//4WHC+WY 
2AR86+qPRkc6Cml/E+8hRscu41Uab0+2+dLDLXgrWYUzbllQ7FaNthZG LF0=
.			86400	IN	NSEC	abb. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20150727170000 20150717160000 1518 . 
qQrsIJPO+bBjpik6BT3VwV7quxLMrb0OkC0JuFWMsUiet/4cxCeqj6r9 
dY937dcYiL/DQ1VtGUXlCcxPN6kw9hOou3lUBHzIJVrPuDdXVjFdDcMo 
UPxqj18VtWr+gf/7zPNaSAPMZeS/uccTwXNUDDIBghQr72oMLWpL3DrU uzc=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2015071701 
1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20150727170000 20150717160000 1518 . 
J42c6EmUxDWXgXxxMz39iyM6AuYBNiTbxQIzrNfaebcQNFHGiEHr+xfW 
M/m2xDBt857L3Uqua6SwI5Kbnv6EAxRdWR50SjYBVBKzvJU4fn0yFHDX 
Mxoxv83Kjqv+34JyL6Jad+rQeHd8zEUD2hTlMAhEJgR1QocDCchanbfQ fEU=

;; Query time: 4 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Sat Jul 18 08:46:37 CEST 2015
;; MSG SIZE  rcvd: 666

as you see you get an authenticated NXDomain as you would expect by 
normal
DNS semantics. Lets ask an unrelated server for it:

dig blafasel.invalid +dnssec +norec @pri.authdns.ripe.net.

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> blafasel.invalid +dnssec +norec 
@pri.authdns.ripe.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 16928
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;blafasel.invalid.		IN	A

;; Query time: 20 msec
;; SERVER: 2001:67c:e0::5#53(2001:67c:e0::5)
;; WHEN: Sat Jul 18 08:46:25 CEST 2015
;; MSG SIZE  rcvd: 45

As you see it gives the default answer for an authoritative server
that is not responsible for a domain. I've also seen servers
answering with referrals to the root, but I have not found one
other than the root servers that answers NXDomain.

> world, that's the point of Name Error in that case, and of the draft 
Tor might not be in the DNSSEC world every dns query that hits a server
hopefully will be in the future and as you see the special use name 
invalid.
is. With that you get the expected behaviour of NXDomain even if the
recursive resolvers and stub resolvers have not been updated for the
specialness of invalid., and in the future onion.

As said I have no problem with .onion getting a special use domain name
allocation I just think it doesn't need to be more special than what we
currently have. And it would be good if we could tackle the problem with
configuration of DNS servers as it is possible with the other RFC6761
names.

So long
-Ralf