Bug 1109292 - dnssec-trigger doesn't setup fallback global nameservers in unbound
Summary: dnssec-trigger doesn't setup fallback global nameservers in unbound
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnssec-trigger
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1119050 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-13 15:03 UTC by Pavel Šimerda (pavlix)
Modified: 2015-05-11 16:54 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-30 14:40:38 UTC
Type: Bug


Attachments (Terms of Use)
dnssec-trigger log after "dnssec-trigger-control submit ..." (26.87 KB, text/plain)
2014-08-12 21:07 UTC, Pavel Šimerda (pavlix)
no flags Details
patch to fix the issue (400 bytes, patch)
2014-08-13 14:24 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff

Description Pavel Šimerda (pavlix) 2014-06-13 15:03:06 UTC
I'm testing dnssec-trigger-script in rawhide and dnssec-trigger seems to probe the local servers resulting in failure, then probe the fallback servers apparently with success but at the end calls 'unbound-control forward off' instead of installing the fallback DNS server in unbound.

Comment 1 Pavel Šimerda (pavlix) 2014-06-13 15:22:25 UTC
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.

Comment 2 Tomáš Hozza 2014-07-14 07:19:20 UTC
*** Bug 1119050 has been marked as a duplicate of this bug. ***

Comment 3 Pavel Šimerda (pavlix) 2014-08-07 13:22:31 UTC
Link to testcase (from the duplicate):

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

Comment 4 Pavel Šimerda (pavlix) 2014-08-12 21:07:08 UTC
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.

Comment 5 Pavel Šimerda (pavlix) 2014-08-12 21:23:14 UTC
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

Comment 6 Pavel Šimerda (pavlix) 2014-08-12 21:23:48 UTC
It looks like the fallbacks are not probed at all but instead they are simply ignored.

Comment 7 Pavel Šimerda (pavlix) 2014-08-13 14:09:32 UTC
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.

Comment 8 Pavel Šimerda (pavlix) 2014-08-13 14:24:08 UTC
Created attachment 926465 [details]
patch to fix the issue

Comment 9 Pavel Šimerda (pavlix) 2014-08-13 19:16:14 UTC
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.

Comment 10 Pavel Šimerda (pavlix) 2014-08-13 19:21:03 UTC
(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.

Comment 11 Pavel Šimerda (pavlix) 2014-08-13 19:24:04 UTC
I'm going to close this bug report if it's not confirmed with Fedora 20 or later.

Comment 12 Moez Roy 2014-08-14 03:35:43 UTC
(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?

Comment 13 Pavel Šimerda (pavlix) 2014-08-14 07:14:09 UTC
(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.

Comment 14 Moez Roy 2014-09-04 09:38:34 UTC
(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?

Comment 15 Pavel Šimerda (pavlix) 2014-09-23 09:16:23 UTC
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.

Comment 16 Pavel Šimerda (pavlix) 2014-10-30 14:40:38 UTC
Please reopen if you can still reproduce the issue and provide detailed information.


Note You need to log in before you can comment on or make changes to this bug.