[Dnsmasq-discuss] Enable bogus-priv by default

Discussion:

Kevin Darbyshire-Bryant

2015-10-19 13:16:06 UTC

Hi Simon & list,

Ok, here's the controversial idea. Can we consider enabling
'bogus-priv' by default and have an additional option say 'allow-priv'
to now disable?

My feeling is that not forwarding 'link-local' type requests upstream by
default is a cleaner way of having things configured. Bearing in mind
the popularity of dnsmasq in all sorts of devices (Internet of Things) a
'be kind to your upstream servers and don't ask daft questions' default
should at least be considered.

I'm sure the flaws in my idea, logic and thinking will now be loudly
explained :-)

Kind regards,

Kevin

Eric Luehrsen

2015-10-20 00:21:48 UTC

Permalink

Kevin,

I don't think there is a flaw in your logic. You are probably 50% right.
DNSMASQ is so flexible and useful it has found two significant homes and
a bunch of other neat uses.

Top however, (1) as a single point entry router caching DNS
(ex 192.168.1.1 / X.X.X.X -> 8.8.4.4), and (2) as a local machine
name cache daemon (ex 127.0.1.1 / 192.168.1.2 -> 192.168.1.1).
For use (1) your default concept is quite right to avoid harassing the
world net and not enumerate your internal system to the world. For (2)
rather, the workstation will need to forward otherwise useless requests
up to the router to resolve local. So thats going to be your 50% split.

So I would recommend that both options be included in the CONF syntax.
I would then recommend that the default behavior be a conditional
compile for the distribution builder. In a Debian-Linux workstation
distr. the default is to forward. In a OpenWRT distr. the default is
to not forward bogus local ... something like that.

Eric

Post by Kevin Darbyshire-Bryant
Hi Simon & list,
Ok, here's the controversial idea. Can we consider enabling
'bogus-priv' by default and have an additional option say 'allow-priv'
to now disable?
My feeling is that not forwarding 'link-local' type requests upstream by
default is a cleaner way of having things configured. Bearing in mind
the popularity of dnsmasq in all sorts of devices (Internet of Things) a
'be kind to your upstream servers and don't ask daft questions' default
should at least be considered.
I'm sure the flaws in my idea, logic and thinking will now be loudly
explained :-)
Kind regards,
Kevin

Simon Kelley

2015-10-20 20:35:45 UTC

Permalink

To add to the list of canonical uses for dnsmasq: DHCP and DNS services
to VMs and containers in things like OpenStack. These typically use
RFC1918 addresses (there's no point in being able to spin a new VM in
seconds if you have to go buy it a real IPv4 address on the black market
first.....) so that's another argument against.

I think that the "principle of least surprise" would stop me from
_changing_ the default, even if I was convinced that the current choice
is the wrong one. It's much too late to change.

Actually, this isn't something that the code author needs to decide:
Vanishingly few people install dnsmasq from source. It's a choice for
the packager. That doesn't get me off the hook, since I package dnsmasq
for Debian (and therefore Ubuntu, too). I note, for instance that

--local-service

defaults OFF in the dnsmasq code, but is defaulted ON in new Debian
installations until explicitly turned off. The same could apply to
bogus-priv.

Of course that means the Kevin has far more people who he needs to
convince to act........

Cheers,

Simon.

Post by Eric Luehrsen
Kevin,
I don't think there is a flaw in your logic. You are probably 50% right.
DNSMASQ is so flexible and useful it has found two significant homes and
a bunch of other neat uses.
Top however, (1) as a single point entry router caching DNS
(ex 192.168.1.1 / X.X.X.X -> 8.8.4.4), and (2) as a local machine
name cache daemon (ex 127.0.1.1 / 192.168.1.2 -> 192.168.1.1).
For use (1) your default concept is quite right to avoid harassing the
world net and not enumerate your internal system to the world. For (2)
rather, the workstation will need to forward otherwise useless requests
up to the router to resolve local. So thats going to be your 50% split.
So I would recommend that both options be included in the CONF syntax.
I would then recommend that the default behavior be a conditional
compile for the distribution builder. In a Debian-Linux workstation
distr. the default is to forward. In a OpenWRT distr. the default is
to not forward bogus local ... something like that.
Eric

Kevin Darbyshire-Bryant

2015-10-21 09:41:02 UTC

Permalink

Post by Simon Kelley
To add to the list of canonical uses for dnsmasq: DHCP and DNS services
to VMs and containers in things like OpenStack. These typically use
RFC1918 addresses (there's no point in being able to spin a new VM in
seconds if you have to go buy it a real IPv4 address on the black market
first.....) so that's another argument against.
I think that the "principle of least surprise" would stop me from
_changing_ the default, even if I was convinced that the current choice
is the wrong one. It's much too late to change.
Vanishingly few people install dnsmasq from source. It's a choice for
the packager. That doesn't get me off the hook, since I package dnsmasq
for Debian (and therefore Ubuntu, too). I note, for instance that
--local-service
defaults OFF in the dnsmasq code, but is defaulted ON in new Debian
installations until explicitly turned off. The same could apply to
bogus-priv.
Of course that means the Kevin has far more people who he needs to
convince to act........

I think I've had it very well explained that my viewpoint is very narrow
:-) And what's the saying about choosing battles wisely? Not this
battle. I did say controversial...and apparently only 50% silly this time.

Ideally those cheap, low margin home router manufacturers will remember
to put '--bogus-priv' in their configs.

Kevin

Matthias Andree

2015-10-24 11:11:13 UTC

Permalink

Post by Kevin Darbyshire-Bryant
Ideally those cheap, low margin home router manufacturers will remember
to put '--bogus-priv' in their configs.

The ideal fix is getting rid of junk by making it unattractive to sell
cheapo gadgets without long-term support.

Ways out would be:
- requiring all long-lived embedded things open source by law (although
the FCC seems to go opposite ways, not that it matters much)
- making sure companies selling embedded networked software sponsor
foundations and offer proper documentation such that such embedded
devices will be maintained for 15+ years

"15+ years" sounds ridiculous? My garbage "internet access device"
(phone & internet via DSL) that my phone/internet provider forces on me
(because they need not provide me with the VoIP password in Germany,
they can just embed it) is already 9+ years old. We've been discussing
this for a decade and things aren't really moving forward.