Trusted upstream resolver

Unbound
1

Hello,

I am involved in a scenario where a satellite link is being used to serve an office and latency is of great concern.

The problem at hand is CNAME resolution which is followed by validation of provided A records. I understand that under normal conditions the A records provided with the initial CNAME response can lead to cache poisoning so they are validated from an authority. However, this leads to doubling the lookup time which typically exceeds 1.5 seconds. Although the difference may seem trivial the additional ~650ms becomes very noticeable by the end users. I’ve provided a short example below.

0.001 [Client]->[Resolver]->A?www.example.com

0.002 [Resolver]->X[Auth]->A?www.example.com

0.758 [Auth]->X[Resolver]->CNAME:www2.example.com+1.2.3.4

0.761 [Resolver]->X[Auth]->A?www2.example.com

1.622 [Auth]->X[Resolver]->A:1.2.3.4

1.625 [Resolver]->[Client]->A:1.2.3.4

NOTE: X == Satellite Link

My thought is to use another nameserver at the other end of the link which can provide this validation feature but is “trusted” by the near-end nameserver server reducing the RTT for local clients. As an aside, the far-end nameserver already exists for other purposes. I’ve provided a short example of this idea below.

0.001 [Client]->[Resolver]->A?www.example.com

0.002 [Resolver]->X[Resolver2]->A?www.example.com

0.288 [Resolver2]->[Auth]->A?www.example.com

0.290 [Auth]->[Resolver2]->CNAME:www2.example.com+1.2.3.4

0.292 [Resolver2]->[Auth]->A?www2.example.com

0.301 [Auth]->[Resolver2]->A:1.2.3.4

0.655 [Resolver2]->X[Resolver]->A:1.2.3.4

0.659 [Resolver]->[Client]->A:1.2.3.4

NOTE: X == Satellite Link

Is there a configuration option I am overlooking to disable these A record validations (from Resolver to Resolver2)?

Thanks,

John

2

Hi John,

Hello,

I am involved in a scenario where a satellite link is being used
to serve an office and latency is of great concern.

The problem at hand is CNAME resolution which is followed by
validation of provided A records. I understand that under normal
conditions the A records provided with the initial CNAME response
can lead to cache poisoning so they are validated from an
authority. However, this leads to doubling the lookup time which
typically exceeds 1.5 seconds. Although the difference may seem
trivial the additional ~650ms becomes very noticeable by the end
users. I’ve provided a short example below.

0.001 [Client]->[Resolver]->A?www.example.com

0.002 [Resolver]->X[Auth]->A?www.example.com

0.758 [Auth]->X[Resolver]->CNAME:www2.example.com+1.2.3.4

0.761 [Resolver]->X[Auth]->A?www2.example.com

1.622 [Auth]->X[Resolver]->A:1.2.3.4

1.625 [Resolver]->[Client]->A:1.2.3.4

NOTE: X == Satellite Link

My thought is to use another nameserver at the other end of the
link which can provide this validation feature but is “trusted” by
the near-end nameserver server reducing the RTT for local clients.
As an aside, the far-end nameserver already exists for other
purposes. I’ve provided a short example of this idea below.

0.001 [Client]->[Resolver]->A?www.example.com

0.002 [Resolver]->X[Resolver2]->A?www.example.com

0.288 [Resolver2]->[Auth]->A?www.example.com

0.290
[Auth]->[Resolver2]->CNAME:www2.example.com+1.2.3.4

0.292 [Resolver2]->[Auth]->A?www2.example.com

0.301 [Auth]->[Resolver2]->A:1.2.3.4

0.655 [Resolver2]->X[Resolver]->A:1.2.3.4

0.659 [Resolver]->[Client]->A:1.2.3.4

NOTE: X == Satellite Link

Is there a configuration option I am overlooking to disable these
A record validations (from Resolver to Resolver2)?

No, there is no option to disable the CNAME checks. The trust in the
other nameserver is by the way not enough reason to have used such an
option, it is protection against inserted spoofed packets here that
has mandated the checks.

Consider enabling prefetch: yes (and prefetch-key: yes) in
unbound.conf, for commonly asked queries that will make it prefetch a
couple seconds before expiry to refresh the cache entry, and that
should be enough to hide this latency for a larger number of queries.

Another option, but less desirable, is cache-min-ttl where you can
force entries to stay in the cache for a longer time (i.e. that CNAME
was from a CDN with very short TTLs).

Best regards, Wouter

3

No, there is no option to disable the CNAME checks. The trust in the
other nameserver is by the way not enough reason to have used such an
option, it is protection against inserted spoofed packets here that
has mandated the checks.

I'm having trouble wrapping my head around this one, why are CNAMEs different in regards to spoofing?

I understand why the resolver wants to do sanity-checking, but are these records more vulnerable to spoofing than in the general case of trusting an upstream resolver implicitly?

Consider enabling prefetch: yes (and prefetch-key: yes) in
unbound.conf, for commonly asked queries that will make it prefetch a
couple seconds before expiry to refresh the cache entry, and that
should be enough to hide this latency for a larger number of queries.

When I was in a similar situation a few months back, prefetching made a *big* difference. However, only for names that are accessed by multiple clients. There were cases where one client was frequently accessing the same resource (but no others) and these still expired without getting prefetched due to the client side caching.

Such is life.

Another option, but less desirable, is cache-min-ttl where you can
force entries to stay in the cache for a longer time (i.e. that CNAME
was from a CDN with very short TTLs).

Within a very reasonable ceiling. Perhaps 300 seconds might be the largest cache-min-TTL that one might consider.

4

Hi Dave,

No, there is no option to disable the CNAME checks. The trust in
the other nameserver is by the way not enough reason to have used
such an option, it is protection against inserted spoofed packets
here that has mandated the checks.

I'm having trouble wrapping my head around this one, why are
CNAMEs different in regards to spoofing?

Because of the spoof from Kaminsky; the CNAME can be abused.
Basically, it uses the indirection of the CNAME to poison a different
target than the one queried for and that enables a birthday-paradox
exploit.

I do not know how else to fix this, except worry that the future holds
even more latency; for EDNS-option negotiation, for TCP and encryption
handshakes... You could forward the domain names that are troubling
to a secondary cache, with a very large cache-min-ttl (and prefetch),
so that they are resolved from cache, but that sounds hacky.

Best regards, Wouter

5

From: Unbound-users [mailto:unbound-users-bounces@unbound.net] On Behalf Of W.C.A. Wijngaards via Unbound-users
Sent: Wednesday, November 04, 2015 2:15 AM
To: unbound-users@unbound.net
Subject: Re: Trusted upstream resolver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave,

>> No, there is no option to disable the CNAME checks. The trust in the
>> other nameserver is by the way not enough reason to have used such an
>> option, it is protection against inserted spoofed packets here that
>> has mandated the checks.
>
> I'm having trouble wrapping my head around this one, why are CNAMEs
> different in regards to spoofing?

Because of the spoof from Kaminsky; the CNAME can be abused.
Basically, it uses the indirection of the CNAME to poison a different
target than the one queried for and that enables a birthday-paradox exploit.

I do not know how else to fix this, except worry that the future holds
even more latency; for EDNS-option negotiation, for TCP and encryption
handshakes... You could forward the domain names that are troubling to a
secondary cache, with a very large cache-min-ttl (and prefetch), so that
they are resolved from cache, but that sounds hacky.

Dave, Wouter; Thanks for the feedback. I guess I was looking for some sort
of hybrid proxy which would simply forward the client's request to an
upstream resolver acting as a stub and return the response back to its
clients as if it did the lookup itself. This hybrid proxy would then
cache the results but since it thinks of itself as a stub resolver would
not need to perform such tasks as CNAME validation itself as its upstream
nameserver already did this.

Prefetch may help with the overall issue but I keep circling back to the
one query/ one response model I have in my mind. I have looked around
a bit and was really hoping unbound would be able to fit the need with
some something simple like a configuration option but looks like I will
need to continue with my investigation.

Thanks again,
John

Best regards, Wouter

>
> I understand why the resolver wants to do sanity-checking, but are
> these records more vulnerable to spoofing than in the general case of
> trusting an upstream resolver implicitly?
>
>> Consider enabling prefetch: yes (and prefetch-key: yes) in
>> unbound.conf, for commonly asked queries that will make it prefetch a
>> couple seconds before expiry to refresh the cache entry, and that
>> should be enough to hide this latency for a larger number of queries.
>
> When I was in a similar situation a few months back, prefetching made
> a *big* difference. However, only for names that are accessed by
> multiple clients. There were cases where one client was frequently
> accessing the same resource (but no others) and these still expired
> without getting prefetched due to the client side caching.
>
> Such is life.
>
>> Another option, but less desirable, is cache-min-ttl where you can
>> force entries to stay in the cache for a longer time (i.e.
>> that CNAME was from a CDN with very short TTLs).
>
> Within a very reasonable ceiling. Perhaps 300 seconds might be the
> largest cache-min-TTL that one might consider.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWObBeAAoJEJ9vHC1+BF+NJ2QP/jBPNbnVqQrY2Y24hIFCjlIv
964fm8EzKDDotmREKSMKuiNai/rTsmApSTs8o8a07m4wU8ttWKmOReZqYglUSXUn
4Q4qiHim+3g4V2pX4RmzJMH9/eEyacPoKsJkiDQCRybbdOF0x+DtJMjwlUOqluVn
rKFBBJCW1GYmzM9Xkx/qfgnp9hR5ei62Wl4+6oZNYcKMmeO38VJXhFc8y+52OmU+
fBh0iuWTLkw4IMrjk5t5YZnSQT/I4wlty65Hu8cFJaPbjWemQizq+fn2EkSNowD6
gOcScmFbFBqrjhgJcxftnGFGoGFoGCgYTJMeTKGVfz3QRhu7BCoF4yMe3LeXEAWn
xdH/wpXYvHJXh0inSH3bk06OBoNKCtmZZf2h8lpJ12z2dq43u5EN1V//XCOmOJ83
U83XaDJv3PG9KFIRfLMLgbyhtPfug7LSrxEkfw1NxilSnRRTgL1M1JDNKBxP1dGM
pXQ7ECt1yy2bOkZjr3bGiJ3l6Sv+pDsdGCkpbafs/SJmDDzirpmrUSeTvH+JBa2K
N56pFmfHjwMZtlDxpx4sws9pAUu/vAAIlAwyRs4jmwWouifGlBzForhMYgJ4s9dC
NeDZ8pKmCxBAlGYGZIvEOYWJTZEcVyiQhvZYcXP+oVILEfi3naC7w5LJjpeDRXFh
MkSVTNItsqTdYc0RbViR
=VFH2
-----END PGP SIGNATURE-----

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.