Trusted upstream resolver

[W.C.A. Wijngaards]

-----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.

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-----