From psimerda at redhat.com  Fri Aug  1 09:21:45 2014
From: psimerda at redhat.com (Pavel Simerda)
Date: Fri, 1 Aug 2014 05:21:45 -0400 (EDT)
Subject: [Dnssec-trigger] dnssec-trigger & autotools
In-Reply-To: <53DA1C2C.8000506@nlnetlabs.nl>
References: <2032937356.9377748.1406802000973.JavaMail.zimbra@redhat.com>
 <53DA1C2C.8000506@nlnetlabs.nl>
Message-ID: <1261767148.9628465.1406884905268.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>
> To: "Pavel Simerda" <psimerda at redhat.com>, dnssec-trigger at nlnetlabs.nl
> Cc: "Tomas Hozza" <thozza at redhat.com>
> Sent: Thursday, July 31, 2014 12:36:28 PM
> Subject: Re: dnssec-trigger & autotools
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Pavel,
> 
> On 07/31/2014 12:20 PM, Pavel Simerda wrote:
> > Hi,
> > 
> > could we modify the dnssec-trigger source tree so that it also
> > uses automake. I think it would be easier to maintain and it would
> > also help to separate a shared library that would be usable without
> > the daemon if necessary.
> 
> You can do that; but it has to work and that is hard.

May I possibly expect help with the OSX and Windows part? What about
related projects, do they use automake or not?

> I think it is likely very difficult, because of the ifdefs in the
> Makefile that we need for OSX and Windows targets and all the
> variability.  Also automake has weird version dependencies.

Yep, autotools have issues on their own but still I think the build
is easier to maintain when using both autoconf and autotools. But
I don't want to push you to something you don't want.

Cheers,

Pavel

> Best regards,
>    Wouter
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJT2hwnAAoJEJ9vHC1+BF+NyQYP/AghMwcDwCem7GvLCqzmJNyw
> N4cEuRM9ly9vhS86KdlFPy6z/9+0x7Gag5C9LbbgAPvB/FjF6JaYeI3MDj0V8gg6
> bL+n1YPbdkybRf6kq/n+sJDvGQfMYb1EEw7RTU9JqYkqj6gKv9filkQqM+7QakNz
> 8NNlcegiB61jrS4CwRLeBnvAdgdtJz08diqh1uJeZtN2LXTY1sSTOeYXtn8OPmGb
> X1VSfdC6lOxbxumazirRER4or0VmCuVTw1CQyJZ6Tvd041tKgOaSOL97yTdvFiRi
> ipBzNNcrpD43EZnWW4K7+IOGNyfFC/aqq5h/anUtvNXppJFv11Fy7KzIIfIKPNuN
> 8l6xjCRq/2CafFt6dYqnWGJag2/Ysx5YQSV5Y2pwttON4lmebVK6X1KATXyxceKC
> TtQB/5rfz0pUcHYL35EPKFnRybBIxUpkpsESqZW5rDZPcGiSVpyPkkgg79YU4TiU
> GKR4U6XyI0xFolVkTPe49yUQGfA1PEAk5CwmQxYOARqzMOtdTVh/y4mvCyJACNqi
> a8AVUIbCI+R2rMlTdDO7YSPnCrtN9mRjNfZHnkHTDX7kw+yW1+Nc0N7QOFpElQzJ
> IelpbOvkcTCJ/Dzd1xvkvgDpxQZUsRC0NPZ+ZFl66RohVEr7qW2EclfSBBv0L6IP
> rdSZak3hOfUT+A6auE0q
> =EB+/
> -----END PGP SIGNATURE-----
> 


From psimerda at redhat.com  Wed Aug 13 14:31:23 2014
From: psimerda at redhat.com (Pavel Simerda)
Date: Wed, 13 Aug 2014 10:31:23 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <1271961093.12966138.1407940140515.JavaMail.zimbra@redhat.com>
Message-ID: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>

Hi,

just found where the problem with not using the fallback configuration
was. All the details are in the Fedora bugzilla ticket[1]. I didn't do
any more extensive research but it basically seems that after planning
the direct probe we need to also plan the tcpdns probe *before* the
direct probe finishes and prevents the tcpdns one from being planned.

Pavel

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1109292
-------------- next part --------------
A non-text attachment was scrubbed...
Name: probe.patch
Type: text/x-patch
Size: 400 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/dnssec-trigger/attachments/20140813/faee6f7f/attachment.bin>

From wouter at nlnetlabs.nl  Wed Aug 13 14:57:22 2014
From: wouter at nlnetlabs.nl (W.C.A. Wijngaards)
Date: Wed, 13 Aug 2014 16:57:22 +0200
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
Message-ID: <53EB7CD2.3090105@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pavel,

On 08/13/2014 04:31 PM, Pavel Simerda wrote:
> Hi,
> 
> just found where the problem with not using the fallback 
> configuration was. All the details are in the Fedora bugzilla 
> ticket[1]. I didn't do any more extensive research but it
> basically seems that after planning the direct probe we need to
> also plan the tcpdns probe *before* the direct probe finishes and
> prevents the tcpdns one from being planned.

You seem to want dnssec-trigger to probe in a different sequence of
fallback methods?

At the design time the direct method was thought to be a better method
than using a public-recursor fallback.  The traffic on authority
servers was not considered a problem.

The bugzilla ticket is solving something which is not a bug but a
feature.  Designed in, as the order of the probes performed.

The aim for the initial design was also to reduce load on that public
resolver (hosted by us in the generic package).

The direct (direct to authority servers) method works very often.  And
when it does it is very likely to produce DNSSEC support.

Your patch also seems to have a race condition, I think, since you
spawn both the direct and the dnstcp probes at the same time.

Best regards,
   Wouter

> Pavel
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109292
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJT63zSAAoJEJ9vHC1+BF+NLI0P/1/x29/8kZv5H9hdI6VQJBvp
HjIVUZa5S/ajqLjwtPxXPoVTelwi5uLUSah+1kKc6tJA5oSMnPRuwy3xfVq1FD8J
hP136PzTs8pt/1n9gcU+LPFExWshHQUjC7CHBHgDBt8WSYVqth12aAxAJPgmjsY4
Jr+NmU4jRct/aoVn73fXNqEsJJ6lG0ByvmYETpobRhQncTX868fe0fxLMD5OjZjy
B+uWDokS4Glh2PP5V9/3SuZZBSSFf55HpsnWup5vC+Zt0xuUDpTd4J6Xl4plrJQF
dHaNUgyuiZfZd/osgnDK6PBTXlCH2mpxNo+w8qQx2+tiShmtaGXpq+Y2xQFs815I
z9ZLr6CUfTXvxjyqQKdmyPyGh3858+pLqts98pGq/02R7BbId7BndfxttWg3VnJY
O6a5HgXfbA5ogooQLY8AWgOvrp7maEYDYOfx1v7j1gSkEP4AMTga5IAC/HbBZu+O
nH2sAuuedZqYPsTT5bkApn2epedepji28M67BjYGv3YjgWza4FtrMkgwPlOG63TW
NjhpeLf6qE4MPrOW+PnJE1/mbVGIulhese5fTldjVI0ia4E3ZX0NpIRbJUpoi89s
HF66Cgv7mVogXvT4Nfnh3NHOMNRTMVSk2r2SDafesdqJqy2A48e/VgewR5jNkMgU
BNbOIR02lnHHduNGMKjB
=h46h
-----END PGP SIGNATURE-----


From thozza at redhat.com  Wed Aug 13 15:46:55 2014
From: thozza at redhat.com (Tomas Hozza)
Date: Wed, 13 Aug 2014 17:46:55 +0200
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <53EB7CD2.3090105@nlnetlabs.nl>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
Message-ID: <53EB886F.5090000@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Wouter.

On Wed 13 Aug 2014 04:57:22 PM CEST, W.C.A. Wijngaards wrote:
> Hi Pavel,
> 
> On 08/13/2014 04:31 PM, Pavel Simerda wrote:
>> Hi,
> 
>> just found where the problem with not using the fallback
>> configuration was. All the details are in the Fedora bugzilla
>> ticket[1]. I didn't do any more extensive research but it
>> basically seems that after planning the direct probe we need to
>> also plan the tcpdns probe *before* the direct probe finishes and
>> prevents the tcpdns one from being planned.
> 
> You seem to want dnssec-trigger to probe in a different sequence of
> fallback methods?
> 
> At the design time the direct method was thought to be a better method
> than using a public-recursor fallback.  The traffic on authority
> servers was not considered a problem.
> 
> The bugzilla ticket is solving something which is not a bug but a
> feature.  Designed in, as the order of the probes performed.
>
> The aim for the initial design was also to reduce load on that public
> resolver (hosted by us in the generic package).
> 
> The direct (direct to authority servers) method works very often.  And
> when it does it is very likely to produce DNSSEC support.

For some reason I thought that fall-back servers were used before the
root servers. However I can see that it is the other way around when
reading the dnssec-trigger project page.

We consider offloading root servers a good thing. I agree with you that
in this case it is more of a feature request. Maybe it could be made
configurable. We have own Fedora infrastructure, so we will not increase
the load on your servers.

The problem I see is the situation when you want to use DNS over SSL,
because full recursion is blocked. Then it would make sense to actually
try the fall-back configuration first.

However Pavel will know more, since he debugged the daemon to find the
cause in source.

> Your patch also seems to have a race condition, I think, since you
> spawn both the direct and the dnstcp probes at the same time.
> 
> Best regards,
>    Wouter
> 
>> Pavel
> 
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109292
> 
> 

Thanks.

Regards,
- -- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT64hvAAoJEMWIetUdnzwtCeUH/iLA5ZiXght/q/h9jYnguuIi
iddIrQkwyg1jbAua9okfvGQlHpUJI05TQVjEmoT/30HWpA4v5UYJUe2XFr7cKz/3
GyCbjYK3ZZn3Jf3UR1gofCRAtRLr1XM+Fp5Qa2IJgkpLuoA595S1ss/2dyJeyGNi
PTr7e1MLLOxBl9JvM/BIlvsiiy+A+sjb9EKLnc0vRgiel7wJkXOn294Bcx1W3S6R
xjzGmRGStAPFKmCiuQfthgLB5Bk6McROWqXzPR8RGGUGDfWSBErfq43ymUuoA5CV
1izvkEm7K02F9ljG9/jOORs7pLhQJs+TS7hGEWUWbCMdqx28WSDNptEFGwBqjVI=
=5P1U
-----END PGP SIGNATURE-----


From psimerda at redhat.com  Wed Aug 13 19:11:23 2014
From: psimerda at redhat.com (Pavel Simerda)
Date: Wed, 13 Aug 2014 15:11:23 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <53EB7CD2.3090105@nlnetlabs.nl>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
Message-ID: <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: "Tomas Hozza" <thozza at redhat.com>, dnssec-trigger at nlnetlabs.nl
> Sent: Wednesday, August 13, 2014 4:57:22 PM
> Subject: Re: patch to fix the dnssec-trigger fallback issue
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Pavel,
> 
> On 08/13/2014 04:31 PM, Pavel Simerda wrote:
> > Hi,
> > 
> > just found where the problem with not using the fallback
> > configuration was. All the details are in the Fedora bugzilla
> > ticket[1]. I didn't do any more extensive research but it
> > basically seems that after planning the direct probe we need to
> > also plan the tcpdns probe *before* the direct probe finishes and
> > prevents the tcpdns one from being planned.
> 
> You seem to want dnssec-trigger to probe in a different sequence of
> fallback methods?

Hi Wouter,

not really. I just wanted to use dnssec-trigger as expected and for
some reason I assumed the expected way is to prefer infrastructure
over full recursion. The bugzilla ticket was started because I failed
to test that the fallbacks work.

Given the (for me new) information that dnssec-trigger prefers full
recursion over any tcp/ssl servers, I'm now blocking packets from
UDP/TCP port 53 on the external interface using iptables. Everything
seems to work as expected now.

> At the design time the direct method was thought to be a better method
> than using a public-recursor fallback.

Sure, that won't be a problem for now and we can revisit this question
later.

> The traffic on authority servers was not considered a problem.

I don't have strong opinion on that and I probably just assume this was
a reason behind the assumed behavior. Let's ignore it for now.

> The bugzilla ticket is solving something which is not a bug but a
> feature.

To be precise, the bugzilla ticket was about a bug but one that isn't present
in the software. Let's see what evolves from it now.

> Designed in, as the order of the probes performed.

In my opinion, it would be much nicer to have an ordered list of configured
probes including the full recursion probe. That way any distribution and
user could use any probe order.

Example 1: Probe fedora infrastructure over 443, then fedora infrastructure
over 80 and then the root servers.

Example 2: Probe my own infrastructure server, no other fallbacks.

But I'm aware that it may have been easier to do it the way it is now.

And I also don't like that unbound's "forward off" has a side effect of
turning on full recursion. I would prefer if the "off" value would just
do what it says, i.e. remove all forwarders and if there was a separate
"direct" or "recursion" value/option that would turn on the full
recursion. Also in my opinion, if all probing fails, it would be better
to let unbound reject queries immediately rather than attempt a defunct
fallback.

> The aim for the initial design was also to reduce load on that public
> resolver (hosted by us in the generic package).

I see.

> The direct (direct to authority servers) method works very often.

I guess we don't have any statistics for this, or do we? Does comparison
of hotspot probing and DNS probing give any useful results?

> And when it does it is very likely to produce DNSSEC support.

Indeed.

> Your patch also seems to have a race condition, I think, since you
> spawn both the direct and the dnstcp probes at the same time.

Yes, I wasn't aware that it creates a race, it was just a simple change
to get it going and it worked for my initial testing. Looking forward
to comments on the above.

Cheers,

Pavel

> Best regards,
>    Wouter
> 
> > Pavel
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109292
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJT63zSAAoJEJ9vHC1+BF+NLI0P/1/x29/8kZv5H9hdI6VQJBvp
> HjIVUZa5S/ajqLjwtPxXPoVTelwi5uLUSah+1kKc6tJA5oSMnPRuwy3xfVq1FD8J
> hP136PzTs8pt/1n9gcU+LPFExWshHQUjC7CHBHgDBt8WSYVqth12aAxAJPgmjsY4
> Jr+NmU4jRct/aoVn73fXNqEsJJ6lG0ByvmYETpobRhQncTX868fe0fxLMD5OjZjy
> B+uWDokS4Glh2PP5V9/3SuZZBSSFf55HpsnWup5vC+Zt0xuUDpTd4J6Xl4plrJQF
> dHaNUgyuiZfZd/osgnDK6PBTXlCH2mpxNo+w8qQx2+tiShmtaGXpq+Y2xQFs815I
> z9ZLr6CUfTXvxjyqQKdmyPyGh3858+pLqts98pGq/02R7BbId7BndfxttWg3VnJY
> O6a5HgXfbA5ogooQLY8AWgOvrp7maEYDYOfx1v7j1gSkEP4AMTga5IAC/HbBZu+O
> nH2sAuuedZqYPsTT5bkApn2epedepji28M67BjYGv3YjgWza4FtrMkgwPlOG63TW
> NjhpeLf6qE4MPrOW+PnJE1/mbVGIulhese5fTldjVI0ia4E3ZX0NpIRbJUpoi89s
> HF66Cgv7mVogXvT4Nfnh3NHOMNRTMVSk2r2SDafesdqJqy2A48e/VgewR5jNkMgU
> BNbOIR02lnHHduNGMKjB
> =h46h
> -----END PGP SIGNATURE-----
> 


From paul at nohats.ca  Wed Aug 13 21:22:53 2014
From: paul at nohats.ca (Paul Wouters)
Date: Wed, 13 Aug 2014 17:22:53 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
Message-ID: <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>

On Wed, 13 Aug 2014, Pavel Simerda wrote:

> In my opinion, it would be much nicer to have an ordered list of configured
> probes including the full recursion probe. That way any distribution and
> user could use any probe order.
>
> Example 1: Probe fedora infrastructure over 443, then fedora infrastructure
> over 80 and then the root servers.

That is bad. It would leave a privacy trail on the fedora server
whenever I logon to a network where I'll never use the fedora
infrastructure. It should ONLY be probed when I have a need for it.
We avoid probing anything that's not the root or a large TLD server
in the hopes that our queries are not leaving too many fingerprints
on the net.

> Example 2: Probe my own infrastructure server, no other fallbacks.

I'm not sure how that use case is helpful to dnssec-trigger? We want to
get working DNSSEC capable resolving going. If you want to somehow only
use your infrastructure, even if it is broken, you should not use
dnssec-trigger but use NM or equivalent to configure unbound directly.

> And I also don't like that unbound's "forward off" has a side effect of
> turning on full recursion. I would prefer if the "off" value would just
> do what it says, i.e. remove all forwarders and if there was a separate
> "direct" or "recursion" value/option that would turn on the full
> recursion.

You want a state where unbound would not be allowed to forward and
not be allowed to recurse? As in be dead in the water? Can you explain
why that would be useful to a user?

> Also in my opinion, if all probing fails, it would be better
> to let unbound reject queries immediately rather than attempt a defunct
> fallback.

What is a defunct fallback? Often the TCP based fallback is slow and
results in timeouts. It is still better then rejecting everything. And
once unbound implements draft-ietf-dnsop-edns-chain-query those problems
would hopefully go away as it would only require on consistent open TCP
connection.

Paul


From psimerda at redhat.com  Thu Aug 14 07:07:00 2014
From: psimerda at redhat.com (Pavel Simerda)
Date: Thu, 14 Aug 2014 03:07:00 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
Message-ID: <1635648743.13430231.1408000020455.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Paul Wouters" <paul at nohats.ca>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>, dnssec-trigger at nlnetlabs.nl
> Sent: Wednesday, August 13, 2014 11:22:53 PM
> Subject: Re: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
> 
> On Wed, 13 Aug 2014, Pavel Simerda wrote:
> 
> > In my opinion, it would be much nicer to have an ordered list of configured
> > probes including the full recursion probe. That way any distribution and
> > user could use any probe order.
> >
> > Example 1: Probe fedora infrastructure over 443, then fedora infrastructure
> > over 80 and then the root servers.
> 
> That is bad.

Are you saying that it is bad to *have* this option or that it is bad to
*choose* this option for your installation?

> It would leave a privacy trail on the fedora server
> whenever I logon to a network where I'll never use the fedora
> infrastructure. It should ONLY be probed when I have a need for it.
> We avoid probing anything that's not the root or a large TLD server
> in the hopes that our queries are not leaving too many fingerprints
> on the net.
> 
> > Example 2: Probe my own infrastructure server, no other fallbacks.
> 
> I'm not sure how that use case is helpful to dnssec-trigger? We want to
> get working DNSSEC capable resolving going. If you want to somehow only
> use your infrastructure, even if it is broken, you should not use
> dnssec-trigger but use NM or equivalent to configure unbound directly.

It would still provide the probing and the user would get consistent user
experience. Imagine a number of own infrastructure servers instead of one,
if you think the example is too simple.

> > And I also don't like that unbound's "forward off" has a side effect of
> > turning on full recursion. I would prefer if the "off" value would just
> > do what it says, i.e. remove all forwarders and if there was a separate
> > "direct" or "recursion" value/option that would turn on the full
> > recursion.
> 
> You want a state where unbound would not be allowed to forward and
> not be allowed to recurse?

Exactly. And I'm apparently not alone as dnssec-trigger seems to already
work around this limitation by setting 127.0.0.127.

> As in be dead in the water? Can you explain why that would be useful to
> a user?

There are periods of time when there's no secure DNS service for global
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.

> > Also in my opinion, if all probing fails, it would be better
> > to let unbound reject queries immediately rather than attempt a defunct
> > fallback.
> 
> What is a defunct fallback?

A fallback that doesn't reply. I don't know what's the exact current
behavior when probing fails for all fallbacks.

> Often the TCP based fallback is slow and results in timeouts.
> It is still better then rejecting everything.

Do you propose to use a random failed fallback? Is anything similar being
done already?

> And
> once unbound implements draft-ietf-dnsop-edns-chain-query those problems
> would hopefully go away as it would only require on consistent open TCP
> connection.

Ah, that's a good news.

Cheers,

Pavel


From wouter at nlnetlabs.nl  Thu Aug 14 07:26:13 2014
From: wouter at nlnetlabs.nl (W.C.A. Wijngaards)
Date: Thu, 14 Aug 2014 09:26:13 +0200
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
Message-ID: <53EC6495.1020305@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pavel,

On 08/13/2014 09:11 PM, Pavel Simerda wrote:
> ----- Original Message -----
>> From: "W.C.A. Wijngaards" <wouter at nlnetlabs.nl> To: "Pavel
>> Simerda" <psimerda at redhat.com> Cc: "Tomas Hozza"
>> <thozza at redhat.com>, dnssec-trigger at nlnetlabs.nl Sent: Wednesday,
>> August 13, 2014 4:57:22 PM Subject: Re: patch to fix the
>> dnssec-trigger fallback issue
>> 
> Hi Pavel,
> 
> On 08/13/2014 04:31 PM, Pavel Simerda wrote:
>>>> Hi,
>>>> 
>>>> just found where the problem with not using the fallback 
>>>> configuration was. All the details are in the Fedora
>>>> bugzilla ticket[1]. I didn't do any more extensive research
>>>> but it basically seems that after planning the direct probe
>>>> we need to also plan the tcpdns probe *before* the direct
>>>> probe finishes and prevents the tcpdns one from being
>>>> planned.
> 
> You seem to want dnssec-trigger to probe in a different sequence
> of fallback methods?
> 
>> Hi Wouter,
> 
>> not really. I just wanted to use dnssec-trigger as expected and
>> for some reason I assumed the expected way is to prefer
>> infrastructure over full recursion. The bugzilla ticket was
>> started because I failed to test that the fallbacks work.

So this was confusion about the probe order.  The other stuff makes
sense now; the bug ticket can be what it wants to be.  Most of your
questions are answered by Paul.

When all probes fail, dnssec-trigger sets unbound to 127.0.0.127, or
to 'nothing', and reports to the user that there is no connectivity
("disconnected" or "DNSSEC fails" if packets got through).

Best regards,
   Wouter

>> Given the (for me new) information that dnssec-trigger prefers
>> full recursion over any tcp/ssl servers, I'm now blocking packets
>> from UDP/TCP port 53 on the external interface using iptables.
>> Everything seems to work as expected now.
> 
> At the design time the direct method was thought to be a better
> method than using a public-recursor fallback.
> 
>> Sure, that won't be a problem for now and we can revisit this
>> question later.
> 
> The traffic on authority servers was not considered a problem.
> 
>> I don't have strong opinion on that and I probably just assume
>> this was a reason behind the assumed behavior. Let's ignore it
>> for now.
> 
> The bugzilla ticket is solving something which is not a bug but a 
> feature.
> 
>> To be precise, the bugzilla ticket was about a bug but one that
>> isn't present in the software. Let's see what evolves from it
>> now.
> 
> Designed in, as the order of the probes performed.
> 
>> In my opinion, it would be much nicer to have an ordered list of
>> configured probes including the full recursion probe. That way
>> any distribution and user could use any probe order.
> 
>> Example 1: Probe fedora infrastructure over 443, then fedora
>> infrastructure over 80 and then the root servers.
> 
>> Example 2: Probe my own infrastructure server, no other
>> fallbacks.
> 
>> But I'm aware that it may have been easier to do it the way it is
>> now.
> 
>> And I also don't like that unbound's "forward off" has a side
>> effect of turning on full recursion. I would prefer if the "off"
>> value would just do what it says, i.e. remove all forwarders and
>> if there was a separate "direct" or "recursion" value/option that
>> would turn on the full recursion. Also in my opinion, if all
>> probing fails, it would be better to let unbound reject queries
>> immediately rather than attempt a defunct fallback.
> 
> The aim for the initial design was also to reduce load on that
> public resolver (hosted by us in the generic package).
> 
>> I see.
> 
> The direct (direct to authority servers) method works very often.
> 
>> I guess we don't have any statistics for this, or do we? Does
>> comparison of hotspot probing and DNS probing give any useful
>> results?
> 
> And when it does it is very likely to produce DNSSEC support.
> 
>> Indeed.
> 
> Your patch also seems to have a race condition, I think, since you 
> spawn both the direct and the dnstcp probes at the same time.
> 
>> Yes, I wasn't aware that it creates a race, it was just a simple
>> change to get it going and it worked for my initial testing.
>> Looking forward to comments on the above.
> 
>> Cheers,
> 
>> Pavel
> 
> Best regards, Wouter
> 
>>>> Pavel
>>>> 
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109292
>>>> 
> 
>> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT7GSRAAoJEJ9vHC1+BF+Ns3gP/RRuIECXk/Z801CYKhhsXNvw
5x1uZA8UERF0wr8oreQSJsYRtaJFk6c902Q3vDyp1sJ5eOctMf1Q7wwfbDtDLIpv
JtTcv5a1u0dazbk3Guh80SluqD0tZOpssgZQZdSt6Vt7ahDlubRHqERfHCWPr1Lj
ZMnUPngEph5jEaAMC3byojWpvTcKxxhTYNIPpAsfln8eUfzkSfsI6+w8l6PSNdS4
MVleK2qAt7KBlzzDXgr3O/zoKhcfuImzVKrLhfAgYBiZT7yXfRQwck/xA2sJGLKZ
2saZdzzpnostC/X3QwzasGwDdytChnjbTeTzwwIEcySB3zpLJ4p9kHw52MoOACVH
TUMgz3M5mlSiIuiUvkfa1XDn0RixakPz0xeFIWEvN6dgtZlqp+7/d4rgtbhz1b+H
sbuf+UAnNN9cn/BRT8WCGmPhB1cnMLLxBOhON5KxJd0Q/uPdwWQMFvuKe2dfKCux
MBNNiKLRcCeFlFC/Z7ufEB62ogR3N3GKyD3StKPjHtLLDSi+NjA/juLBN0dSgERh
PMWpoqzNTopFHCfqOYOaLCY3/z8Mqk53FyqDhIH0ussoncsdb6ZVcw/nbZjeX/ew
0b1/pnpnP8pjGAu2cDhtEWbLod/yvVpwXdhalH7Y2VWme1RBDFSAGJf0pu+Y/b+W
nPx7IlMTS8n+OyULIjHa
=1FWo
-----END PGP SIGNATURE-----


From thozza at redhat.com  Thu Aug 14 10:51:07 2014
From: thozza at redhat.com (Tomas Hozza)
Date: Thu, 14 Aug 2014 12:51:07 +0200
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
Message-ID: <53EC949B.7080908@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2014 11:22 PM, Paul Wouters wrote:
> On Wed, 13 Aug 2014, Pavel Simerda wrote:
> 
>> In my opinion, it would be much nicer to have an ordered list of
>> configured
>> probes including the full recursion probe. That way any distribution and
>> user could use any probe order.
>>
>> Example 1: Probe fedora infrastructure over 443, then fedora
>> infrastructure
>> over 80 and then the root servers.
> 
> That is bad. It would leave a privacy trail on the fedora server
> whenever I logon to a network where I'll never use the fedora
> infrastructure. It should ONLY be probed when I have a need for it.
> We avoid probing anything that's not the root or a large TLD server
> in the hopes that our queries are not leaving too many fingerprints
> on the net.

I think "bad" is a point of view. Doing full recursion produces more
DNS queries (until cached) to the net, just asking the fallback server
produces one. Then further queries origin from that server. Also if the
fallback server does resolving for more users, the harder is to say who
originally asked for the name, right?

So it depends on how you put it and what is your intention. I understand
that you don't want to use "untrusted" 3rd party fallback
infrastructure, since you consider the authoritative servers more
trustworthy. Others may consider the other way around the better choice.

>> Example 2: Probe my own infrastructure server, no other fallbacks.
> 
> I'm not sure how that use case is helpful to dnssec-trigger? We want to
> get working DNSSEC capable resolving going. If you want to somehow only
> use your infrastructure, even if it is broken, you should not use
> dnssec-trigger but use NM or equivalent to configure unbound directly.

Nobody said that the infrastructure we want to use is broken. It is the
fall-back infrastructure configured in dnssec-trigger configuration.

We are talking about trying to use the DNSSEC-enabled fallback
infrastructure first. The "other fallbacks" stands for other fallback
mechanisms, like full recursion, etc., right Pavel?

>> And I also don't like that unbound's "forward off" has a side effect of
>> turning on full recursion. I would prefer if the "off" value would just
>> do what it says, i.e. remove all forwarders and if there was a separate
>> "direct" or "recursion" value/option that would turn on the full
>> recursion.
> 
> You want a state where unbound would not be allowed to forward and
> not be allowed to recurse? As in be dead in the water? Can you explain
> why that would be useful to a user?

I think that Pavel pointed out the use case already required by
dnssec-trigger when setting 127.0.0.127 as forwarder.

>> Also in my opinion, if all probing fails, it would be better
>> to let unbound reject queries immediately rather than attempt a defunct
>> fallback.
> 
> What is a defunct fallback? Often the TCP based fallback is slow and
> results in timeouts. It is still better then rejecting everything. And
> once unbound implements draft-ietf-dnsop-edns-chain-query those problems
> would hopefully go away as it would only require on consistent open TCP
> connection.

Regards,
- -- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT7JSbAAoJEMWIetUdnzwtptoIAL5HfiOFuRNRNYxc+dY2FGaz
iZcKumf+QPsjsUcxmmQQvOAUTPsGkBf4aCEdbmaTVUridNhEdAC7Cp9zHhsQVSfD
8+GArBI9LlDu7Ax1bv7tWlpx7FojUCJK+FI/E7BjHUW63Ogs/OYyjWg99ALlgK4u
ItDsPuZZnJpbcHC1HNtrPa2YstW635g41y2dR+PK5OueLRKs5SaIZ9OPgupnBSi5
aPGbDcddLTS1X8q+dMg19HAYIqkQm9xOq/JJmn23/JzgBrKob/0IXavMrS09pJEs
wgYShZ0TTb0jKYWpadHKzXRVl+H7nI258W3W1kgrG7f18FM0cByYlfKc7ckuywA=
=hyEl
-----END PGP SIGNATURE-----


From paul at nohats.ca  Thu Aug 14 14:18:29 2014
From: paul at nohats.ca (Paul Wouters)
Date: Thu, 14 Aug 2014 10:18:29 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <1635648743.13430231.1408000020455.JavaMail.zimbra@redhat.com>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
 <1635648743.13430231.1408000020455.JavaMail.zimbra@redhat.com>
Message-ID: <alpine.LFD.2.10.1408141011480.8307@bofh.nohats.ca>

On Thu, 14 Aug 2014, Pavel Simerda wrote:

>>> Example 1: Probe fedora infrastructure over 443, then fedora infrastructure
>>> over 80 and then the root servers.
>>
>> That is bad.
>
> 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. It's the "click to continue" soft fail.

>>> Example 2: Probe my own infrastructure server, no other fallbacks.
>>
>> I'm not sure how that use case is helpful to dnssec-trigger? We want to
>> get working DNSSEC capable resolving going. If you want to somehow only
>> use your infrastructure, even if it is broken, you should not use
>> dnssec-trigger but use NM or equivalent to configure unbound directly.
>
> It would still provide the probing and the user would get consistent user
> experience. Imagine a number of own infrastructure servers instead of one,
> if you think the example is too simple.

The override is already there to go "INSECURE". We could possibly make
it more clear to the user that the local infrastructure was broken and
if they require its use they should override. And possibly not just call
it INSECURE, but something like "force local insecure/broken" or
something.

>>> And I also don't like that unbound's "forward off" has a side effect of
>>> turning on full recursion. I would prefer if the "off" value would just
>>> do what it says, i.e. remove all forwarders and if there was a separate
>>> "direct" or "recursion" value/option that would turn on the full
>>> recursion.
>>
>> You want a state where unbound would not be allowed to forward and
>> not be allowed to recurse?
>
> Exactly. And I'm apparently not alone as dnssec-trigger seems to already
> work around this limitation by setting 127.0.0.127.

unbound still answers to incoming queries from the cache in that state.
So it is still a resolver for the client applications. I had they
impression you wanted unbound to not answer at all.

>> As in be dead in the water? Can you explain why that would be useful to
>> a user?
>
> There are periods of time when there's no secure DNS service for global
> 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.

>>> Also in my opinion, if all probing fails, it would be better
>>> to let unbound reject queries immediately rather than attempt a defunct
>>> fallback.
>>
>> What is a defunct fallback?
>
> A fallback that doesn't reply. I don't know what's the exact current
> behavior when probing fails for all fallbacks.
>
>> Often the TCP based fallback is slow and results in timeouts.
>> It is still better then rejecting everything.
>
> Do you propose to use a random failed fallback? Is anything similar being
> done already?

I would like to see unbound use one or a few persistent TCP connections
to the upstream fallback resolvers, as that will greatly reduce the
timed out queries to fallbacks that DO work but are too slow now because
the local unbound builds a TCP handshake for every individual query.
That's why I wrote the tcp-edns-query-chain draft.

Paul


From paul at nohats.ca  Thu Aug 14 14:40:46 2014
From: paul at nohats.ca (Paul Wouters)
Date: Thu, 14 Aug 2014 10:40:46 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <53EC949B.7080908@redhat.com>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
 <53EC949B.7080908@redhat.com>
Message-ID: <alpine.LFD.2.10.1408141030310.8307@bofh.nohats.ca>

On Thu, 14 Aug 2014, Tomas Hozza wrote:

>>> Example 1: Probe fedora infrastructure over 443, then fedora
>>> infrastructure
>>> over 80 and then the root servers.
>>
>> That is bad. It would leave a privacy trail on the fedora server
>> whenever I logon to a network where I'll never use the fedora
>> infrastructure. It should ONLY be probed when I have a need for it.
>> We avoid probing anything that's not the root or a large TLD server
>> in the hopes that our queries are not leaving too many fingerprints
>> on the net.
>
> I think "bad" is a point of view. Doing full recursion produces more
> DNS queries (until cached) to the net, just asking the fallback server
> produces one.

I am worried about leaking my source IP trail to one single (fedora)
server. Using local caches actually makes it much harder to track my
whereabouts, precisely because they have cache. Even if all the local
wifi's used 8.8.8.8, my whereabouts wouldn't routed far up the network,
and hopefully would be more lost in the noise. Those queries would also
most likely go in plaintext (port 80) to the fallback server and not
over tls (port 443).

> So it depends on how you put it and what is your intention. I understand
> that you don't want to use "untrusted" 3rd party fallback
> infrastructure, since you consider the authoritative servers more
> trustworthy. Others may consider the other way around the better choice.

Offering the users too many dials and buttons is not good. We need to
look at DNS privacy concerns and make as many decisions for the users
as we can. Powerusers can always setup a VPN to their own infrastructure
and use their own DNS servers there.

>>> Example 2: Probe my own infrastructure server, no other fallbacks.
>>
>> I'm not sure how that use case is helpful to dnssec-trigger? We want to
>> get working DNSSEC capable resolving going. If you want to somehow only
>> use your infrastructure, even if it is broken, you should not use
>> dnssec-trigger but use NM or equivalent to configure unbound directly.
>
> Nobody said that the infrastructure we want to use is broken. It is the
> fall-back infrastructure configured in dnssec-trigger configuration.

Which, if you have used it at all, tends to cause many timeouts right
now, and I often have to go to INSECURE mode or bring up a VPN because
it becomes unworkable really fast.

> We are talking about trying to use the DNSSEC-enabled fallback
> infrastructure first.

I understand. And I have a problem with always sending out a pretty
unique/rare probe packet that identifies me if it is not required to do
so. The design of dnssec-trigger takes privacy into account. I went
around asking some big TLDs for certain test records, precisely because
it is better to ask TLD servers are not have OS specific probes send.

I believe it would be good not to send probes to fedora/rhel
infrastructure, unless you have no choice.

Additionally, probing when not needed puts load on the servers
too. Remember those fallback servers only talk TCP or TCP-SSL to
clients.

Paul


From psimerda at redhat.com  Thu Aug 14 15:33:47 2014
From: psimerda at redhat.com (Pavel Simerda)
Date: Thu, 14 Aug 2014 11:33:47 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <alpine.LFD.2.10.1408141011480.8307@bofh.nohats.ca>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
 <1635648743.13430231.1408000020455.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408141011480.8307@bofh.nohats.ca>
Message-ID: <1226145828.13610694.1408030427137.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Paul Wouters" <paul at nohats.ca>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: dnssec-trigger at nlnetlabs.nl
> Sent: Thursday, August 14, 2014 4:18:29 PM
> Subject: Re: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
> 
> On Thu, 14 Aug 2014, Pavel Simerda wrote:
> 
> >>> Example 1: Probe fedora infrastructure over 443, then fedora
> >>> infrastructure
> >>> over 80 and then the root servers.
> >>
> >> That is bad.
> >
> > 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.

> It's the "click to continue" soft fail.

I don't think administrative configuration and "click to continue" are
comparable in any way.

> >>> Example 2: Probe my own infrastructure server, no other fallbacks.
> >>
> >> I'm not sure how that use case is helpful to dnssec-trigger? We want to
> >> get working DNSSEC capable resolving going. If you want to somehow only
> >> use your infrastructure, even if it is broken, you should not use
> >> dnssec-trigger but use NM or equivalent to configure unbound directly.
> >
> > It would still provide the probing and the user would get consistent user
> > experience. Imagine a number of own infrastructure servers instead of one,
> > if you think the example is too simple.
> 
> The override is already there to go "INSECURE". We could possibly make
> it more clear to the user that the local infrastructure was broken and
> if they require its use they should override. And possibly not just call
> it INSECURE, but something like "force local insecure/broken" or
> something.
> 
> >>> And I also don't like that unbound's "forward off" has a side effect of
> >>> turning on full recursion. I would prefer if the "off" value would just
> >>> do what it says, i.e. remove all forwarders and if there was a separate
> >>> "direct" or "recursion" value/option that would turn on the full
> >>> recursion.
> >>
> >> You want a state where unbound would not be allowed to forward and
> >> not be allowed to recurse?
> >
> > Exactly. And I'm apparently not alone as dnssec-trigger seems to already
> > work around this limitation by setting 127.0.0.127.
> 
> unbound still answers to incoming queries from the cache in that state.
> So it is still a resolver for the client applications. I had they
> impression you wanted unbound to not answer at all.

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.

> >> As in be dead in the water? Can you explain why that would be useful to
> >> a user?
> >
> > There are periods of time when there's no secure DNS service for global
> > 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.

> >>> Also in my opinion, if all probing fails, it would be better
> >>> to let unbound reject queries immediately rather than attempt a defunct
> >>> fallback.
> >>
> >> What is a defunct fallback?
> >
> > A fallback that doesn't reply. I don't know what's the exact current
> > behavior when probing fails for all fallbacks.
> >
> >> Often the TCP based fallback is slow and results in timeouts.
> >> It is still better then rejecting everything.
> >
> > Do you propose to use a random failed fallback? Is anything similar being
> > done already?
> 
> I would like to see unbound use one or a few persistent TCP connections
> to the upstream fallback resolvers, as that will greatly reduce the
> timed out queries to fallbacks that DO work but are too slow now because
> the local unbound builds a TCP handshake for every individual query.

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.

Cheers,

Pavel


From paul at nohats.ca  Fri Aug 15 15:13:33 2014
From: paul at nohats.ca (Paul Wouters)
Date: Fri, 15 Aug 2014 11:13:33 -0400 (EDT)
Subject: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
In-Reply-To: <1226145828.13610694.1408030427137.JavaMail.zimbra@redhat.com>
References: <2123559081.12969934.1407940283939.JavaMail.zimbra@redhat.com>
 <53EB7CD2.3090105@nlnetlabs.nl>
 <1241993819.13332971.1407957083863.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408131715220.6321@bofh.nohats.ca>
 <1635648743.13430231.1408000020455.JavaMail.zimbra@redhat.com>
 <alpine.LFD.2.10.1408141011480.8307@bofh.nohats.ca>
 <1226145828.13610694.1408030427137.JavaMail.zimbra@redhat.com>
Message-ID: <alpine.LFD.2.10.1408151059280.10260@bofh.nohats.ca>

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