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