Bug 1289823 - Local DNS resolver using public view of split DNS (race condition?)
Local DNS resolver using public view of split DNS (race condition?)
Product: Fedora
Classification: Fedora
Component: dnssec-trigger (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-12-08 22:59 EST by Scott Schmit
Modified: 2017-12-12 06:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-12 06:09:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Lightly-sanitized results of "journalctl -b -u NetworkManager -u dnssec-triggerd -u unbound" (35.10 KB, text/plain)
2015-12-08 22:59 EST, Scott Schmit
no flags Details
Requested information for various boots (39.99 KB, application/x-gzip)
2016-01-04 23:08 EST, Scott Schmit
no flags Details

  None (edit)
Description Scott Schmit 2015-12-08 22:59:18 EST
Created attachment 1103782 [details]
Lightly-sanitized results of "journalctl -b -u NetworkManager -u dnssec-triggerd -u unbound"

Description of problem:
I followed the directions at https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test on a Fedora 22 laptop.

My network domain is DNSSEC-protected and split DNS, with a private and public view, both of which are signed.  DHCP(v6) offer DNS resolvers that are running bind-9.10.2-5.P4.fc22.x86_64.  These resolvers present a private view when accessed via internal IP addresses and a public view when accessed via external IP addresses.  The addresses presented by DHCP(v6) are internal addresses, so if these addresses are used, the laptop should get the private view.

After booting my laptop today, I found that DNS lookups were using my domain's public view instead of the private view.  After disabling WiFi & re-enabling it, DNS lookups used my private view as expected.

I'm not sure which component to file this against, as I suspect it may be a race condition in the interactions between components (based on the logs), but the Change page says to file against dnssec-trigger, so that's what I went with.

Version-Release number of selected component (if applicable):

How reproducible:
I'm not sure -- I've just tried the one boot so far.  If this matters, I can provide more detailed information as I boot the laptop over time.

Steps to Reproduce:
1. Boot the PC from a cold start in range of an already-configured WiFi network providing the private view of a DNSSEC-protected split DNS zone (both views signed)
2. Observe that lookups use the public zone after connection
3. Disable and re-enable the network connection
4. Observe that lookups use the private zone after connection

Actual results:
The public view is used (apparently) due to timeouts while the system is starting.  The private view is used after disconnecting and reconnecting from the network.

Expected results:
The private view is used, every time.

Additional info:
I'm attaching the lightly-sanitized results of "journalctl -b -u NetworkManager -u dnssec-triggerd -u unbound"
You can see the log results from startup, after disabling the WiFi, and after re-enabling the WiFi.
Comment 1 Paul Wouters 2015-12-08 23:05:47 EST
can you show the output of sudo unbound-control list_forwards

normally, that should contain a forwarder for "." (the root) to one of your DHCP supplied DNS servers, which would be internal, and so things should work?

Another check you can do is running:

sudo dnssec-trigger-control status

which will show the results of the last probe and could have a hint about what happened.
Comment 2 Scott Schmit 2015-12-12 14:29:15 EST
Sorry it took me a while to get back to you, as soon as you gave me those commands to try, it stopped happening until today. Looking at my logs, I've booted 9 times since enabling dnssec-triggerd and only 3/9 of those boots came up with the external view (so far).

Anyway, the output you were looking for:
$ sudo unbound-control list_forwards
$ sudo dnssec-trigger-control status
at (no probe performed)
no cache: no DNS servers have been supplied via DHCP
state: auth secure

Hope this helps!
Comment 3 Paul Wouters 2015-12-14 11:53:39 EST
So it seems NetworkManager is telling dnssec-trigger hooks that it did not get any DNS servers from DHCP. When this happens next, can you check with nmcli if it lists DNS servers? This is either an issue in NM lying to dnssec-trigger, or dnssec-trigger misreading NM.
Comment 4 Scott Schmit 2016-01-04 23:08 EST
Created attachment 1111683 [details]
Requested information for various boots

See attachment for the journalctl and requested command output for various connections to my network. I tried to get enough samples with consistent structure so that you can diff between good & bad, etc.  My naming isn't perfectly consistent, but hopefully the timestamps should make things fairly clear.
Comment 5 Jan Kurik 2016-07-26 00:57:48 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.
Comment 6 Fedora End Of Life 2017-11-16 14:41:45 EST
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 7 Fedora End Of Life 2017-12-12 06:09:31 EST
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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