Bug 1182488 (Default_Local_DNS_Resolver) - Default Local DNS Resolver
Summary: Default Local DNS Resolver
Keywords:
Status: NEW
Alias: Default_Local_DNS_Resolver
Product: Fedora
Classification: Fedora
Component: distribution
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomáš Hozza 🤓
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: ChangeAcceptedF22 SystemWideChange Ch...
Depends On: 1108335 gnome_portal_helper_dns_servers 1287607 ipv6 1125267 dnssec_policy 1146109 1147030 1147705 1183981 1187183 1187371 1187839 1195752 1200996 1201813 1201830 1203950 1210250 1213573 1215376 1221939 1223110 1227239 1227397 1227399 1227406 1228465 1229216 1229596 1229599 1231798 1235289 1235290 1236363 1240193 1241291 1242567 1242578 1251762 1256737 nm_connectivity_state_change_notify docker_local_resolver 1317615 1361256 1361257
Blocks: dnssec
TreeView+ depends on / blocked
 
Reported: 2015-01-15 09:23 UTC by Jaroslav Reznik
Modified: 2019-08-19 07:37 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Jaroslav Reznik 2015-01-15 09:23:30 UTC
This is a tracking bug for Change: Default Local DNS Resolver
For more details, see: https://fedoraproject.org//wiki/Changes/Default_Local_DNS_Resolver

To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.

Comment 1 Waclaw Sierek 2015-02-05 19:05:59 UTC
Will there be any impact for those using services like Unlocator https://unlocator.com/faq/ ?

Comment 2 Pavel Šimerda (pavlix) 2015-02-06 15:53:33 UTC
(In reply to Waclaw Sierek from comment #1)
> Will there be any impact for those using services like Unlocator
> https://unlocator.com/faq/ ?

The FAQ is not very descriptive. I can just guess that Unlocator works by spoofing the DNS responses and directing traffic to their own proxy. That will be detected by Unbound as an attack. That means that you'll either not reach the services or that you will reach them as if without the Unlocator service.

You may choose to turn off the feature entirely or you can configure Unbound to use Unlocator services for specific DNS domain subtrees. Static /etc/unbound configuration will take precedence over the dynamic data from dnssec-trigger.

Comment 3 Tomáš Hozza 🤓 2015-02-07 11:23:43 UTC
(In reply to Waclaw Sierek from comment #1)
> Will there be any impact for those using services like Unlocator
> https://unlocator.com/faq/ ?

I think it should work as long as they don't mess with DNS records like Pavel noted. But from my testing their DNS servers seems to be OK.

root@thozza-pc ~
# unbound-control forward 185.37.37.37 185.37.37.185
ok
root@thozza-pc ~
# unbound-control flush_zone .
ok removed 26 rrsets, 17 messages and 4 key entries
root@thozza-pc ~
# dig nic.cz

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> nic.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54359
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nic.cz.				IN	A

;; ANSWER SECTION:
nic.cz.			1753	IN	A	217.31.205.50

;; Query time: 137 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 07 12:19:33 CET 2015
;; MSG SIZE  rcvd: 51

root@thozza-pc ~
# dig rhybar.cz

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-6.P1.fc21 <<>> rhybar.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26221
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rhybar.cz.			IN	A

;; Query time: 242 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 07 12:19:38 CET 2015
;; MSG SIZE  rcvd: 38


However I'm not sure if we are now able to use use statically configured forwarders without dnssec-trigger daemon reconfiguring it.

Comment 4 Jaroslav Reznik 2015-02-20 10:01:42 UTC
This message is a reminder that Fedora 22 Change Checkpoint: Completion deadline (testable) is on 2015-02-24 [1].

At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Completion deadline.

This bug should be set at least to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. Fedora 22 is going to be strictly time based release. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon. 

In case of any questions, don't hesitate to ask Wrangler (jreznik). Thank you.

[1] https://fedoraproject.org/wiki/Releases/22/Schedule

Comment 5 Tomáš Hozza 🤓 2015-02-24 09:45:12 UTC
We, the owners of the feature discussed the status. Currently the feature is almost complete, however it lacks mechanism to better handle slit DNS configuration with networks that don't provide the domains list on connect. We are planning to address this situation by special unbound module, which is currently worked on, but it is not finished yet. Without the module we think the Change could break some users setup and thus forcing them to turn it off.

We would like to prevent such scenario and decided to postpone the Change to F23.

Comment 6 Jaroslav Reznik 2015-02-24 13:52:12 UTC
Ok, thank you. I'm going to proceed with required steps to move to F23.

Comment 7 Shawn Starr 2015-06-11 20:10:50 UTC
In so much as how this feature plays with people who run their own nameservers? As long as this can be disabled completely, my own DNS server running PowerDNS will soon support recursive DNSSEC checking so I don't need a DNS running on localhost.

Comment 8 Petr Spacek 2015-06-12 07:49:10 UTC
You are free to disable it, sure. We are aiming to provide sensible and secure defaults in the vanilla installation but of course you will be able to uninstall the package or change NetworkManager configuration at will.

Comment 9 Moez Roy 2015-07-11 06:30:10 UTC
*** Bug 1164044 has been marked as a duplicate of this bug. ***

Comment 10 Jan Kurik 2015-07-14 14:02:41 UTC
This message is a reminder that Fedora 23 Change Checkpoint: Completion deadline (testable) is on 2015-07-28 [1].

At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Completion deadline.

This bug should be set at least to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon. 

In case of any questions, don't hesitate to ask Wrangler (jkurik). Thank you.

[1] https://fedoraproject.org/wiki/Releases/23/Schedule

Comment 11 Jan Kurik 2015-08-06 09:06:35 UTC
Removing from the scope of F23 as we have already passed the deadline when this change needs to be in MODIFIED state.

Comment 12 pjp 2015-08-06 15:08:50 UTC
Hello Jan,

(In reply to Jan Kurik from comment #11)
> Removing from the scope of F23 as we have already passed the deadline when
> this change needs to be in MODIFIED state.

No, the work is in progress and the solution is in good shape for testing. Tomas is currently traveling to US to attend Flock. He'll add the due details here soon. Let's note remove it from F23 scope just yet.

Thank you.

Comment 13 Tomáš Hozza 🤓 2015-08-06 18:50:04 UTC
Sorry for not updating the bug in time.

As PJP said, we are still actively working on getting all the changes into Fedora on time for F23. We discussed the approach on different products and think it makes sense to finally have this in Fedora by default. Although WGs can override the default presets and compose.

The current state is:

- on Workstation we agreed on specific integration steps:
  - GNOME should change the way they launch the Captive portal login browser window
  - dnssec-trigger is not installing the panel by default and ships different configuration (with Captive portal detection turned off)
  - NM devels will provide nm-dispatcher notification on Connection State change

GNOME part - not sure what is the state, since nobody from GNOME attended the last call we had
dnssec-trigger part - configuration done, still need to wait on the NM part
NM part - agreed with dcbw that they will prioritize to helps us be ready for F23


- Cloud and Docker
  - PJP is actively approaching the Docker upstream to change the way they are handling localhost in resolv.conf, so that the containers can use the local resolver. So it will make sense to have the resolver on the Atomic Host. With regular cloud images it does not make sense to include the local resolver.

Docker issue - https://github.com/docker/docker/issues/14627


- Server
  - It definitely makes sense to have it there and should work well already. Also since the dnssec-trigger panel is not installed by default, the situation is even better.


Sorry for the late update. I changed the target back to F23. If there is a problem with that, please approach us, the change owners.

Thanks!

Comment 14 Moez Roy 2015-08-09 19:16:59 UTC
(In reply to Tomas Hozza from comment #13)
> Sorry for not updating the bug in time.
> 
> As PJP said, we are still actively working on getting all the changes into
> Fedora on time for F23. We discussed the approach on different products and
> think it makes sense to finally have this in Fedora by default. Although WGs
> can override the default presets and compose.
> 
> The current state is:
> 
> - on Workstation we agreed on specific integration steps:
>   - GNOME should change the way they launch the Captive portal login browser
> window
>   - dnssec-trigger is not installing the panel by default and ships
> different configuration (with Captive portal detection turned off)
>   - NM devels will provide nm-dispatcher notification on Connection State
> change
> 
> GNOME part - not sure what is the state, since nobody from GNOME attended
> the last call we had
> dnssec-trigger part - configuration done, still need to wait on the NM part
> NM part - agreed with dcbw that they will prioritize to helps us be ready
> for F23
> 
> 
> - Cloud and Docker
>   - PJP is actively approaching the Docker upstream to change the way they
> are handling localhost in resolv.conf, so that the containers can use the
> local resolver. So it will make sense to have the resolver on the Atomic
> Host. With regular cloud images it does not make sense to include the local
> resolver.
> 
> Docker issue - https://github.com/docker/docker/issues/14627
> 
> 
> - Server
>   - It definitely makes sense to have it there and should work well already.
> Also since the dnssec-trigger panel is not installed by default, the
> situation is even better.
> 
> 
> Sorry for the late update. I changed the target back to F23. If there is a
> problem with that, please approach us, the change owners.
> 
> Thanks!

Its still not added to kickstart files or comps; from Bug 1203950:

(In reply to Kevin Fenzi from comment #7)
> So, it sounds like server is ok with it, but I don't know about cloud folks. 
> 
> If it's only cloud that doesn't want it, we would better put it in comps in
> a group everything installs/uses and exclude in cloud than all over the
> place in kickstart files. 
> 
> So, perhaps we should wait for the cloud folks and then add to comps and/or
> cloud kickstarts?

Comment 15 Tomáš Hozza 🤓 2015-08-10 15:40:35 UTC
PJP, can you please approach the cloud folks, so we can convince Fedora RCM to fix Bug #1203950?

Thanks!

Comment 16 Kevin Fenzi 2015-08-10 15:55:27 UTC
So, at the last FESCo meeting, all the changes that were not in modified were discussed, and a few were kept targeting F23, but the rest were not. 

https://fedorahosted.org/fesco/ticket/1467#comment:5

If you still intend to target this for f23 (and it seems you do?) I'd suggest opening a fesco ticket and informing fesco about this (Or if you like I can). 

The main issue here is that we just shipped alpha without this change, which means it will lack a lot of early testing that all the other changes are going to get.

Comment 17 pjp 2015-08-10 16:34:55 UTC
Hello Tomas,

(In reply to Tomas Hozza from comment #15)
> PJP, can you please approach the cloud folks, so we can convince Fedora RCM
> to fix Bug #1203950?

  Yes, will do.

Comment 18 Rok Papež 2015-08-18 14:11:42 UTC
Local resolver will break NAT64/DNS64 deployments, please don't make it default:
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#DNS64

NAT64 vs. NAT44:
- load on NAT decreases as more contents is available over IPv6
- much cheaper then CGN - Carrier Grade NAT
- better connectivity
- cleaner 1 IP protocol network, easier to troubleshoot

More:
http://blog.ipspace.net/2011/05/nat64-its-all-about-legacy-content.html
http://www.slideshare.net/IOSHints/nat64-and-dns64-in-30-minutes
(slide 11+ is about DNS64)

Arnes (http://www.arnes.si/en/about-arnes.html) plans production deployment of NAT64/DNS64 in next 4 years for 950-1500 organisations to feed the IoT/wireless craze.

Comment 19 Charles R. Anderson 2015-08-18 14:33:15 UTC
(In reply to Rok Papež from comment #18)
> Local resolver will break NAT64/DNS64 deployments, please don't make it
> default:
> https://en.wikipedia.org/wiki/IPv6_transition_mechanism#DNS64

The ship of "local DNS resolver" has already sailed in many platforms.  What you are suggesting is that we give up on DNSSEC so that legacy IPv4 can live longer.  I think this is a poor choice.  How about suggesting how DNS64 can be integrated into the Local DNS resolver instead?

Comment 20 Rok Papež 2015-08-26 14:13:24 UTC
(In reply to Charles R. Anderson from comment #19)
> (In reply to Rok Papež from comment #18)
> > Local resolver will break NAT64/DNS64 deployments, please don't make it
> > default:
> > https://en.wikipedia.org/wiki/IPv6_transition_mechanism#DNS64
> 
> The ship of "local DNS resolver" has already sailed in many platforms.  What
> you are suggesting is that we give up on DNSSEC so that legacy IPv4 can live
> longer.  I think this is a poor choice.  How about suggesting how DNS64 can
> be integrated into the Local DNS resolver instead?

NAT64/DNS64 ia a mechanism to deploy native only IPv6. NAT64 and DNS64 devices translate IPv6 client requests to IPv4 servers. It's one of the most promising technologies to adopt "IPv6 only" "client" networks. It's the least evil of all the NAT technologies; as IPv6 contents grows, less NATing is needed.

If local DNSSEC resolvers become the norm in all devices, DNS64 part won't work and we'll need to deploy NAT44 (regular IPv4-IPv4 NAT), thus prolonging the v4 agony and the v4 end-to-end connectivity breakage.

======================================
Example of plain DNS and DNS64 query:
# host nlb.si
nlb.si has address 193.201.214.49
nlb.si mail is handled by 5 mgw2.nlb.si.
nlb.si mail is handled by 5 mgw1.nlb.si.

# host nlb.si 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

nlb.si has address 193.201.214.49
nlb.si has IPv6 address 2001:1470:bfff:64:c1:c9d6:3100:0
nlb.si mail is handled by 5 mgw2.nlb.si.
nlb.si mail is handled by 5 mgw1.nlb.si.
======================================

DNS64 can't be easily integrated as it spoofs records; adds AAAA record to it. There is a way to use PCP: https://tools.ietf.org/html/rfc7225#section-3. But the local resolver would need to include the PCP client and do RFC 6147: "DNS64 in stub-resolver mode".

Integrating DNS64 into local resolver IETF (v6ops) thread here:
http://www.ietf.org/mail-archive/web/v6ops/current/msg22610.html

Default "vanilla" local resolver breaks NAT64.

Comment 21 Tomáš Hozza 🤓 2015-08-26 18:36:51 UTC
We agreed to aim for F24 to finish the integration properly. I'll update the change wiki.

Comment 22 Pavel Šimerda (pavlix) 2015-12-02 20:03:39 UTC
(In reply to Rok Papež from comment #18)
> Local resolver will break NAT64/DNS64 deployments

Local resolver concept won't break DNS64 but the DNSSEC by default feature conflicts with DNS64 by default due to the way DNS64 is specified.

The way out is to support DNS64 in unbound but then you either have to get each machine configured with the DNS64 prefix or you would have to use the universal DNS64 prefix which is IMO a much better solution.

While NAT64/DNS64 is a great idea, it IMO needs to be harmonized with DNSSEC instead of blocking it.

Comment 23 Pavel Šimerda (pavlix) 2015-12-02 20:21:50 UTC
(In reply to Pavel Šimerda (pavlix) from comment #22)
> (In reply to Rok Papež from comment #18)
> > Local resolver will break NAT64/DNS64 deployments

See also:

https://bugzilla.redhat.com/show_bug.cgi?id=1108335

Comment 24 Jan Kurik 2015-12-10 11:26:28 UTC
The Change has been postponed: https://fedorahosted.org/fesco/ticket/1511

Comment 25 Ben Cotton 2018-08-14 13:12:20 UTC
According to the Fedora 29 schedule[1], today is the deadline for changes to be in a testable state. If your change is ready to be tested, please set the status to ON_QA. A list of incomplete changes will be sent to FESCo tomorrow for evaluation. If you know your change will not be ready for Fedora 29, you can set the version to rawhide and notify bcotton@fedoraproject.org.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Comment 26 Tomáš Hozza 🤓 2018-08-14 13:57:40 UTC
(In reply to Ben Cotton from comment #25)
> According to the Fedora 29 schedule[1], today is the deadline for changes to
> be in a testable state. If your change is ready to be tested, please set the
> status to ON_QA. A list of incomplete changes will be sent to FESCo tomorrow
> for evaluation. If you know your change will not be ready for Fedora 29, you
> can set the version to rawhide and notify bcotton@fedoraproject.org.
> 
> [1] https://fedoraproject.org/wiki/Releases/29/Schedule

This is not F29 change. We are just keeping this tracker opened, because we are interested in tracking the work.

I think you should update your script or search properties, because this tracker is not something you need to be concerned about.

Comment 27 Ben Cotton 2019-02-19 20:15:34 UTC
Tomas, if you want to continue tracking work in this bug, please assign it to the appropriate component. The Changes Tracking component is for tracking Change proposals.

Comment 28 pjp 2019-02-20 06:57:33 UTC
Android 9 Pie has introduced a 'Private DNS' name server feature
to support secure encrypted name resolution via DNS-over-TLS protocol - RFC 7858.

  -> https://security.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
  -> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
  -> https://blog.cloudflare.com/enable-private-dns-with-1-1-1-1-on-android-9-pie/

In 'Automatic' mode it checks if the given name servers support DNS-over-TLS at tcp port 853,
if available it uses it by default. If not it falls back to regular port 53.

It's pretty much what we had planned with the local DNSSEC resolver feature.
I wonder if we could once again try and get GUI guys onboard with it.


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