1.1.1.1 high TTL when serving stale answers

[vcunat]

I randomly ran into these super-high TTL values:

$ kdig @1.1.1.1 ec.europa.eu +nsid
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 48470
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; NSID: 37316D363936 "71m696"
;; EDE: 3 (Stale Answer)

;; QUESTION SECTION:
;; ec.europa.eu.                A

;; ANSWER SECTION:
ec.europa.eu.           4294961904      RRSIG   A 8 3 300 20211230040524 20211130033246 64599 europa.eu. [omitted]
ec.europa.eu.           4294961904      A       147.67.210.30
ec.europa.eu.           4294961904      A       147.67.34.30

;; Received 386 B
;; Time 2021-12-08 15:03:12 CET
;; From [email protected](UDP) in 13.4 ms

Such high values are not even allowed. I don’t know if this is some special case or a bug in all stale-serving. /cc @mvavrusa, I suppose.

[vcunat]

Sometimes I see more EDEs in these answers, e.g.

;; EDE: 3 (Stale Answer)
;; EDE: 6 (DNSSEC Bogus)
;; EDE: 22 (No Reachable Authority)

[vcunat]

And I can confirm that there were some BOGUS problems in their zone today, which triggered my queries.

[anb]

Hi @vcunat, did you see the big TTL even when the answer was not stale?

[vcunat]

No, I haven’t noticed such a case. I think that even at that very same moment, some identical queries going to 1.1.1.1 got answered as non-stale with normal low TTL.