Bug 1128310 - in-addr.arpa queries for private IP ranges doesn't work if fallback servers are used
Summary: in-addr.arpa queries for private IP ranges doesn't work if fallback servers a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnssec-trigger
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
Assignee: Tomáš Hozza 🤓
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-08 22:06 UTC by Petr Spacek
Modified: 2015-04-21 18:48 UTC (History)
5 users (show)

Fixed In Version: dnssec-trigger-0.12-20.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-18 09:32:23 UTC


Attachments (Terms of Use)
patch to use reverse zones from connections (3.35 KB, patch)
2015-01-22 21:20 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff
patch to use reverse zones from connections (3.39 KB, patch)
2015-01-23 10:35 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff
proof of concept patch to support rfc1918 zones (2.42 KB, patch)
2015-01-23 10:51 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff
patch to support rfc1918 based reverse zones (6.81 KB, patch)
2015-01-26 11:20 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff

Description Petr Spacek 2014-08-08 22:06:37 UTC
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.

Comment 1 Petr Spacek 2014-08-11 12:19:59 UTC
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

Comment 2 Paul Wouters 2014-08-11 15:17:45 UTC
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

Comment 3 Petr Spacek 2014-08-12 07:05:23 UTC
(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.

Comment 4 Pavel Šimerda (pavlix) 2014-08-13 20:16:40 UTC
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?

Comment 5 Paul Wouters 2014-08-13 23:53:18 UTC
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.

Comment 6 Petr Spacek 2014-08-14 10:58:32 UTC
(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.

Comment 7 Pavel Šimerda (pavlix) 2014-08-14 16:29:43 UTC
(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

Comment 8 Pavel Šimerda (pavlix) 2015-01-22 21:20:50 UTC
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).

Comment 9 Petr Spacek 2015-01-23 08:53:35 UTC
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.

Comment 10 Pavel Šimerda (pavlix) 2015-01-23 09:00:34 UTC
(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.

Comment 11 Petr Spacek 2015-01-23 09:14:46 UTC
(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.

Comment 12 Pavel Šimerda (pavlix) 2015-01-23 10:35:32 UTC
Created attachment 983281 [details]
patch to use reverse zones from connections

Patch cleaned up, off by default so that we test it first.

Comment 13 Pavel Šimerda (pavlix) 2015-01-23 10:51:59 UTC
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.

Comment 14 Pavel Šimerda (pavlix) 2015-01-26 11:20:31 UTC
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.

Comment 15 Fedora Update System 2015-01-26 20:47:39 UTC
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

Comment 16 Fedora Update System 2015-01-28 19:56:07 UTC
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).

Comment 17 Fedora Update System 2015-03-17 11:06:52 UTC
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

Comment 18 Fedora Update System 2015-03-17 11:07:08 UTC
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

Comment 19 Fedora Update System 2015-03-26 22:04:24 UTC
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.

Comment 20 Tomáš Hozza 🤓 2015-04-07 12:42:48 UTC
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.

Comment 21 Tomáš Hozza 🤓 2015-04-08 12:38:01 UTC
Patch sent to the upstream.

Comment 22 Fedora Update System 2015-04-08 16:32:02 UTC
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

Comment 23 Fedora Update System 2015-04-09 09:09:48 UTC
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).

Comment 24 Fedora Update System 2015-04-18 09:32:23 UTC
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.

Comment 25 Fedora Update System 2015-04-21 18:48:56 UTC
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.


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