Lukas Tribus
2016-01-06 00:37:35 UTC
Hello,
back in October there was a discussion about enabling bogus-priv by
default [1].
Since I'm late to the party I can't reply directly to that thread, so
I'm creating a new one.
I want to add that there is a RFC recommendation out there regarding
this behavior, its RFC 6761 Section-6.1 [2].
What it basically recommends is what Kevin proposed here: default
to bogus-priv by default; but that's not all, it also recommends that:
test
localhost
invalid
are treated as local domains (not forwarded to upstream resolvers).
There is also RFC 6762 [3], which recommends treating the following
domains local as well:
local
254.169.in-addr.arpa (already covered in bogus-priv)
8.e.f.ip6.arpa
9.e.f.ip6.arpa
a.e.f.ip6.arpa
b.e.f.ip6.arpa
Also RFC 7686 was approved a few months ago declaring onion a local
domain [4] (a private domain within the TOR network, that must not
be leaked to non-TOR aware resolvers). This is already in unbound
for example [5].
So the configuration covering all those recommendations (and thus,
avoid leaking private/local data) would look like this:
#rfc6761#section-6.1
bogus-priv
#rfc6761#section-6.2
local=/test/
#rfc6761#section-6.3
local=/localhost/
#rfc6761#section-6.4
local=/invalid/
#rfc6762#section-22
local=/local/
local=/8.e.f.ip6.arpa/
local=/9.e.f.ip6.arpa/
local=/a.e.f.ip6.arpa/
local=/b.e.f.ip6.arpa/
#rfc7686#section-2
local=/onion/
That's 9 additional configuration directives (other than bogus-priv) to
avoid leaking private data upstream. I don't think its realistic to
expect the package maintainers to handle and maintain all those
configurations.
Not every repository/distribution has the luxury of having a DNS expert
as dnsmasq maintainer.
A few questions about this:
I understand we can't break existing setups by enabling bogus-priv by
default, but would this be acceptable in a new major release - like 3.0
(or never ever)? I guess we would probably want an option to re-enable
specific domains, instead of unconditionally enabling them all.
Would it be acceptable for the private zones mentioned above (that aren't
covered by bogus-priv) to get blocked by default (forward and v6 reverse
zones)?
What would a simple yet extensible approach to implement RFC 7686 in dnsmasq
look like (like installing a static list of local domains and giving the
user the possibility to unblock domains)?
Unbound for example uses the blocked-by-default approach suggested by the
RFCs [6] (see directives unblock-lan-zones and local-zone).
In case none of this is acceptable, would you accept patches against manpage
and dnsmasq.conf.example that explain the issue and provide configuration
example?
Perhaps I should mention what the onion domain block is about: suppose a
journalist is trying to setup TOR but fails to do it correctly. When he's
trying to connect to a TOR hidden service (which uses the onion domain),
not only is the destination (onion) domain leaked to its adversaries (so
they know about the hidden service in the first place), they will also
have the real source-IP and timestamp of the request.
That's the background of RFC 7686 (more about this at [7]).
Regards,
Lukas
[1] https://www.mail-archive.com/dnsmasq-***@lists.thekelleys.org.uk/msg09898.html
[2] https://tools.ietf.org/html/rfc6761#section-6.1
[3] https://tools.ietf.org/html/rfc6762#section-22
[4] https://tools.ietf.org/html/rfc7686#section-2
[5] https://github.com/jedisct1/unbound/commit/ac5750617faaddbe037fc43a8b45d2845725ce34
[6] https://unbound.nlnetlabs.nl/documentation/unbound.conf.html
[7] https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think
back in October there was a discussion about enabling bogus-priv by
default [1].
Since I'm late to the party I can't reply directly to that thread, so
I'm creating a new one.
I want to add that there is a RFC recommendation out there regarding
this behavior, its RFC 6761 Section-6.1 [2].
What it basically recommends is what Kevin proposed here: default
to bogus-priv by default; but that's not all, it also recommends that:
test
localhost
invalid
are treated as local domains (not forwarded to upstream resolvers).
There is also RFC 6762 [3], which recommends treating the following
domains local as well:
local
254.169.in-addr.arpa (already covered in bogus-priv)
8.e.f.ip6.arpa
9.e.f.ip6.arpa
a.e.f.ip6.arpa
b.e.f.ip6.arpa
Also RFC 7686 was approved a few months ago declaring onion a local
domain [4] (a private domain within the TOR network, that must not
be leaked to non-TOR aware resolvers). This is already in unbound
for example [5].
So the configuration covering all those recommendations (and thus,
avoid leaking private/local data) would look like this:
#rfc6761#section-6.1
bogus-priv
#rfc6761#section-6.2
local=/test/
#rfc6761#section-6.3
local=/localhost/
#rfc6761#section-6.4
local=/invalid/
#rfc6762#section-22
local=/local/
local=/8.e.f.ip6.arpa/
local=/9.e.f.ip6.arpa/
local=/a.e.f.ip6.arpa/
local=/b.e.f.ip6.arpa/
#rfc7686#section-2
local=/onion/
That's 9 additional configuration directives (other than bogus-priv) to
avoid leaking private data upstream. I don't think its realistic to
expect the package maintainers to handle and maintain all those
configurations.
Not every repository/distribution has the luxury of having a DNS expert
as dnsmasq maintainer.
A few questions about this:
I understand we can't break existing setups by enabling bogus-priv by
default, but would this be acceptable in a new major release - like 3.0
(or never ever)? I guess we would probably want an option to re-enable
specific domains, instead of unconditionally enabling them all.
Would it be acceptable for the private zones mentioned above (that aren't
covered by bogus-priv) to get blocked by default (forward and v6 reverse
zones)?
What would a simple yet extensible approach to implement RFC 7686 in dnsmasq
look like (like installing a static list of local domains and giving the
user the possibility to unblock domains)?
Unbound for example uses the blocked-by-default approach suggested by the
RFCs [6] (see directives unblock-lan-zones and local-zone).
In case none of this is acceptable, would you accept patches against manpage
and dnsmasq.conf.example that explain the issue and provide configuration
example?
Perhaps I should mention what the onion domain block is about: suppose a
journalist is trying to setup TOR but fails to do it correctly. When he's
trying to connect to a TOR hidden service (which uses the onion domain),
not only is the destination (onion) domain leaked to its adversaries (so
they know about the hidden service in the first place), they will also
have the real source-IP and timestamp of the request.
That's the background of RFC 7686 (more about this at [7]).
Regards,
Lukas
[1] https://www.mail-archive.com/dnsmasq-***@lists.thekelleys.org.uk/msg09898.html
[2] https://tools.ietf.org/html/rfc6761#section-6.1
[3] https://tools.ietf.org/html/rfc6762#section-22
[4] https://tools.ietf.org/html/rfc7686#section-2
[5] https://github.com/jedisct1/unbound/commit/ac5750617faaddbe037fc43a8b45d2845725ce34
[6] https://unbound.nlnetlabs.nl/documentation/unbound.conf.html
[7] https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think