-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Patrik,
On 08/21/2015 05:14 PM, Patrik Lundin via Unbound-users wrote: > Hello, > > I recently noticed what to me is a strange caching behaviour for > NXDOMAIN results. > > This has been seen both on Ubuntu 14.04 with unbound 1.4.22 and on > OpenBSD with unbound 1.5.2. > > I noticed that for some domains, the cache TTL for NXDOMAIN > results seemed to be shared for all nonexistant replies under that > domain: This is because the RRset cache is shared between answers. The SOA record is in that cache. When you query the second time, unbound detects that the SOA record has not changed, and therefore keeps timing out the existing SOA record. And then you get a lower TTL, of that SOA record, when you query again. This is because of cache update rules, which are complicated. We want to time out existing records, so that we look them up again when they expire. If the newer SOA record was different (i.e. contained different data), it would have been updated. These cache update rules are set to stop eg. cache poisoning, and the resolver sticking to an old nameserver after a nameserver change. (the exact negative TTL has seen fixes recently, eg. with a max negative ttl unbound.conf setting, and depends on what the authority server sent). Best regards, Wouter > > The first lookup (which also suspiciously seems to use the SOA TTL > of 7200 rather than the NXDOMAIN TTL of 18000): === dig > nonexistant1.unbound.net > > ; <<>> DiG 9.4.2-P2 <<>> nonexistant1.unbound.net ;; global > options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > status: NXDOMAIN, id: 35933 ;; flags: qr rd ra; QUERY: 1, ANSWER: > 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;nonexistant1.unbound.net. IN A > > ;; AUTHORITY SECTION: unbound.net. 7200 IN SOA > ns.nlnetlabs.nl. postmaster.unbound.net. 2015081500 28800 7200 > 604800 18000 > > ;; Query time: 474 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; > WHEN: Fri Aug 21 16:51:23 2015 ;; MSG SIZE rcvd: 104 === > > The second lookup for that same name, which as one would expect has > a decremented TTL: === $ dig nonexistant1.unbound.net > > ; <<>> DiG 9.4.2-P2 <<>> nonexistant1.unbound.net ;; global > options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > status: NXDOMAIN, id: 9365 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, > AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;nonexistant1.unbound.net. IN A > > ;; AUTHORITY SECTION: unbound.net. 7195 IN SOA > ns.nlnetlabs.nl. postmaster.unbound.net. 2015081500 28800 7200 > 604800 18000 > > ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; > WHEN: Fri Aug 21 16:51:28 2015 ;; MSG SIZE rcvd: 104 === > > Now we look up another nonexistant domain, which I would expect to > have a TTL of 7200 (18000?), but this one shares the reported TTL > with my previous lookup: === $ dig nonexistant2.unbound.net > > ; <<>> DiG 9.4.2-P2 <<>> nonexistant2.unbound.net ;; global > options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > status: NXDOMAIN, id: 27898 ;; flags: qr rd ra; QUERY: 1, ANSWER: > 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: ;nonexistant2.unbound.net. IN A > > ;; AUTHORITY SECTION: unbound.net. 7189 IN SOA > ns.nlnetlabs.nl. postmaster.unbound.net. 2015081500 28800 7200 > 604800 18000 > > ;; Query time: 32 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; > WHEN: Fri Aug 21 16:51:34 2015 ;; MSG SIZE rcvd: 104 === > > Does anyone else see this? Is it by design? What makes this even > more confusing to me is that I see different results for different > domains. I believe I am even seeing different results inside the > same domains possibly depending on what I have looked up before > that. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV15R+AAoJEJ9vHC1+BF+NJHEP/RDSz0zGIE8pTRHoZ2osjeoA G/IjstXLQgEk4cFawsH5gEwUAJ7tJx4FiGUJJhfy9IG0W+mSOJw/MDECKwb/Ad39 AwXO+ZJ+h24+QfTWAO/I9tyJwbD9+BOVtKv/i580R8p7Y42l2M3FdBgAqkkLH8Vc O7GyO6AWJNulXAfLSwG+QTk8z7HJj0YHWVxAFcJQV4q2N+kqZpOpoffASWqSWtkC k7rSWRD2qLKdYX5+CDK99xKw1LHVL9Ncczp/vaUZHul9++e/RRvmoBqbjbUeo0Ar NXPWaAYHWuwswN6o4D0pc78O11kSz8GzVAHVCOi0E4ovBUA1Z4cTnHvhmuKMXZZH wYGaFeLd+MhZOAU5Y4+JtNgq5LTsOeUjfSt8FTrAArAPJj9z9yIa9pWAEMdDEPYg YInb9x5vo2BQ9KBdyZngSU/bQ1Oyu317Gcfp5WygD0FyLAIT0pVLAN7UVVJMHqy2 Btl5kh9OhH85oYEuRIKX2IBSf4EIP3NHyo9pGPp+U81vknkYdyQFPyrxUOooX4B4 OoYafObLkOzAsE4WF3+kdZ+h1g0Q12FIzGvuW2wFiQudrC5/101QT8wVSs75gH7J xDf7KRIhld0DtDcfXP2or/fVNi1yI3zTboNA0IW6hOdnnxu2ouPSt4Cus1ersMmx fIo4PDhO89uHCS8OVfi4 =6ERn -----END PGP SIGNATURE-----
