Local DNS DoT “upgrade”

First of all: This seems to be my first blogpost since 2014. Partially because of time constraints and also because what to tell πŸ˜‰ Let’s see if the frequency stays at one post per 7 years.

Just a quick overview of my local DNS setup at home as it was for some years until yesterday:

  • I’m running a Synology Diskstation as network storage as well as a kind of infrastructure server for my home network because I bought it already for that purpose because of its ability to run Docker containers in addition to the normal DSM software and services. A network storage was a basic requirement (I had one for many years before) and because this has to run anyway 24×7 I was looking for a possibility to run as many things as possible on it to not require yet another power consuming device. Others run one or more Raspis but when it comes to disk usage and activity that one is not the best choice I think.
  • On the Synology I already had running a pi-hole docker container for quite some time to provide a network wide malware (and yes, also tracking and advertisement) filter. That one is running on a macvlan Docker network because otherwise pi-hole would not recognize the different devices/IPs. As the Synology Docker implementation is rather limited in the UI but provides also docker-compose via shell access this setup is done via docker-compose.
    My DHCP server (built into my central Mikrotik router) provides the pi-hole IP as DNS server to all clients. (And BTW my outgoing firewall does filter all outgoing access to 8.8.8.8 and the other Google DNS IP. Actually I’m doing a DNAT to the pi-hole for those requests. Some clients accept it and some don’t but hey, that’s how it is.)
  • I still use my ISPs DNS resolvers as recursors for pi-hole because I more or less trust my ISP, would hope that those are closest to my Internet connection with small(est) latency and because I believe in the Internet’s decentralized architecture and want to avoid concentration of vital services into a few big players like Google and Cloudflare. Even if their policies look nice I’m not sure how much those really can be trusted. Not to forget they are US companies.

Having said this: Those services in general have a point. Probably even more in networks/countries not under the European GDPR where collecting data from DNS requests (without consent) would be QUITE illegal.
What is certainly true though is that the still common style of DNS resolution is quite behind my normal privacy expectations.

So at least as a start to address this in my own little silo I decided to go for encryption of DNS traffic. For this different possibilities exist like DoT (DNS over TLS) and DoH (DNS over HTTPS) and probably also others. As I do not see why I would need to use DoH for my home network I decided to go for DoT for now. (NB: I think DoH can be a very good technology especially when being a roadwarrior connecting to arbitrary networks with mobile devices.) (A good summary why I’m not a real DoH fan for general purpose can be found here.)

So with that idea and the fact that pi-hole itself does not support any of that and also does not have real plans to do so I went on and searched for possibilities. What you the find are some references to stubby, unbound and cloudflared. You find even some references how to integrate those with pi-hole but all informations I found are about pi-hole on a Raspi where you can easily install an additional service but very few hints about how to do it in a Docker setup.

stubby

I decided to go for stubby as I heard good things about it and I didn’t need a full recursor like unbound and as I already indicated cloudflared was already out even when it was just from its name and origins.

So it was clear that I need a second container to run stubby while it might have been possible to load stubby into the pi-hole docker container with some effort I wanted to be sure that the DoT proxy is available within the whole network and not only to pi-hole. (Just because w/o a real usecase right now.)
In any case I was searching for a usable stubby container or Dockerfile to create one and ended up using https://github.com/MatthewVance/stubby-docker.git. That one looked quite ok for my usecase, I just changed the Dockerfile to the latest openssl version and the stubby configuration to the DoT servers I would like to connect to. In my case I used one provided by my ISP (which is only semi-official right now but hopefully becomes fully official at some point) and also Quad9’s. This is also some sort of central but at least somewhat more trustable than the other big guys.

Then I quickly learned that connecting a Docker container running on a macvlan network is not able to reach its Docker host network which was a blocking issue until I found a solution. There was some sort of workaround mentioned somewhere in the wide Internet which was something around creating another macvlan bridge on the host to be able to communicate but I was afraid of doing that on the Synology. No idea how flexible DSM would be around such a manual thing.

So what I tried next to solve the Docker host connectivity issue was to add a second network to the pi-hole container (I’ve chosen the default bridge in the beginning) to be able to communicate with the stubby container on the same network. Now, what to say. I wasn’t able to find any reliable way to make sure that pi-hole would set up eth0 on the macvlan and ethX on the other network. Whatever I tried (docker-compose network priority) ended up with macvlan NOT on eth0. For whatever reason I do not yet understand. Still pi-hole can be configured to listen on all interfaces which is not exactly what I wanted but as a workaround that turned out be good enough finally.

After I got both containers connected to the same Docker network, I was facing the next issue: pi-hole expects an IP address as upstream resolver but in the Docker world you don’t care about IP addresses in most cases. Everything is automatic by default.
To solve that issue I ended up with a new specific network instead of the default bridge and a direct IP assignment for the stubby container:

services:
[...pihole...]
  stubby:
    container_name: stubby
    image: wrosenauer/stubby:latest
    hostname: dns
    ports:
      - "53:8053/udp"
    restart: unless-stopped
    networks:
      zzzdns:
        ipv4_address: 172.18.0.250

networks:
[...macvlan...]
  zzzdns:
    driver: bridge
    ipam:
      config:
        - subnet: 172.18.0.0/16
          gateway: 172.18.0.1

This setup now seems to work quite alright (as much as I can tell after a day) for me.

And I finally decided to write something up here because I do not have a huge Docker background and was searching the net for hints how a setup with pi-hole and stubby could look like (on a Docker host which is not totally flexible) and had a hard time to find good pointers. I’m not sure if someone will find this in future searching for a similar solution but at least there is a slighty better chance now πŸ˜‰

Share

Samsung Galaxy S (I9000) vs. HTC Desire

Recently I got my first Android based mobile phone (Samsung Galaxy S 9000) and shortly after another one from my employer (HTC Desire). So people asked me to write up some comparison and here we go:

Both phones are still running on Android 2.1. No official updates to 2.2 available yet from T-Mobile for Desire and Samsung. HTC already released an update but the Desire is T-Mobile branded so no fun yet. Both vendors promised an update to 2.2 in September though.

Technical details (mainly where both phones differ):

HTC Desire:

  • 3,7″ 480×800 AMOLED (S-LCD in future revisions)
  • Weight: 135 g
  • 5MP camera with flashlight
  • RAM 576 MB
  • internal memory 512MB
  • microSD slot
  • Headset w/ earplugs
  • notification LED

Samsung Galaxy S:

  • 4,0″ 480×800 S-AMOLED
  • Weight: 119 g
  • 5MP camera w/o any light
  • RAM 512 MB
  • internal memory 8GB
  • microSD slot
  • Headset w/ in-ear plugs
  • no! notification LED
  • additional front camera

Hardware:

In addition to what you can see above here are some comments when it comes to real use. I would call the display the biggest advantage of the Galaxy. It’s bigger, it looks black (compared to the grey of the Desire) and it’s less reflecting than HTC’s. Fingerprints are also not that striking. The downside is that the size is pretty much at the limit what you want to control with one hand. The case of the Desire feels a bit higher quality to me mainly because it’s heavier and not glossy. The Galaxy is pretty much designed as the iPhone3. The USB connector on the Galaxy is at the top right and has a little slider to close it. The HTC’s connector is at the bottom centric and it looks much more likely that there will be car kits or other cradles what I pretty much doubt for the Galaxy because of the connector’s position. As you can see above the difference in memory capacity is pretty stunning. The internal memory compares between 512MB and 8GB. On the memory side there is also to mention that you can replace the microSD card in the Galaxy while the phone is powered on what you cannot do with the Desire as the battery has to be removed to access the slot. The thing what I miss most on the Galaxy is a the LED to see if there are any new notifications.

Software:

Both handsets are coming with a similar set of preinstalled applications. HTC ships a home screen extension named HTC Sense which is similar to the design they ship with their Windows Mobile devices and looks appealing (at least) to me. (I like their animated weather applet ;-)). Samsung has another design and other included widgets. The main set of apps is quite different. They seem to have different EMail, Calendar, ActiveSync, Music components for example. (I have no idea if any of these is the original Android default application.) The Samsung EMail app has some usability issues as they list the IMAP folders at the top side by side and shorten the folder name. So I end up seeing something like “INBOX/Archi|INBOX/Arch|INBOX/Arch” at the top because I have subfolders under INBOX/Archive. Apparently more than one sublevel is not really usable. Samsung ships an application called AllShare which is basically a full? DNLA framework . I haven’t found such a feature on the HTC. But then again the Desire comes with a backup feature which can save stuff to the microSD card. The Galaxy lacks a built in backup feature. General responsiveness of the phone seems to be better on the Desire. For whatever reason I sometimes get lagging in the UI animations and application startups on the Galaxy for unknown reasons. I have to add that I use more apps on the Galaxy than I do on the Desire but I don’t think that’s the full truth. So I’m awaiting eagerly the arrival of the new Android 2.2 based firmware which hopefully fixes other issues as well.

Data roaming:

A short note about the general handling of data connections in Android 2.1 which is the same on both devices: For the case of roaming you can disable the use of data connections (except WiFi) completely. There is no official way to turn off data in your home network. There might be apps to do that.

Phone quality:

I cannot go into details yet because I haven’t done that many phone calls and haven’t tried the headsets for calling yet. Also I use different carriers with the phones which makes it hard to compare the right things. From my small experience I feel that the Desire has worse sound quality as I hear overdrive artifacts with it what I didn’t notice with the Galaxy. Connecting hands-free sets to both phones worked flawlessly.

This comparison is by far not complete but includes the things I found important after using both for only three weeks now.

Update:

Yesterday I’ve updated my JF3 firmware to JM1 (which is not Froyo yet) and apparently these mysterious lags are gone now from my Galaxy.

Share

Mozilla Buildservice Repository

Thanks to Matthias Koenig, Andreas Jaeger, Marcus Rueckert and Robert O’Callahan!

Because of those guys we finally got a complete Mozilla Buildservice Repository which now contains Firefox 2 (with Novell’s additions)
Therefore the repository now carries Firefox 2, pre-versions of SeaMonkey 1.1, Thunderbird 2.0 and XULRunner 1.8.1 in addition to the low-level libraries of NSPR 4.6.3 and NSS 3.11.3 for SUSE Linux 10.0, 10.1 and Factory.

Share

backlog

I’m still on vacation until wednesday but finally I’m online again πŸ˜‰

Spent some hours reading all my mails. It’s everytime a bad thing to be on vacation during beta phase and it’s even worse since openSUSE and a fully open Bugzilla.

BTW: I was in Kalifornien for dinner last week (not California but a german village at the coast to the Baltic Sea next to Brasilien. Funny thing.)

Share

It’s finally there …

As I find it sometimes very interesting to read blogs from other guys, I decided to try it out myself. Maybe someone
find it also interesting sometimes?
So I’ve searched for some weblog system to install on my server and chose WordPress for now.
So here it is and hopefully I will make some use of it πŸ˜‰

Share