"bad cache-hit" or "bad-cache hit"

[John Thurston]

Looking in my logs today, I found a confusing line:

    validating cran.rproject.org/SOA: bad cache hit (rproject.org/DS)

I was trying to figure out what was wrong with my cache, and how BIND 
might be able to determine that a cache hit is bad. To do that, it would 
need to retrieve the current value and compare it to the value in cache 
. . and by the time it has done that, why has it bothered to consult the 
cache?


But now I think I may have mis-parsed the line. Maybe it isn't:

    bad cache-hit (i.e. Something was wrong with the cached value)

but is instead:

    bad-cache hit (i.e. We found what we wanted in the cache of bad 
entries)


Can anyone confirm my hypothesis?


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "bad cache-hit" or "bad-cache hit"

[Mark Andrews]

It a hold down cache on bad lookups. The timeout is 10 minutes.  To prove 
whether a zone is secure or not DS records at delegations in the chain are 
looked up. Sometimes that fails. This cache records that failure. 

-- 
Mark Andrews

> On 17 Apr 2024, at 07:03, John Thurston  wrote:
> 
> 
> Looking in my logs today, I found a confusing line:
> 
> validating cran.rproject.org/SOA: bad cache hit (rproject.org/DS)
> 
> I was trying to figure out what was wrong with my cache, and how BIND might 
> be able to determine that a cache hit is bad. To do that, it would need to 
> retrieve the current value and compare it to the value in cache . . and by 
> the time it has done that, why has it bothered to consult the cache?
> 
> But now I think I may have mis-parsed the line. Maybe it isn't:
> 
> bad cache-hit (i.e. Something was wrong with the cached value)
> 
> but is instead:
> 
> bad-cache hit (i.e. We found what we wanted in the cache of bad entries)
> 
> Can anyone confirm my hypothesis?
> 
> 
> 
> -- 
> --
> Do things because you should, not just because you can. 
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Answers for www.dnssec-failed.org with dnssec-validation auto;

[John Thurston]

I'm seeing strange behavior with a BIND 9.18.24 resolver and 
dnssec-failed.org.


With no dnssec-validation line (or with "dnssec-validation auto") in the 
.conf, querying for www.dnssec-failed.org returns SERVFAIL, as expected 
. . until it doesn't. After several seconds of answering SERVFAIL, I 
start getting NOERROR responses, and IP addresses in the ANSWER. It 
isn't a predictable number of seconds; sometimes 9, sometimes 20.


Is this supposed to be happening?

When I examine the process with delv and my eyeballs, I can't see why it 
is succeeding with dig and my validating resolver.


Maybe I'm not looking for the right things with my eyeballs? I'm 
stumped, and looking for advice for nest-steps in understanding what's 
going on.



The following one-liner:

# rndc flush && while true; do dig -4 www.dnssec-failed.org. A 
@localhost; sleep 1; done


Results in answers like:


; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62774
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9fd5ae2d4566c51d0100661f07f2bfc240421b91f851 (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN  A

;; Query time: 237 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Tue Apr 16 15:21:22 AKDT 2024
;; MSG SIZE  rcvd: 78


; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7693
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 90175bca7b323c830100661f07f3467dc5a561eb4f77 (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN  A

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Tue Apr 16 15:21:23 AKDT 2024
;; MSG SIZE  rcvd: 78

--- after ~20 more like those ---


; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34572
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 60f5a11077dc97240100661f0809905b6096fd5e287a (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN  A

;; ANSWER SECTION:
www.dnssec-failed.org.  7199    IN  A   68.87.109.242
www.dnssec-failed.org.  7199    IN  A   69.252.193.191

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Tue Apr 16 15:21:45 AKDT 2024
;; MSG SIZE  rcvd: 110


; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2987
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 89a4502552606c370100661f080a5dd5f9299ddb95fe (good)
;; QUESTION SECTION:
;www.dnssec-failed.org. IN  A

;; ANSWER SECTION:
www.dnssec-failed.org.  7198    IN  A   68.87.109.242
www.dnssec-failed.org.  7198    IN  A   69.252.193.191

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Tue Apr 16 15:21:46 AKDT 2024
;; MSG SIZE  rcvd: 110



--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users