History

DNSCrypt Poland was born in October 2013. At the time it was the first and only service in Europe. It started as a fun mini-project for me to encrypt my own traffic, but shortly after I created a quick Wordpress blog to provide service announcements, put up my face and contact details to build trust. I've seen traffic increasing, seeing more demand for RAM for unbound cache and hungry namecoind daemon. There were ups & down, moments when lack of finance got in the way and I asked for support. I got it and used it all up for hosting, domains and website, doing 100% of what I could myself.

Mid-game

I even published some financial statements but quickly after Q1 2017 I couldn't have spent that much time on maintaining the service. It was set up well and I didn't have to touch it for months. I've had an uptime of more than 600 days twice!

Later the service has gotten very quirky. The Debian distribution got far behind easily updateable, unbound daemon started acting up and crashing every now and then, causing weird outages when systemd was restarting it. Some outages were due to dnscrypt-proxy suddenly segfaulting. A bug I never managed to debug due to -ENOTIME.

End-game & reboot!

This meant an overhaul of the service was long overdue. I worked on this in the last couple of months and here it is!

• Same data-centre, new server, current OS (Ubuntu 20.04 LTS)
• 2 service tiers: one with no-filtering, vanilla DNS experience and one with pure malware and phishing blocklists
• Same but current unbound, but blocklists are not unbound zones
• encrypted-dns-server replaced dnscrypt-wrapper
• blocklists are documented on github and easy to check what they block, what's the source and how many domains are there. Update script is shared.
• same vnstati traffic charts, but also new prometheus/grafana charting, see Performance page.
• Ghost has replaced Wordpress
• Dogfooding of this is extensive: all my family's mobile devices are using it, as well as home network directs all traffic to pihole which excelusively uses dnscrypt.pl-guardian

I put much faith in this setup and I encourage everybody to test it out, make the switch, ditch the old one and contact me for whatever reason you like.

One more thing

I'm thinking of deploy more extensive blocklists, perhaps a paid service, not sure yet, I need to figure it out. Since mid-2017 I've had no external funding and I'm trying to run a smooth and efficient fleet here. I hope I can bring good quality and, as I always wanted, grow the service to host another server in Warsaw.

In a nutshell my recommendations are the following:

• Windows: https://simplednscrypt.org/
• iOS: https://itunes.apple.com/us/app/dnscloak-dnscrypt-client/id1452162351
• Android: Haven't tried any of them but RethinkDNS and TrustDNS seem all right.
• OpenWRT: the new dnscrypt-proxy2 package like in these instructions. You can configure the /etc/dnscrypt-proxy2/dnscrypt-proxy.toml file later.
• Home networks. If you don't want or don't have pihole, pick dnscrypt-proxy for your platform and install it: Releases · DNSCrypt/dnscrypt-proxy (github.com)
• If you do have a pihole, do the same. One example instruction is here: DNS with Pi-Hole + DNSCrypt (sean-wright.com)

Service comparison

Addresses and ports

| Service | DNS | Address:Port | Provider Name |
|-------------|:------:|:-------------:|:-------------:|:-------------:|
| dnscrypt.pl | poz1.dnscrypt.pl | 178.216.201.128:2053 | 2.dnscrypt-cert.dnscrypt.pl |
| dnscrypt.pl-guardian | poz1.dnscrypt.pl | 178.216.201.128:2054 | 2.dnscrypt-cert.dnscrypt.pl |
| soltysiak | dc1.soltysiak.com | 178.216.201.222:2053 | 2.dnscrypt-cert.soltysiak.com |

Public Key for poz1.dnscrypt.pl

7F61:7CB8:1EA5:53D2:34C4:9BC2:79C7:4F7B:5498:050D:1DBF:111A:FEE6:9963:C647:A169

Public Key for soltysak.com

25C4:E188:2915:4697:8F9C:2BBD:B6A7:AFA4:01ED:A051:0508:5D53:03E7:1928:C066:8F21

Before you go have a look, let me express my thanks to everybody who supported this service. I traditionally do not say any names, but you all know who you are and so please accept thanks on behalf of all the users.

The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.

First fact is that dnscrypt-proxy will warn if the certificate expiry is more than 24h (86400 seconds) from now. This is value is hardcoded as CERT_RECOMMENDED_MAX_KEY_ROTATION_PERIOD. The reasoning is that if the certificate is long lived it is easier for an adversary to record DNSCrypt traffic, crack or obtain the secret key material and ultimately decrypt your traffic. This means that the gain from that is limited to the lifetime of the certificate, therefore it’s best to limit exposure in worst case to a much smaller, yet, still reasonable time span. Sadly, dnscrypt-wrapper by default generates certificate for 360 days.

Anyway, the guidance for dnscrypt-proxy service maintainers is as follows:

1. When generating your cert file use –cert-file-expire-days=1
2. Run your daemons, but automate rotation of keys using a script. There is a very handy script in the docker image:
   https://github.com/jedisct1/dnscrypt-server-docker/blob/master/dnscrypt-wrapper.sh
3. Ensuring the paths are correct, I invoke the above script from another script I have which find out the PIDs of all running dnscrypt-proxy daemons, starts the wrapper, and when that is done, kills the previous daemons.

cd /opt/dnscrypt-wrapper/sbin pids=`ps ax|egrep "dnscrypt-wrapper.*provider-name" | grep -v grep | awk ' { print $1 }'` echo Starting a new Wrapper ./dnscrypt-wrapper.sh echo Sleeping sleep 6 echo Killing if [ "$pids" != "" ]; then kill -9 $pids echo Done! Result: $? else echo Done! Starting fi

The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.

Although it’s fine for the service to work and many other dnscrypt providers have long expiry too, the warning is a valid concern. I decided to change this behavior in DNSCrypt Poland.

We used to have a key valid for 5 years; starting today we now use keys rotating every 24 hours.

In a hypothetical case where the secret key was compromised by an adversary it would be possible to decrypt previously captured traffic. Now, the forward secrecy is better as the keys change frequently.

I suspect no issues, but as usual, please give me a shout on twitter or drop me a line if you encounter any issues.

Long Story

When DNSCrypt Poland was first established in 2013 it had a 1-year certificate. Close to the first expiry I recognized a problem of performing a smooth cutover to a new certificate. I contributed SO_REUSEPORT to dnscrypt-wrapper and libevent which allows to run many instances of dnscrypt-wrapper: one with the old and one with the new certificate.

Being lazy busy though, the next certificate I generated was a 5-year one. For it to work I contributed another patch and that allowed me to sleep tight for 3 years now.

Having changed the scheme to rotate every 24 hours, I can sleep ever better now :)

Technical Detail

Before:

• dnscrypt-wrapper instance is using manually generated keys and certificate

After:

• A new key is generated every 12 hours
• dnscrypt-wrapper picks up new keys and handles requests encrypted with old and new keys
• old keys are deleted

This means at any moment in time we have 2 keys generated within last 12 hours; after 24 hours there is a completely new set of keys. This allows to have key overlap for clients to continue working without glitches during the time they will retry if they are unable to fetch the certificate.

Often I do not have the means to thank (bitcoin) or it’s awkard to thank (does it make sense to send back 0.01 with a thank you note to a wire transfer?), so here it is,

the 2016 Financial Report for DNSCrypt Poland.

Feel free to ask questions or point out anything I might’ve missed.

Due to a sorry state of my budget constraints for DNSCrypt and close to non-existing donations and paypal shutting down, I’ve decided to lower to the memory from 2GB to 1GB on the VM. This will cause lower cache hit ratio, but still allow to operate while achieving 43% lower monthly cost. Sorry :-(

• Zagraniczni inwestorzy (tj. kanadyjsckie i amerykańskie firmy) otrzymają prawo pozywania o odszkodowanie jeśli uznają, że doznały strat z powododu prawa lub środków prawnych Unii Europejskiej lub poszczególnych krajów członkowskich. Dotyczy to także praw, które powstały dla dobra wspólnego, np. prawa środowiskowe czy ochrony konsumentów. To nazwano ISDS – Investor-State-Dispute-Settlement i jest w istocie prywatnym procesem pozywania państw za realizowanie ich suwerrenego prawa do stanowienia prawa.

• Grupy firm mają być włączone w proces tworzenia nowego prawa i regulacji jeśli wpływałyby one na ich interesy. To nazwano regulatory cooperation i oznacza, że reprezentanci ogromnych firm będą miały wpływ na kształt prawa, zanim będzie ono podlegać dyskusji przez wybieralne parlamenty. To podburza demokrację!
• Ogromne firmy miały i nadal mają nadmierny wpływ na tajne negocjacje związane z CETA i TTIP. Wedgłu oficjalnych informacji w samej fazie przygotowawczej dla TTIP miało miejsce ponad 590 spotkań między Komisją Europejską a reprezentantami lobby. 92% z tych spotkań było z przedstawicielami firm, podczas gdy tylko 8% to były dyskusje z przedstawicielami konsumentów czy związków zawodowych. Także podczas tych negocjacji reprezentanci przemysłu wywierali znaczący wpływ. Niektóre sformułowania w szkicach tekstów, które ujrzały światło dzienne wyszły bezpośrednio spod piór przemysłowych lobbystów.
• Negocjacje prowadzone są potajemnie. Nawet nasi publiczni reprezentanci wiedzą niewiele o postępach. Otrzymują oni rezultaty prac w formie długich tekstów uzgodnień (np. CETA ma 1500 stron!) i tylko po zakończeniu negocjacji zatem mają wyłącznie możliwość przyjęcia lub odrzucenia całości tekstu bez możliwości sugerowania poprawek.
• Prawa pracowników są pod naciskiem i wiele miejsc pracy w rozlicznych gałęziach przemysłu. W USA formalnie uznawane jest tylko kilka rodzajów praw pracowniczych (tylko 2 z 8 standardów pracowniczych ILO – International Labour Organisation). W rolnictwie i przemyśle elektrycznym mogą mieć miejsce bardzo duże utraty miejsc pracy z powodu większej konkurencji z zagranicy.
• Liberalizacja i prywatyzacja są proponowane wyłącznie jako jednokierunkowe rozwiązania. Powrót organizacji użyteczności publicznej takich jak szpitale czy odbiór odpadów do sektora publicznego po tym jak zostałyby sprywatyzowane stałoby się jeszcze trudniej lub nawet niemożliwe dzięki CETA i TTIP.
• Na Unię Europejską i jej kraje członkowskie jest wywierana presja aby dopuścić ryzykowane technologię take jak fracking (szczelinowanie hydrauliczne – metoda wydobycia gazu łupkowego) czy technologie modyfikacji genetycznych.
• Standardy żywnościowe i ochrona konsumenta produktów kosmetycznych i medycznych może być ustalona na takich samych poziomach jak amerykańskie. Problem w tym, że potrzebujemy wyższych standardów a nie niższych i słabszej ochrony czy to dotyczy stosowania pestycydów, hodowli przemysłowych czy czystych źródel energii. Regulatory cooperation i ISDS uczyniłoby to trudniejszym lub niemożliwym.

CETA i TTIP to umowy, których zamiarem jest zwiększenie siły ponadnarodowych biznesów na koszt demokracji i dobra ogólnego. Nie możemy do tego dopuścić. Dlatego podpisałem Inicjatywę Obywateli Europejskich (European Citizens’ Initiative) i do tego, w obliczu powyższego, bardzo gorąco zachęcam Ciebie i wszystkich użytkowników DNSCrypt Poland.

Razem możemy powstrzymać TTIP i CETA!

Link do inicjatywy:

* PL – http://stop-ttip.pl/

* EN – https://stop-ttip.org/

• feasibility of crowdfunding campaigns like kickstarter, patreon, polakpotrafi
• alternatives to paypal for international donations
• setting up a foundation
• or, I don’t know, inherit milions and win the lottery ;-)

Big thanks to everybody!

1. Usage is going up – we’re pushing now around 7 GB/day
2. RAM went up with the recent upgrade
3. Cache Hit Ratio went up from around 42% to 78%
4. Sadly, running cost went up because of traffic used (1) and costlier VM option (2)

Roughly: Double the RAM means double the cost. Plus some (minor) extra on all traffic beyond 50GB / month.

For transparency – as usual – I’ve updated the costs on the “support us” page.

Happy resolving!

Planned Outage

Our hosting provider (e24cloud.com) notified us that they will be doing maintenance which will affect the availability of our underlying storage:

• Start: 22-MAR-2015, 00:30 CET (+01:00 UTC)
• Finish: 22-MAR-2015, 01:30 CET (+01:00 UTC)

Although this does not affect the DNSCrypt VM guest itself I doubt we will be able to function for long without storage during that time. If this timing will affect you, please switch to another DNSCrypt provider ahead of 22-MAR-2015 for continuity. If not, you can sleep calmly.

RAM Upgrade

Since there has been an increase in load and this means outage anyway, I’m going to take this opportunity and double the RAM on the server to maintain more records in the DNS Cache, have higher hit ratios and provide a better service. This will increase the running cost, but it’s all for you. If you appreciate it and want to chip in, please donate!

I will be informing on progress on all above on twitter, so please check there: @dnscryptpl

It adds cache size statistics which otherwise you would have to get by dumping the cache. That, however, blocks the resolving for the time it takes to produce the dump and would not acceptable to be run periodically on a large cache. This is where my patch steps in and provides the values free of charge :-)

I’m going to upgrade to 1.5.0 as soon as possible and use those additional statistics on the Performance page.