Subject: Re: [dns-privacy] Non-DNS traffic over port 53?

From: Tao Wan <[email-masked]>
Date: Tue, 6 Jan 2015 20:28:35 +0000

Hi Warren,

You may find the following paper interesting, albeit not exactly what you are looking for: 
"Practical Comprehensive Bounds on Surreptitious Communication over DNS" (by Vern Paxson, et al). 

https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/paxson

It analyzed 230 billions of DNS lookups, and found 59 confirmed tunnels established over DNS.

Cheers,
Tao Wan

-----Original Message-----
From: dns-privacy [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Tuesday, December 30, 2014 12:24 PM
To: [email-masked]
Subject: [dns-privacy] Non-DNS traffic over port 53?

Hi there all,

First off, apologies for the lack of activity since Hawaii. We (the
chairs) have been procrastinating and got a little sidetracked with
day-jobs. We are finally getting our lives organized, getting github
setup for issue tracking, etc.

One of the open questions is how to deal with / how bad the infamous
middlebox problem is. This will somewhat dictate what solutions we are
able to consider / will work in the real world.

So, I was wondering if anyone has any data / has seen any research on
just how well "non-DNS" traffic works over port 53 - UDP and TCP? So,
if one tries to pass $random_protcol over port 53 from behind various
CPE / firewalls / IPS / etc how likely is it to work?

Many years ago I tried running VPNs and SSH over port 53 to try and
deal with broken captive portals (Ok, it was more to avoid paying what
I viewed as usury rates / to avoid icky ACLs).  This had mixed success
(used to work somewhat OK, but then got slowly less likely to work
over time) - obviously this was a special case, knowing how this works
in general / today would be very useful to informing what solutions
are worth pursuing.

W
-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 6 Jan 2015 22:05:30 -0500

While tunneling over DNS is interesting, it isn't really the answer to our
problem which is how to establish a robust and efficient encrypted DNS
protocol.

DNS tunnels tend to be used by folk willing to tolerate low bandwidth and
low latency. Cramming your requests into BASE32 encoded labels and your
responses into BASE64 encoded TXT fields comes at a cost. That is fine if
the only lookups you want to do are A and AAAA but not so great if you want
to do DNSSEC.

There are ways to do efficient discovery over a DNS tunnel, in fact that
was the original rationale for Omnibroker. Faced with a lossy, low
bandwidth channel, I decided to compress multiple queries into one.

The much simpler solution is to abandon the use of port 53 for encrypted
DNS and negotiate the port number along with the crypto parameters. UDP
works fine on non port 53 in over 95% of cases and most importantly, there
is no way for British Telecom to know that you are making a DNS query so
they can redirect your requests for google.com to their proxy which does
SSL stripping - like I found them doing to me over the weekend.

Lets just get over the well known port concept. It is not scalable and it
is not necessary for what we are doing here. Do the connection
establishment over port 80 or port 443 and let the attacker guess what the
service port is.

For the rare cases where you can't do port 53 then you can either fall back
to DNS tunneling or to HTTP/HTTPS. In the first drafts of Omnibroker I
suggested both but figures from the TLS faction here convince me that we
don't really need both.