[conspire] Internet Privacy: today's vote and measures to take

[Rick Moen]

Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):

> Ok dnsmasqd and unbound are working.

Yay.  I'll assume you know how to use dig (or delv[1], or nslookup) to
verify correct operation through throwing queries at stuff.

> luci (the web interface of openwrt) doesn't let you change server=
> configuration option. Fortunately luci doesn't mess up with
> /etc/dnsmasqd.conf but it just source it with
> 
> conf-file=/etc/dnsmasq.conf

Just to make sure I didn't mislead, I was going by vague recollection
and a couple of Web-search hits about what Dnsmasq file to tweak.  You
may notice that I said just 'dnsmasq.conf' without claiming to know
where it is -- because I'd be wrong if I said that.  ;->  Point is, 
please don't take what I wrote as a Word of God recipe details, but
rather as 'I guesstimate that something like this will work fine, or
ought to.'  (I've tested exactly nothing in that discussion, except
where I said otherwise.)

OTOH, you said 'are working'.  ;->

> Potentially I'm planning to serve up real _public_ authoritative DNS
> records.  It depends on if I'll be able to get a/some static IP and a
> fatter upstream.

Realistically speaking for most Internet domains' authoritative DNS in
most situations, it's not even necessary to have gigabit ethernet ports
in order to avoid being bottlenecked on bandwidth.  (Of course, all
halfway modern x86_64 hosts do have that, so great, and it's nice to
have that with no extra effort.)  Basically, DNS is not a
bandwidth-intensive protocol, usually -- at least, it never was for any
of the businesses' auth nameservers I've managed in the past.  And you
really never hear about authoritative nameservers choking on CPU
overload or being driven into swap.  Extreme edge cases like the
nameservers for a popular TLD possibly differ, dunno.



> openwrt kernels are reasonably well maintained.

Good to know.

This is my being stubbornly careful, but:  When commodity ARM SoCs can
run the kernel.org armhf (etc.) kernel, though, that's the day I'll no
longer rule them out for Internet-facing or security-sensitive
deployments.  (The fact that each ARM board needs a special-snowflake
bootloader is also something that gives me pause.)

Seems to me that the cost advantage of RPi isn't compelling enough, 
and also commodity x86_64 is pretty darned cheap.

[snip point about storage as differentiator]

> On the other hand if I don't need storage I'm looking for a router.
> In the SOHO segment is not worth to DIY, just go with openwrt.

For a dedicated router, absolutely a reasonable choice.

> I'm looking around for something more powerful but still the best
> option seems some kind of x86 board from pc-engines.

You've pointed to these before, and they look really good.

> If I'll really set up a publicly exposed authoritative DNS some kind
> of containerization would come handy and I'm worried performance
> will be terrible on ARM.

Agreed.  Based on what I know of the current state of the product space, 
I'd consider ARM too risky as to performance and too funky about
software support to bet a key production service on.  Something very
standard and very fungible seems a much better bet.

Those mini-ITX motherboards of PC-Engine's have all the right design
elements and the right balance of capabilities to do many single-role
server functions, notably medium-capacity router, medium-capacity
firewall, or authoritative DNS nameserver.  (Obviously, their best
model, APU2, topping out at 4GB would disqualify it from running a big
Oracle RDBMS server.  ;->  )


[1] http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/man.delv.html
It's the new shiny toy with the best DNSSEC support, and so we're all
supposed to switch to it, etc., etc.