Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: self-providing encrypted DNS  (Read 4880 times)

G.DMT

  • Member
  • **
  • Posts: 76
self-providing encrypted DNS
« on: April 28, 2016, 04:43:11 PM »

Originally, I posted this as a reply to :
'Android stealthily forcing google dns' http://forum.kitz.co.uk/index.php/topic,17374.msg317604.html#msg317604

But I realised that it was:
a) completely off topic in
    Computers & Hardware >  Android & other hand held devices
and
b) too much of a thread hijack

So I thought better of that and tried to find a better place to post it.
'General Internet' seemed like a relevant area, but mods feel free to move this if I have overlooked a more appropriate sub-forum.

Anyways a comment from Chrysalis piqued my interest:

I am considering moving my DNS server out of the UK tho, as I wonder how much power the UK authority has in been able to get the transit provider at my UK location to sniff my dns traffic, the DNScrypt will encrypt between my router and the server which stops sky sniffing, but not from the server to other DNS servers.  The problem been that DNScrypt is a hack, its not a standard, so there is no encryption protocol for server to server queries.

Similarly I prefer DNScrypt to encrypt client to server queries and similarly I prefer to administer my own DNS server with a free public service (opendns) as a backup.

ATM I run unbound as a server hosted DNS resolver, mostly for the ease of setup and maintenance since I feel that I can probably rely on Debian packagers for security updates.  :)

I also had it in my mind to at some point change the setup to obfuscate the currently plaintext server-to-server queries that Chrysalis mentions.

However, in The Real Word, time is a finite resource, and I have not (yet) spent the time to reimplement an otherwise functional system.

The general idea would be to change from setup

A) (myclient) -> dnscrypt client proxy [1] -> _encrypted_ (myserver) -> dnscrypt-wrapper [2]  -> myDNS_daemon [ unbound | Powerdns | DNSmasq | Bind ] -> _unencrypted_ root servers
 to
B) (myclient) -> dnscrypt client proxy [1] -> _encrypted_ (myserver) -> dnscrypt-wrapper [2]  -> {DNSmasq -> dnscrypt client proxy} -> _encrypted_   open public servers e.g opendns*

[1] https://dnscrypt.org/#dnscrypt-proxy
[2] https://dnscrypt.org/#dnscrypt-server
* https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv

The basic idea behind configuring  such an overly convoluted query architecture being that dnsmasq allows to control where the servers queries are directed to, and thus could be configured to despatch them via dnscrypt-proxy, which would thus allow them to be serviced by an encrypted server upstream. 

Not exactly ideal, but possibly better than the existing undesireable plaintext.

As I happened to mention in another post earlier this morning, UKNOF34 had a couple of interesting presentations on the dnsdist configurable DNS server
http://forum.kitz.co.uk/index.php/topic,17559.msg321838.html#msg321838

I see that this interesting line has appeared on the dnscrypt.org site at the end of para [1]

'dnsdist can act as a DNSCrypt server when compiled with --enable-dnscrypt.'

Which suggests that the following (much less complicated) setup is now a possibility
 
C) (myclient) -> dnscrypt client proxy [1] -> _encrypted_ (myserver) -> dnsdist [3]
leaving open the question of
 (myserver) -> [ root servers |  open public servers e.g opendns ]

[3] http://dnsdist.org/README/#DNSCrypt

So it looks like there may now be 2 FOSS server based solutions possible.

I would appreciate any thoughts/comments/suggestions from anyone interested in the provision of encrypted DNS.  ;D

Thanks for reading this far!   :)

p.s. Anyone interested in providing encrypted DNS services to their LAN can easily do so via OpenWRT
https://wiki.openwrt.org/inbox/dnscrypt   ;)

p.p.s. Anyone interested in trying the namecoin encrypted DNS service can easily do so via the Gargoyle open source router project where it has been integrated into the GUI for years.
https://www.gargoyle-router.com/phpbb/viewtopic.php?f=3&t=2120
« Last Edit: April 28, 2016, 05:26:05 PM by G.DMT »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: self-providing encrypted DNS
« Reply #1 on: April 29, 2016, 05:50:02 AM »

As an alternative, you could put your DNS traffic through a VPN tunnel to an overseas server?
Logged

loonylion

  • Reg Member
  • ***
  • Posts: 723
Re: self-providing encrypted DNS
« Reply #2 on: April 29, 2016, 11:48:34 AM »

As an alternative, you could put your DNS traffic through a VPN tunnel to an overseas server?

obvious issue there is it could significantly increase latency on dns lookups, which would in turn make everything else slower.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: self-providing encrypted DNS
« Reply #3 on: May 01, 2016, 08:11:23 AM »

In that case, need a really really fast router, with CPU support for crypto. Could QoS-prioritise DNS packets, it all small packets, which some routers do already, which would be a big help when things are heavily loaded. If you can overlap DNS requests then the latency time shouldn't be such a big deal.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7405
  • VM Gig1 - AAISP CF
Re: self-providing encrypted DNS
« Reply #4 on: May 01, 2016, 11:52:17 AM »

dnscrypt is pretty light weaver.

I compared opendns normal to opendns crypto and the latency difference doesnt really register and the cpu can handle it.  These are only tiny packets.

Using a vpn just for dns is overkill.

here is some histogram data for my dnscrypt lookups. (note these are not for opendns, these are to my personal dns server running on a VPS)

Code: [Select]
May  1 10:23:45 unbound: [1419:1] info: server stats for thread 1: 8794 queries, 1919 answers from cache, 6875 recursions, 65 prefetch
May  1 10:23:45 unbound: [1419:1] info: server stats for thread 1: requestlist max 14 avg 1.30519 exceeded 0 jostled 0
May  1 10:23:45 unbound: [1419:1] info: average recursion processing time 0.163243 sec
May  1 10:23:45 unbound: [1419:1] info: histogram of recursion processing times
May  1 10:23:45 unbound: [1419:1] info: [25%]=0.0343178 median[50%]=0.101478 [75%]=0.213324
May  1 10:23:45 unbound: [1419:1] info: lower(secs) upper(secs) recursions
May  1 10:23:45 unbound: [1419:1] info:    0.000000    0.000001 260
May  1 10:23:45 unbound: [1419:1] info:    0.000128    0.000256 1
May  1 10:23:45 unbound: [1419:1] info:    0.000256    0.000512 495
May  1 10:23:45 unbound: [1419:1] info:    0.000512    0.001024 34
May  1 10:23:45 unbound: [1419:1] info:    0.001024    0.002048 11
May  1 10:23:45 unbound: [1419:1] info:    0.002048    0.004096 25
May  1 10:23:45 unbound: [1419:1] info:    0.004096    0.008192 48
May  1 10:23:45 unbound: [1419:1] info:    0.008192    0.016384 257
May  1 10:23:45 unbound: [1419:1] info:    0.016384    0.032768 537
May  1 10:23:45 unbound: [1419:1] info:    0.032768    0.065536 1073
May  1 10:23:45 unbound: [1419:1] info:    0.065536    0.131072 1270
May  1 10:23:45 unbound: [1419:1] info:    0.131072    0.262144 1825
May  1 10:23:45 unbound: [1419:1] info:    0.262144    0.524288 807
May  1 10:23:45 unbound: [1419:1] info:    0.524288    1.000000 180
May  1 10:23:45 unbound: [1419:1] info:    1.000000    2.000000 27
May  1 10:23:45 unbound: [1419:1] info:    2.000000    4.000000 19
May  1 10:23:45 unbound: [1419:1] info:    4.000000    8.000000 1
May  1 10:23:45 unbound: [1419:1] info:    8.000000   16.000000 1
May  1 10:23:45 unbound: [1419:1] info:   16.000000   32.000000 4
May  1 10:23:46 unbound: [1417:0] info: server stats for thread 0: 9446 queries, 2261 answers from cache, 7185 recursions, 46 prefetch
May  1 10:23:46 unbound: [1417:0] info: server stats for thread 0: requestlist max 15 avg 1.15309 exceeded 0 jostled 0
May  1 10:23:46 unbound: [1417:0] info: average recursion processing time 0.276986 sec
May  1 10:23:46 unbound: [1417:0] info: histogram of recursion processing times
May  1 10:23:46 unbound: [1417:0] info: [25%]=0.035446 median[50%]=0.101953 [75%]=0.216486
May  1 10:23:46 unbound: [1417:0] info: lower(secs) upper(secs) recursions
May  1 10:23:46 unbound: [1417:0] info:    0.000000    0.000001 202
May  1 10:23:46 unbound: [1417:0] info:    0.000064    0.000128 1
May  1 10:23:46 unbound: [1417:0] info:    0.000256    0.000512 560
May  1 10:23:46 unbound: [1417:0] info:    0.000512    0.001024 23
May  1 10:23:46 unbound: [1417:0] info:    0.001024    0.002048 20
May  1 10:23:46 unbound: [1417:0] info:    0.002048    0.004096 17
May  1 10:23:46 unbound: [1417:0] info:    0.004096    0.008192 47
May  1 10:23:46 unbound: [1417:0] info:    0.008192    0.016384 277
May  1 10:23:46 unbound: [1417:0] info:    0.016384    0.032768 556
May  1 10:23:46 unbound: [1417:0] info:    0.032768    0.065536 1141
May  1 10:23:46 unbound: [1417:0] info:    0.065536    0.131072 1347
May  1 10:23:46 unbound: [1417:0] info:    0.131072    0.262144 1838
May  1 10:23:46 unbound: [1417:0] info:    0.262144    0.524288 839
May  1 10:23:46 unbound: [1417:0] info:    0.524288    1.000000 220
May  1 10:23:46 unbound: [1417:0] info:    1.000000    2.000000 27
May  1 10:23:46 unbound: [1417:0] info:    2.000000    4.000000 13
May  1 10:23:46 unbound: [1417:0] info:    4.000000    8.000000 11
May  1 10:23:46 unbound: [1417:0] info:    8.000000   16.000000 17
May  1 10:23:46 unbound: [1417:0] info:   16.000000   32.000000 29
« Last Edit: May 01, 2016, 11:56:48 AM by Chrysalis »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7405
  • VM Gig1 - AAISP CF
Re: self-providing encrypted DNS
« Reply #5 on: May 07, 2016, 03:15:57 PM »

things are slower sadly with my above config.

here is histogram for opendns without dnsscrypt.

Code: [Select]
May  7 15:02:24 unbound: [17035:0] info: server stats for thread 0: 460 queries, 263 answers from cache, 197 recursions, 4 prefetch
May  7 15:02:24 unbound: [17035:0] info: server stats for thread 0: requestlist max 4 avg 0.308458 exceeded 0 jostled 0
May  7 15:02:24 unbound: [17035:0] info: average recursion processing time 0.019593 sec
May  7 15:02:24 unbound: [17035:0] info: histogram of recursion processing times
May  7 15:02:24 unbound: [17035:0] info: [25%]=0.00884891 median[50%]=0.0165027 [75%]=0.0281971
May  7 15:02:24 unbound: [17035:0] info: lower(secs) upper(secs) recursions
May  7 15:02:24 unbound: [17035:0] info:    0.000000    0.000001 2
May  7 15:02:24 unbound: [17035:0] info:    0.000256    0.000512 25
May  7 15:02:24 unbound: [17035:0] info:    0.000512    0.001024 3
May  7 15:02:24 unbound: [17035:0] info:    0.001024    0.002048 2
May  7 15:02:24 unbound: [17035:0] info:    0.002048    0.004096 4
May  7 15:02:24 unbound: [17035:0] info:    0.004096    0.008192 9
May  7 15:02:24 unbound: [17035:0] info:    0.008192    0.016384 53
May  7 15:02:24 unbound: [17035:0] info:    0.016384    0.032768 69
May  7 15:02:24 unbound: [17035:0] info:    0.032768    0.065536 21
May  7 15:02:24 unbound: [17035:0] info:    0.065536    0.131072 9
May  7 15:02:24 unbound: [17036:1] info: server stats for thread 1: 596 queries, 373 answers from cache, 223 recursions, 7 prefetch
May  7 15:02:24 unbound: [17036:1] info: server stats for thread 1: requestlist max 4 avg 0.213043 exceeded 0 jostled 0
May  7 15:02:24 unbound: [17036:1] info: average recursion processing time 0.031704 sec
May  7 15:02:24 unbound: [17036:1] info: histogram of recursion processing times
May  7 15:02:24 unbound: [17036:1] info: [25%]=0.00852824 median[50%]=0.0153447 [75%]=0.0295051
May  7 15:02:24 unbound: [17036:1] info: lower(secs) upper(secs) recursions
May  7 15:02:24 unbound: [17036:1] info:    0.000256    0.000512 46
May  7 15:02:24 unbound: [17036:1] info:    0.000512    0.001024 1
May  7 15:02:24 unbound: [17036:1] info:    0.001024    0.002048 2
May  7 15:02:24 unbound: [17036:1] info:    0.002048    0.004096 2
May  7 15:02:24 unbound: [17036:1] info:    0.004096    0.008192 2
May  7 15:02:24 unbound: [17036:1] info:    0.008192    0.016384 67
May  7 15:02:24 unbound: [17036:1] info:    0.016384    0.032768 59
May  7 15:02:24 unbound: [17036:1] info:    0.032768    0.065536 29
May  7 15:02:24 unbound: [17036:1] info:    0.065536    0.131072 9
May  7 15:02:24 unbound: [17036:1] info:    0.131072    0.262144 2
May  7 15:02:24 unbound: [17036:1] info:    0.262144    0.524288 1
May  7 15:02:24 unbound: [17036:1] info:    0.524288    1.000000 3

Notice its way faster much closer to my base latency.  I am going to expriment some to see how close I can bridge the performance gap, sadly with dnscrypt it can feel like a heavily interleaved connection at times.

Also one of the problems with using my own personal dns server is it's cache is not always pre populated, as I am the only dns client, unbound has a prefetch feature but it only pre populates when a dns lookup is made and the TTL is down to 10%, it doesnt pre populate otherwise.

Bind I think will pre populate based on a usage algorithm so does not require a dns lookup to be made within the last 10% of the TTL lifetime.

Dnscrypt will occasionally cause a very slow lookup 2+secs.  But on average only bumps the latency a small amount.

The biggest slowdowns are dnssec lookups (opendns doesnt support dnssec) and if using my own dns server having to repopulate the cache.
« Last Edit: May 07, 2016, 03:20:19 PM by Chrysalis »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7405
  • VM Gig1 - AAISP CF
Re: self-providing encrypted DNS
« Reply #6 on: May 07, 2016, 06:42:19 PM »

opendns 'with' dnscrypt.

Code: [Select]
May  7 17:22:18 unbound: [17255:1] info: server stats for thread 1: 593 queries, 176 answers from cache, 417 recursions, 7 prefetch
May  7 17:22:18 unbound: [17255:1] info: server stats for thread 1: requestlist max 3 avg 0.372642 exceeded 0 jostled 0
May  7 17:22:18 unbound: [17255:1] info: average recursion processing time 0.024723 sec
May  7 17:22:18 unbound: [17255:1] info: histogram of recursion processing times
May  7 17:22:18 unbound: [17255:1] info: [25%]=0.00501221 median[50%]=0.0227795 [75%]=0.0421786
May  7 17:22:18 unbound: [17255:1] info: lower(secs) upper(secs) recursions
May  7 17:22:18 unbound: [17255:1] info:    0.000256    0.000512 88
May  7 17:22:18 unbound: [17255:1] info:    0.001024    0.002048 3
May  7 17:22:18 unbound: [17255:1] info:    0.002048    0.004096 9
May  7 17:22:18 unbound: [17255:1] info:    0.004096    0.008192 19
May  7 17:22:18 unbound: [17255:1] info:    0.008192    0.016384 45
May  7 17:22:18 unbound: [17255:1] info:    0.016384    0.032768 114
May  7 17:22:18 unbound: [17255:1] info:    0.032768    0.065536 121
May  7 17:22:18 unbound: [17255:1] info:    0.065536    0.131072 13
May  7 17:22:18 unbound: [17255:1] info:    0.131072    0.262144 5
May  7 17:22:19 unbound: [17254:0] info: server stats for thread 0: 664 queries, 234 answers from cache, 430 recursions, 7 prefetch
May  7 17:22:19 unbound: [17254:0] info: server stats for thread 0: requestlist max 4 avg 0.489703 exceeded 0 jostled 0
May  7 17:22:19 unbound: [17254:0] info: average recursion processing time 0.028074 sec
May  7 17:22:19 unbound: [17254:0] info: histogram of recursion processing times
May  7 17:22:19 unbound: [17254:0] info: [25%]=0.0080896 median[50%]=0.0241731 [75%]=0.0447462
May  7 17:22:19 unbound: [17254:0] info: lower(secs) upper(secs) recursions
May  7 17:22:19 unbound: [17254:0] info:    0.000256    0.000512 76
May  7 17:22:19 unbound: [17254:0] info:    0.001024    0.002048 5
May  7 17:22:19 unbound: [17254:0] info:    0.002048    0.004096 7
May  7 17:22:19 unbound: [17254:0] info:    0.004096    0.008192 20
May  7 17:22:19 unbound: [17254:0] info:    0.008192    0.016384 49
May  7 17:22:19 unbound: [17254:0] info:    0.016384    0.032768 122
May  7 17:22:19 unbound: [17254:0] info:    0.032768    0.065536 119
May  7 17:22:19 unbound: [17254:0] info:    0.065536    0.131072 27
May  7 17:22:19 unbound: [17254:0] info:    0.131072    0.262144 3
May  7 17:22:19 unbound: [17254:0] info:    0.262144    0.524288 2
Logged

G.DMT

  • Member
  • **
  • Posts: 76
Re: self-providing encrypted DNS
« Reply #7 on: May 09, 2016, 05:30:56 PM »

Thank you for taking the trouble to make such informative posts.   :)

Real usage data is a valuable contribution.

To see delays increased by 50% to 100% is  interesting, and could be enough to dissuade from using the notional 'double dnscrypt' configuration.

Although that may not be entirely logical in my particular circumstances - since my apallingly poor rural ADSL1 routinely returns 'bandwidth test' ping roundtrip delays in the 70s of milliseconds.   :(

Adding another straw on that camels back would probably go unnoticed!
 

« Last Edit: May 09, 2016, 05:36:09 PM by G.DMT »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7405
  • VM Gig1 - AAISP CF
Re: self-providing encrypted DNS
« Reply #8 on: May 09, 2016, 06:43:25 PM »

yeah dnssec is definitely the biggest impact on performance, dnscrypt is acceptable easily.

I am currently deciding whether to turn dnssec back on as before, or just doing dnssec lookups only on domains I know to be protected.  If dnssec is enabled for everything, then I am slowing down 99% of queries by about 200-300% for security of 1% of lookups.

I think dnscrypt is a no brainer, dnssec is what needs thinking about.

Also if your base latency is 70ms, I think the penalty is higher sadly.  As its generally a multiple of your base latency for dnssec. However dnscrypt you will probably not feel as that will be a small % of 70ms.

The reason dnssec is such a big penalty is extra lookups are required.
« Last Edit: May 09, 2016, 06:45:34 PM by Chrysalis »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7405
  • VM Gig1 - AAISP CF
Re: self-providing encrypted DNS
« Reply #9 on: May 11, 2016, 07:30:02 PM »

Interestingly I have found if the local unbound server on the router if set to not load the validate module (disabled dnssec) but forwards queries to a dnssec capable resolver (which I have done), dnssec lookups still work when specifically requested.

In my browser I have a extension loaded which checks dnssec status when browsing, and this is working in the current config without page load lag associated with extra dnssec lookups.  So I have a reasonable config right now.

Where this setup is weak is that applications that dont request dnssec checks such as pretty much every email client and browsers (without the extension) will return successful dns lookups if a dnssec zone is compromised.  But I still have my other dns hardening measures in place to make it harder for a MITM to spoof responses.  Will keep it like this for now.
Logged

G.DMT

  • Member
  • **
  • Posts: 76
Re: self-providing encrypted DNS
« Reply #10 on: May 12, 2016, 10:55:48 AM »

In my browser I have a extension loaded which checks dnssec status when browsing, and this is working in the current config without page load lag associated with extra dnssec lookups.  So I have a reasonable config right now.

That seems like a good idea, I think I might give this a try for a while.

I use Firefox as my main browser and a quick search found me these 2 browser extensions:

Web of Trust (WOT)  for Firefox and android
https://www.mywot.com/

and DNSSEC/TLSA Validator for Mozilla Firefox, IceWeasel
https://www.dnssec-validator.cz/

Perhaps you would share what browser extension you are using and any observations / hints / tips ?
 
cheers!  :)
 
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7405
  • VM Gig1 - AAISP CF
Re: self-providing encrypted DNS
« Reply #11 on: May 12, 2016, 03:11:38 PM »

I use the second which works fine in chrome, but not in firefox, but since chrome is my main browser now I didnt really put much time into fixing it on firefox.

stay away from WOT, lots of false positives, e.g. people marking a site as dangerous simply because they dont agree with the content.

Also you can specify a separate dns server to use if needed for the dnssec lookups if your main resolver isnt dnssec capable.
Logged