QNAME minimization, replacing dnsmasq with Unbound

[L-P]

Hi,

QNAME minimization (RFC 7816) is a way to resolve domain names without
having to send the full request to every authority in the chain.
ie. if you have three authorities, A knows who has .com, B .foo.com, and C
bar.foo.com, you ask A for .com, B for foo.com and C for bar.foo.com,
instead of leaking the full bar.foo.com to everyone.

I think this would be a privacy improvement and is quite cheap to implement.

dnsmasq is currently used as a DNS resolver, I propose to replace it with
Unbound as it implements QNAME minimization.

From the package description:

Unbound is a recursive-only caching DNS server which can perform DNSSEC
validation of results. It implements only a minimal amount of authoritative
service to prevent leakage to the root nameservers

FreeBSD considered it stable and secure enough to replace BIND in 2014.

Replacing dnsmasq with Unbound should be painless, migrating a live server
could be doable by downloading the unbound package before removing dnsmasq.
I don't know if such a migration should be included in Streisand as it will be
dead code as soon as gets written.

TL;DR questions:

1. QNAME minimization, yay or nay?
2. Is it worth replacing Dnsmasq ?
3. Should an automatic dnsmasq->Unbound migration be included in Streisand?

[lukastribus]

Dnsmasq is a stub resolver, so QNAME minimization doesn't make sense.
QNAME minimization makes sense for full recursive servers, like Unbound or BIND.

The real question is: are you suggesting to move away from a stub resolver (querying other recursive servers) to a full recurser (querying only authoritative DNS servers)?

And no, I don't think the migration from a stub resolver to a full recurser is as painless as you are suggesting (think firewall policies, outgoing query load, etc).

Also see:
https://bugs.lede-project.org/index.php?do=details&task_id=747

[L-P]

are you suggesting to move away from a stub resolve

Yes, for four reasons:

1. Privacy: all DNS requests are going through Google right now (cf.
   playbooks/group_vars/all), this is not ideal.
2. Censorship: in some countries (eg. France) providers are required to filter
   and censor DNS requests, Google is well-known for enabling censorship
   so they probably comply with these government requests.
3. Performance: Google DNS are slow in an unpredictable way. See the green part
   of this graph. At the end of week 7 I replaced the default resolver
   (probably dnsmasq) that pointed to 8.8.8.8 with unbound.
4. QNAME minimization.

[lukastribus]

Regarding censorship, I have never seen Google censoring on their public resolvers and regarding the performance issue, you would have to elaborate on how/what you are actually measuring; but in general I agree that streisand is not the kind of project that should rely on (any) external resolvers.

[L-P]

I'm measuring the time elapsed between DNSStart and DNSDone in a go HTTP ClientTrace (actual code).

Go contacts the resolver in /etc/resolv.conf directly (src):

openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
close(3)                                = 0
socket(PF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
write(3, "\31!\1\0\0\1\0\0\0\0\0\0\7example\3com\0\0\34\0\1", 29) = 29

[cpu]

Closing in favour of StreisandEffect/discussions#12

Edit: Apologies - put the wrong URL there initially.