Talk:Features/DNSSEC on workstations

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 7: Line 7:
 
[[User:pwouters]] dnsmasq can interfere with the system easilly - currently I experience problems with dnsmasq stealing port 53 when used for KVM as dhcp server. There should definitely be a conversation with the NM people to see how to make things work. Moving to a non-DNSSEC caching local resolver seems to me to be a non-option at this time. Chaining might be an option. Also, unbound has various options to deal with changing ips and dhcp obtained caches (even when they include a mix of dnssec-capable and dnssec-incapable dns servers)
 
[[User:pwouters]] dnsmasq can interfere with the system easilly - currently I experience problems with dnsmasq stealing port 53 when used for KVM as dhcp server. There should definitely be a conversation with the NM people to see how to make things work. Moving to a non-DNSSEC caching local resolver seems to me to be a non-option at this time. Chaining might be an option. Also, unbound has various options to deal with changing ips and dhcp obtained caches (even when they include a mix of dnssec-capable and dnssec-incapable dns servers)
  
- [[User:dcbw]]
+
[[User:dcbw]]
  
 
I'd prefer to use dnsmasq if at all possible, by potentially fixing whatever issues it has with DNSSEC.  While I know BIND can do DNSSEC out of the box it's quite heavy-weight for what we really want it for.  dnsmasq is already deployed pretty much everywhere since it's capable and tiny.
 
I'd prefer to use dnsmasq if at all possible, by potentially fixing whatever issues it has with DNSSEC.  While I know BIND can do DNSSEC out of the box it's quite heavy-weight for what we really want it for.  dnsmasq is already deployed pretty much everywhere since it's capable and tiny.
Line 16: Line 16:
  
 
Second, if somebody could post a config file in which bind has been configured as a fowarding, caching-only nameserver with DNSSEC enabled that would greatly help me.
 
Second, if somebody could post a config file in which bind has been configured as a fowarding, caching-only nameserver with DNSSEC enabled that would greatly help me.
 +
 +
I would recommend to use Unbound for DNSSEC validation, much more easy to configure than BIND. I already had this working locally on my Fedora 14 system by running and configuring Unbound and just changing the name servers in NetworkManager to 127.0.0.1 and ::1 --[[User:Fkooman|Fkooman]] 08:24, 18 February 2011 (UTC)
 +
 +
If NM really wants to validate DNSSEC signatures (as opposed to relying on the ISP's DNS server to validate), then it should presumably use a validating stub resolver.  A validating stub resolver will issue CD requests to the upstream recursive resolver and validate the results using its own trust anchor.  Unfortunately, [http://sourceforge.net/projects/vsresolver/ vsResolver] seems to be the only implementation available, and it doesn't look like it's meant for production use.  Unbound, BIND, and dnsmasq can't do it afaict. [[User:Amluto|Amluto]] 17:46, 27 March 2012 (UTC)

Latest revision as of 17:46, 27 March 2012

- Why is this a checkbox to enable, vs a checkbox to disable? User:notting

User:pwouters If this feature is moved to f15, I suggest a checkbox to disable as well. perhaps f14 can see an update with an enable box?

- I've heard that NM is planning on moving to dnsmasq as a local resolver in the future. This would conflict with that. User:notting

User:pwouters dnsmasq can interfere with the system easilly - currently I experience problems with dnsmasq stealing port 53 when used for KVM as dhcp server. There should definitely be a conversation with the NM people to see how to make things work. Moving to a non-DNSSEC caching local resolver seems to me to be a non-option at this time. Chaining might be an option. Also, unbound has various options to deal with changing ips and dhcp obtained caches (even when they include a mix of dnssec-capable and dnssec-incapable dns servers)

User:dcbw

I'd prefer to use dnsmasq if at all possible, by potentially fixing whatever issues it has with DNSSEC. While I know BIND can do DNSSEC out of the box it's quite heavy-weight for what we really want it for. dnsmasq is already deployed pretty much everywhere since it's capable and tiny.

That said, I'm adding caching nameserver support to NetworkManager right now on the cachingdns branch. dnsmasq support is already written, and I'm working on BIND support right now. I'd prefer if we could set the Fedora NetworkManager to use dnsmasq by default, and if users really want BIND for some reason they could enable that through /etc/NetworkManager/NetworkManager.conf.

I'm also highly allergic to Yet Another Checkbox. If we can avoid adding more UI for this (by turning DNSSEC on by default) then we should do so. However, we first need to determine the failure cases and just how bad they'd be before I'd entertain the idea of adding a UI on/off switch for it.

Second, if somebody could post a config file in which bind has been configured as a fowarding, caching-only nameserver with DNSSEC enabled that would greatly help me.

I would recommend to use Unbound for DNSSEC validation, much more easy to configure than BIND. I already had this working locally on my Fedora 14 system by running and configuring Unbound and just changing the name servers in NetworkManager to 127.0.0.1 and ::1 --Fkooman 08:24, 18 February 2011 (UTC)

If NM really wants to validate DNSSEC signatures (as opposed to relying on the ISP's DNS server to validate), then it should presumably use a validating stub resolver. A validating stub resolver will issue CD requests to the upstream recursive resolver and validate the results using its own trust anchor. Unfortunately, vsResolver seems to be the only implementation available, and it doesn't look like it's meant for production use. Unbound, BIND, and dnsmasq can't do it afaict. Amluto 17:46, 27 March 2012 (UTC)