Trusted upstream resolver

[Woodworth, John R]

> -----Original Message-----
> From: Unbound-users [mailto:unbound-users-bounces at unbound.net] On Behalf Of W.C.A. Wijngaards via Unbound-users
> Sent: Wednesday, November 04, 2015 2:15 AM
> To: unbound-users at unbound.net
> Subject: Re: Trusted upstream resolver
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Dave,
>
> On 11/03/2015 10:04 PM, Dave Warren via Unbound-users wrote:
> > On 2015-11-03 05:57, W.C.A. Wijngaards via Unbound-users wrote:
> >> 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.