[Dnssec-trigger] patch to fix the dnssec-trigger fallback issue

[Paul Wouters]

On Thu, 14 Aug 2014, Pavel Simerda wrote:

>>> Are you saying that it is bad to *have* this option or that it is bad to
>>> *choose* this option for your installation?
>>
>> That's the same thing. Offering unwise options to users is bad, because
>> they will end up using it.
>
> Do you actually advocate hardcoding configuration in C just to prevent the
> administrator from creating a configuration that you consider unwise? I would
> rather be able to configure the software to my liking even if it was just for
> testing purposes. But I agree that good defaults are a must.

You are generalising my remark. In this case, I believe offering the
user an option is a bad idea. We don't give users options for every
programming decision we have to make.

>> It's the "click to continue" soft fail.
>
> I don't think administrative configuration and "click to continue" are
> comparable in any way.

On a laptop, every user is the administrator. Calling this an
administrative configuration is somewhat misleading. I am reminded
of Linus' "add printer" rant on user vs administrator decision.
You are talking about an enduser decision here. Most endusers are sadly
driven by "continue continue continue" syndrome, and following the
endusers desire would lead to all security systems always failing
soft/open.

> Why would you have that impression? I'm just not entirely happy about the
> messy configuration where you have to use "off" for "full recursion" and
> "127.0.0.127" for "off" (or empty list, no recursion). But I see that it
> technically works and I can live with it if it's too late to change it
> to something more sane.

I tried using some unbound-control options to turn it "off" but those
options are either ignored (without error) or unsettable. I tried:

sudo unbound-control set_option do-ip4: no
sudo unbound-control set_option do-ip6: no

sudo unbound-control set_option do-udp: no
sudo unbound-control set_option do-tcp: no

sudo unbound-control set_option access-control: 0.0.0.0/0 refuse

Perhaps that's something that could be fixed so the 127.0.0.127 hack
would no longer be needed?


>>> resolution available and there's no reason to keep bogus configuration
>>> for the time. The user would receive failed responses faster and could
>>> still successfully query the forwarders.
>>
>> I don't understand this. What lingering bogus configuration? Your
>> definition of "successfully query the forwarders" when those are broken
>> for DNSSEC is not the same as my definition.
>
> I'm not aware of a possibility to have different definitions, here.

You want to continue querying on what i consider broken networks but you
consider acceptable networks. Clearly, we don't agree.

> That seems to be unrelated both to my question and to my concern about
> what exactly happens when *none* of the dnstcp fallbacks are reachable. I'll
> be happy if the draft gets implemented but I don't see any relation to any
> of my questions/concerns.

If none are reachable, the user should be prompted with the option to go
insecure or cache-only. If that does not happen, it is a bug. However,
as I said, don't confuse "no reachable fallback" with "fallback only
works partially because of TCP/SSL slowness".

Paul