Description of problem: IP address to name resolution doesn't work if fallback servers are used. Version-Release number of selected component (if applicable): dnssec-trigger-0.12-12.fc20.x86_64 How reproducible: 100 % Steps to Reproduce: 1. Connect to a network which doesn't have DNSSEC-enabled servers. 2. Try to resolve some IP address to host name, e.g. $ dig -x 10.36.4.194 Actual results: Query is forwarded to fallback servers which doesn't make sense. Fallback (public) servers will always return NXDOMAIN answer. Expected results: Queries for in-addr.arpa and some subset of ip6.arpa should be forwarded to local servers even if they don't support DNSSEC. For those zones it is not possible to get any sensible reply from public servers on Internet. Additional info: http://tools.ietf.org/html/rfc6303#section-4 contains list of zones which should be handled in this way.
Maybe it would be valuable to set forwarding for TLDs 'test' and 'example' because those two also have only local significance. http://tools.ietf.org/html/rfc6761#section-6.2 http://tools.ietf.org/html/rfc6761#section-6.5
I'd be tempted to let those be handled by AS112. unbound already adds the AS112 domains as default local-zone: entries.. http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-04 https://www.as112.net/ The problem of handling .example, etc is that you would need a sensible place to forward these to. Back to the original problem, perhaps local-zone: entries are ignored when forwarding ".". But that is what I would expect to happen to if I connect to a LAN that uses 10.* and that I use its DNS server with. those 10.* reverse entries will then make it to the local server responsble for those entries. it would get complicated if we try to forward those (obviously untrusted!) RFC1918 reverse ranges to the "insecure" or "broken" server. I'll talk to upstream and get their opinion on this, Paul
(In reply to Paul Wouters from comment #2) > I'd be tempted to let those be handled by AS112. unbound already adds the > AS112 domains as default local-zone: entries.. > > http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-04 > https://www.as112.net/ > > The problem of handling .example, etc is that you would need a sensible > place to forward these to. My understanding is that 'test.' can be used by local site for it's own purposes, e.g. software development. For this reason I'm proposing to forward 'test.' queries to local server (i.e. do the same thing as with private IP ranges). Forwarding 'example.' to local server is just an cache optimization (because NXDOMAIN will be centrally cached) but the same thing can be achieved by local-zone: configuration. > Back to the original problem, perhaps local-zone: entries are ignored when > forwarding ".". But that is what I would expect to happen to if I connect to > a LAN that uses 10.* and that I use its DNS server with. those 10.* reverse > entries will then make it to the local server responsble for those entries. I agree with your analysis - that is exactly the reason why I opened this bug. > it would get complicated if we try to forward those (obviously untrusted!) > RFC1918 reverse ranges to the "insecure" or "broken" server. Please correct me if I'm wrong but I think that it is impossible to have DNSSEC-secured reverse zones for private IP ranges without *explicit* trust anchors on the client, right? I.e. requiring DNSSEC for those domains (again - without explicit trust anchor) doesn't make sense because those domains can't have sensible DS records in in-addr.arpa. Please correct me if I'm wrong.
I would guess this is not only about special addresses but also about the local address range. The problem is that the local (organization scope) address range is generally not known to the configuration service as it is handled by the default route as any other traffic. Any suggestions?
If the local forwarder is not dnssec-broken, and won't get rejected by dnssec-trigger, there is no problem. If the local forwarder is dnssec-broken, we have a problem. We cannot use it for non-local dnssec resolving and we don't really know the difference between local and non-local on our client. We could add some NM option, but I'd prefer not to have too many knobs for people to tweak. I would say the easiest solution in this case is to fix the broken local forwarder. The user can override with dnssec-trigger to go "insecure", which will result in working with the local broken forwarder but having been informed that they are now no longer protected with DNSSEC. Note that the original bug report has an error. It states: 1. Connect to a network which doesn't have DNSSEC-enabled servers. That is actually not the real problem. You can run bind or unbound or whatever without enabling DNSSEC, as long as you comply with the RFCs for forwarding records (eg forward unvalidated RRSIGs). So what you really mean is: 1. Connect to a network with a non-RFC compliant DNS server (like bind4) I guess what I'm saying is that this is a nonbug in my view.
(In reply to Paul Wouters from comment #5) > If the local forwarder is not dnssec-broken, and won't get rejected by > dnssec-trigger, there is no problem. > > If the local forwarder is dnssec-broken, we have a problem. We cannot use it > for non-local dnssec resolving and we don't really know the difference > between local and non-local on our client. We could add some NM option, but This is the point where we don't agree with each other: "we don't really know the difference between local and non-local on our client." It seems to be clear to me when it comes to private IP ranges in in-addr.arpa. sub-tree. Private IP ranges are well defined in RFCs and cannot be used on public Internet anyway. Why don't handle them as "local"? > I'd prefer not to have too many knobs for people to tweak. I would say the I agree that too many knobs is not what we want. This should work automatically. > easiest solution in this case is to fix the broken local forwarder. The user Oh yes, we should scream loudly if the local DNS forwarder is broken. Maybe we could show GUI pop-up when dnssec-broken forwarder is detected? > can override with dnssec-trigger to go "insecure", which will result in > working with the local broken forwarder but having been informed that they > are now no longer protected with DNSSEC. Speaking strictly about private sub-trees - there is *no* DNSSEC protection if trust anchors were not configured manually. From my point of view this proposal makes situation only better because security properties stays the same (no DNSSEC) but the resolution actually works :-) What did I miss? > Note that the original bug report has an error. It states: > > 1. Connect to a network which doesn't have DNSSEC-enabled servers. > > That is actually not the real problem. You can run bind or unbound or > whatever without enabling DNSSEC, as long as you comply with the RFCs for > forwarding records (eg forward unvalidated RRSIGs). So what you really mean > is: > > 1. Connect to a network with a non-RFC compliant DNS server (like bind4) I agree that your wording is better.
(In reply to Petr Spacek from comment #6) > Private IP ranges are well defined in RFCs and cannot be used on public > Internet anyway. Why don't handle them as "local"? +1 > Oh yes, we should scream loudly if the local DNS forwarder is broken. Maybe > we could show GUI pop-up when dnssec-broken forwarder is detected? I think we should only scream loudly in situations not handled gracefully. But it would be nice to use a different icon when fallback is used than when everything works out of the box and dnssec-trigger would theoretically not be needed (except that it's needed to detect that it is the situation and that it carries the nm/unbound integration script). > > 1. Connect to a network with a non-RFC compliant DNS server (like bind4) > I agree that your wording is better. +1
Created attachment 983074 [details] patch to use reverse zones from connections It is not perfect in that it doesn't handle any other addresses than those in the same network as the assigned IP address. But it's better than nothing. Please review and please let me know about any ideas on how to do this better. I'm considering making it the default behavior (as in the patch).
IMHO we could make it more straightforward and simply configure forwarding for all private IP address ranges to servers anounced by DHCP and disable DNSSEC validation for them by default. There is absolutely no point in querying public servers for in-addr.arpa records related to private IP ranges and also there is no way how you can publish zone's DNSKEY in parent zone.
(In reply to Petr Spacek from comment #9) > IMHO we could make it more straightforward and simply configure forwarding > for all private IP address ranges to servers anounced by DHCP and disable > DNSSEC validation for them by default. Where would we forward them? Simply via the default route to avoid the fallback? What if we're connected to multiple network with different ranges. I know it's not 100% but this would at least catch the directly connected hosts which is often what you want to do. We might want to use the two approaches in combination but that is a bit more tricky. > There is absolutely no point in querying public servers for in-addr.arpa > records related to private IP ranges and also there is no way how you can > publish zone's DNSKEY in parent zone. Agreed.
(In reply to Pavel Šimerda (pavlix) from comment #10) > (In reply to Petr Spacek from comment #9) > Where would we forward them? Simply via the default route to avoid the > fallback? What if we're connected to multiple network with different ranges. > I know it's not 100% but this would at least catch the directly connected > hosts which is often what you want to do. > > We might want to use the two approaches in combination but that is a bit Yes, a combination will be the best available option I guess. Maybe we can try some magic like this: local IP address is 192.168.2.1/24 -> this is from private IP block 192.168.0.0/16 -> forward all queries related to 192.168.0.0/16 to local server. VPN network is 10.11.12.13/24 -> -> this is from private IP block 10.0.0.0/8 -> forward all queries related to 10.0.0.0/8 to DNS servers given out by VPN. This can be further optimized by more forwarding forwarding for directly connected subnets - that would catch some cases where VPN and local network use the same private IP block ... but in these cases you will likely face routing problem in IP layer anyway so I do not think we have to solve this case super-precisely.
Created attachment 983281 [details] patch to use reverse zones from connections Patch cleaned up, off by default so that we test it first.
Created attachment 983296 [details] proof of concept patch to support rfc1918 zones This patch is not yet finished but shows how the private IP reverse zones would be done.
Created attachment 984167 [details] patch to support rfc1918 based reverse zones Let's be happy with RFC1918 stuff for now. Per-address reverse name resolution forward zones are a bit more complicated due to the variability of network prefix lengths.
dnssec-trigger-0.12-18.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-18.fc21
Package dnssec-trigger-0.12-18.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-18.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1279/dnssec-trigger-0.12-18.fc21 then log in and leave karma (feedback).
dnssec-trigger-0.12-19.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-3864/dnssec-trigger-0.12-19.fc22
dnssec-trigger-0.12-19.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2015-3843/dnssec-trigger-0.12-19.fc21
dnssec-trigger-0.12-19.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Reopening, as the functionality does not work at all! The forward zones are added, however these are useless because unbound responds always with NXDOMAIN. This is due to the fact, that by default unbound has AS112 zones configured as static ~ meaning it will answer with NXDOMAIN for all Queries.
Patch sent to the upstream.
dnssec-trigger-0.12-20.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-20.fc21
Package dnssec-trigger-0.12-20.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-20.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-5821/dnssec-trigger-0.12-20.fc21 then log in and leave karma (feedback).
dnssec-trigger-0.12-20.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dnssec-trigger-0.12-20.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.