Bug 1182488 (Default_Local_DNS_Resolver)

Will there be any impact for those using services like Unlocator https://unlocator.com/faq/ ?

(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.

(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.

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

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.

Ok, thank you. I'm going to proceed with required steps to move to F23.

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.

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.

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

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

Removing from the scope of F23 as we have already passed the deadline when this change needs to be in MODIFIED state.

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.

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!

(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?

PJP, can you please approach the cloud folks, so we can convince Fedora RCM to fix Bug #1203950?

Thanks!

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.

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.

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.

(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?

(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.

We agreed to aim for F24 to finish the integration properly. I'll update the change wiki.

(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.

(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

The Change has been postponed: https://fedorahosted.org/fesco/ticket/1511

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.

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

(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.
> 
> [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.

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.

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.

Given the f33 systemd-resolved change does this bug need to still exist? Or is there ongoing work you wish to track still here?

(In reply to Kevin Fenzi from comment #29)
> Given the f33 systemd-resolved change does this bug need to still exist? Or
> is there ongoing work you wish to track still here?

No, I'm not going to finish it and I don't expect anyone else to do it either. Closing.