Steps to reproduce:

1) Set the nameserver(s) using:

dnssec-trigger-commit ip-address-of-bad-nameserver

2) Check unbound configuration:

unbound-control forward


Expected result:

Fallback nameservers in the output.


Actual result:

"off" in the output (recursion done by unbound).


Notes:

You might want to use verbosity=4 and check the logs.

*** Bug 1119050 has been marked as a duplicate of this bug. ***

Link to testcase (from the duplicate):

https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL

Created attachment 926216 [details]
dnssec-trigger log after "dnssec-trigger-control submit ..."

From the log it looks like the probing completes successfully but still dnssec-triggerd instructs unbound not to use forwarding.

Configuration (without comments):

verbosity: 4
resolvconf: "/var/run/dnssec-trigger/resolv.conf"
url: "http://fedoraproject.org/static/hotspot.txt OK"
ssl443: 80.239.156.220 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
tcp80:  80.239.156.220
ssl443: 66.35.62.163 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
tcp80:  66.35.62.163
ssl443: 152.19.134.150 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
tcp80:  152.19.134.150
ssl443: 2610:28:3090:3001:dead:beef:cafe:fed9 A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
tcp80:  2610:28:3090:3001:dead:beef:cafe:fed9

It looks like the fallbacks are not probed at all but instead they are simply ignored.

I probably found where the problem is:

1382 void
1383 probe_cache_done(void)
1384 {
...
1403 »···if(!svr->probe_dnstcp && !svr->saw_first_working
1404 »···»···&& !svr->saw_direct_work && (cfg_have_dnstcp(svr->cfg) ||

The dnstcp probing is only started if the above condition is true and during my testing saw_direct_work was true rendiring the whole condition false. I don't see any reason to not probe for dnstcp as direct should only be used as a last resort.

I would even say that the direct should never be used (especially if fallbacks are set up) as it increases traffic on the authoritative servers which is generally bad and probably also against any standards and usage policies and it doesn't provide any benefit to the user. When HTTP and HTTPS to the known public servers is blocked, DNS to any external servers will be probably blocked as well.

Created attachment 926465 [details]
patch to fix the issue

So finally it seems that the behavior is different what we thought. The full recursion fallback is always preferred over the infrastructure fallbacks. Whether it's a good idea or not is another story. I manually confirmed that the upstream behavior is consistent which puts the QA test into question.

(In reply to Pavel Šimerda (pavlix) from comment #3)
> Link to testcase (from the duplicate):
> 
> https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL

The test case works for me using the upstream package.

I'm going to close this bug report if it's not confirmed with Fedora 20 or later.

(In reply to Pavel Šimerda (pavlix) from comment #10)
> (In reply to Pavel Šimerda (pavlix) from comment #3)
> > Link to testcase (from the duplicate):
> > 
> > https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL
> 
> The test case works for me using the upstream package.

Is the upstream package in Updates Testing?

(In reply to quickbooks.office from comment #12)
> (In reply to Pavel Šimerda (pavlix) from comment #10)
> Is the upstream package in Updates Testing?

Basically yes, the updates-testing package is very close to upstream and it's most helpful to test that package now.

(In reply to Pavel Šimerda (pavlix) from comment #9)
> So finally it seems that the behavior is different what we thought. The full
> recursion fallback is always preferred over the infrastructure fallbacks.
> Whether it's a good idea or not is another story. I manually confirmed that
> the upstream behavior is consistent which puts the QA test into question.

Confused here. I blocked all UDP traffic on my router. I am not able to get any connectivity using the following steps:

Enable Updates Testing:

yum install dnssec-trigger

systemctl enable dnssec-triggerd.service

systemctl enable unbound.service

service unbound restart

service dnssec-trigger restart

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -p tcp --dport 53 -j REJECT --reject-with icmp-admin-prohibited

iptables -A OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-admin-prohibited 

Then I go the hard way to the system tray / Right-click on dnssec-trigger applet and select "reprobe" .

What am I supposed to do to get DNS-over-SSL to work?

So... according to my tests the fallbacks work correctly. All you should need is the current f20 stable package with the distro version of the configuration file, block the tcp/udp 53 as you describe, restart dnssec-trigger or reprobe from GUI.

You should separately test that you can reach the configured fallbacks via specified ports. You can also use a higher log level and check what exactly is happening. I played with it for a while and it worked nicely with the blocked DNS tcp/udp port.

Some of my previous comments are void since we talked about the fallbacks and indeed the root server usage is seen as preferred over the infrastructure fallbacks.

Please reopen if you can still reproduce the issue and provide detailed information.