Bug 1133219 - dnssec-trigger fails to configure forwarders for unbound resolver
Summary: dnssec-trigger fails to configure forwarders for unbound resolver
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnssec-trigger
Version: 21
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: Fad_Pune_Aug_2014
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-23 13:12 UTC by pjp
Modified: 2015-01-20 11:22 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-01-20 11:22:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description pjp 2014-08-23 13:12:16 UTC
Today we configured Local DNSSEC resolver on a F21 alpha release as part of FAD_Pune_Aug_2014. While it resolved external internet domains, it failed to resolve local internal domain names.

Description of problem:
dnssec-trigger fails to configure forwarders list in unbound DNSSEC resolver.

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

How reproducible: always


Steps to Reproduce:
1. boot from a F21 liveos built from 
   Fedora-Live-Workstation-x86_64-21-20140820.iso
     -> http://koji.fedoraproject.org/koji/taskinfo?taskID=7430567
2. Yum install dnssec-trigger
3. Start nm-connection-editor
4. Edit network IPv4 settings to make NM configure only IP address
   and set DNS server = 127.0.0.1
5. systemctl enable dnssec-trigger
6. systemctl start dnssec-trigger
7. Browse internet & intranet sites

Actual results:
  - unbound fails to resolve internal domain names.
  - unbound-control list_forwards shows no output.

Expected results:
  - unbound must resolve internal domains names too.
  - unbound-control list_forwards should show local name servers list.

Additional info:

Comment 1 Tomáš Hozza 2014-08-25 08:07:37 UTC
Hi.

Could you please run:
# python /usr/libexec/dnssec-trigger-script --debug --update

and attach the output?

Also configuration of active connections from NM would be beneficial.
(use 'nmcli c s a <uuid>').

If the network-provided nameservers are the only ones able to resolve internal zones and are NOT DNSSEC-capable, then dnssec-trigger will not use them. At the moment dnssec-trigger sets up a forward zone for each connection-provided domain. This is done by default for each connection type, except WiFi connection. The behavior can be altered by editing /etc/dnssec.conf.

Please note that currently, if the connection does not provide any domain with it, dnssec-trigger is not able to configure forward zone properly and thus internal zones will not work. We have some thoughts about how to solve this situation, but nobody implemented it yet.

Comment 2 pjp 2014-09-23 06:34:21 UTC
   Hello Tomas,

(In reply to Tomas Hozza from comment #1)
> Could you please run:
> # python /usr/libexec/dnssec-trigger-script --debug --update
> and attach the output?

===
[root@localhost ~]# unbound-control list_forwards
[root@localhost ~]# 
[root@localhost ~]# python  /usr/libexec/dnssec-trigger-script --debug --update
<Config validate_connection_provided_zones=False add_wifi_provided_zones=False>
Running: run_update
<ConnectionList(only_default=True, skip_wifi=False, connections=[<Connection(uuid=59b0864f-b099-4b15-9e2b-c33df84a1524, type=other, default=True, zones=[], servers=['127.0.0.1'])>])>
<Store(name=servers, set(['127.0.0.1']))>
Global forwarders: 127.0.0.1
<ConnectionList(only_default=False, skip_wifi=True, connections=[<Connection(uuid=59b0864f-b099-4b15-9e2b-c33df84a1524, type=other, default=True, zones=[], servers=['127.0.0.1'])>])>
<UnboundZoneConfig(data={})>
<Store(name=zones, set([]))>
removing stored zones not present in both unbound and an active connection
installing connection provided zones
[root@localhost ~]# 
[root@localhost ~]# unbound-control list_forwards
[root@localhost ~]# 
===

> Also configuration of active connections from NM would be beneficial.
> (use 'nmcli c s a <uuid>').

===
[root@localhost ~]# nmcli c s 59b0864f-b099-4b15-9e2b-c33df84a1524 | grep domain
DHCP4.OPTION[2]:                        requested_domain_search = 1
DHCP4.OPTION[3]:                        requested_nis_domain = 1
DHCP4.OPTION[8]:                        requested_domain_name = 1
DHCP4.OPTION[12]:                       domain_name = redhat.com
DHCP4.OPTION[23]:                       requested_domain_name_servers = 1
DHCP4.OPTION[25]:                       domain_name_servers = 10.65.201.89 10.68.5.26 10.70.34.1
[root@localhost ~]#
===

> If the network-provided nameservers are the only ones able to resolve
> internal zones and are NOT DNSSEC-capable, then dnssec-trigger will not use
> them.

  Sorry? But that's always the case, only network-provided name servers would know about internal doamins, no?

> At the moment dnssec-trigger sets up a forward zone for each
> connection-provided domain. This is done by default for each connection
> type, except WiFi connection. The behavior can be altered by editing
> /etc/dnssec.conf.

  Shouldn't it be default configuration in /etc/dnssec.conf? Because we can not expect or ask users to edit /etc/dnssec.conf to resolve domain names over WiFi.

> Please note that currently, if the connection does not provide any domain
> with it, dnssec-trigger is not able to configure forward zone properly and
> thus internal zones will not work. We have some thoughts about how to solve
> this situation, but nobody implemented it yet.

   I see. Recently one of the colleague also reported this same issue, that internal domain don't resolve.

Please let me know if you need more information.

Thank you.

Comment 3 Siddharth Sharma 2014-09-23 06:45:41 UTC
Hi,

I have the same problem , if i am in VPN it stops resolving any internal IP's. Let me know if any information is needed 

Thanks

Comment 4 Pavel Šimerda (pavlix) 2014-09-23 08:56:05 UTC
(In reply to pjp from comment #2)
> <Connection(uuid=59b0864f-b099-4b15-9e2b-c33df84a1524,
> type=other, default=True, zones=[], servers=['127.0.0.1'])>])>

This looks like a misconfiguration in NetworkManager. No connection should have 127.0.0.1 in the list of DNS servers. The only thing we could do is to issue a warning when it happens.

Comment 5 pjp 2014-09-23 09:29:08 UTC
(In reply to Pavel Šimerda (pavlix) from comment #4)
> This looks like a misconfiguration in NetworkManager. No connection should
> have 127.0.0.1 in the list of DNS servers. The only thing we could do is to
> issue a warning when it happens.

  Yes, after removing nameserver=127.0.0.1 from the NM connection settings, unbound is configured with the local forwarders, and resolves internal domains too.

Thank you.


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