New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PDNS Recursor - No cache hit found although cache entry is present #6340

Closed
carlos-n opened this Issue Mar 13, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@carlos-n

carlos-n commented Mar 13, 2018

  • Program: Recursor
  • Issue type: Bug report

Short description

Answers are not chached when forwarding queries using "forward-zones-recurse".

Environment

  • Operating system: Centos 7.4
  • Software version: 4.1.1
  • Software source: pdns-recursor-4.1.1-1pdns.el7.x86_64

Steps to reproduce

  1. We have forward-zones-recurse=.=8.8.8.8 configured in our recursor. We use this configuration because we have limited access to internet from our recursor and thus we wouldn't be able to do the recursion ourselves.
  2. We try to resolve "wikipedia.com".
  3. We receive the answer and our cache is updated.
; <<>> DiG 9.9.3 <<>> @10.0.3.204 wikipedia.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36999
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wikipedia.com.                 IN      A

;; ANSWER SECTION:
wikipedia.com.          599     IN      A       91.198.174.192

;; Query time: 41 msec
;; SERVER: 10.0.3.204#53(10.0.3.204)
;; WHEN: Thu Mar 16 04:45:26 CET 2017
;; MSG SIZE  rcvd: 58


; main record cache dump from thread follows
;
a.root-servers.net. 3599580 IN A 198.41.0.4 ; (Insecure) auth=1
a.root-servers.net. 3599580 IN AAAA 2001:503:ba3e::2:30 ; (Insecure) auth=1
b.root-servers.net. 3599580 IN A 199.9.14.201 ; (Insecure) auth=1
b.root-servers.net. 3599580 IN AAAA 2001:500:200::b ; (Insecure) auth=1
c.root-servers.net. 3599580 IN A 192.33.4.12 ; (Insecure) auth=1
c.root-servers.net. 3599580 IN AAAA 2001:500:2::c ; (Insecure) auth=1
d.root-servers.net. 3599580 IN A 199.7.91.13 ; (Insecure) auth=1
d.root-servers.net. 3599580 IN AAAA 2001:500:2d::d ; (Insecure) auth=1
e.root-servers.net. 3599580 IN A 192.203.230.10 ; (Insecure) auth=1
e.root-servers.net. 3599580 IN AAAA 2001:500:a8::e ; (Insecure) auth=1
f.root-servers.net. 3599580 IN A 192.5.5.241 ; (Insecure) auth=1
f.root-servers.net. 3599580 IN AAAA 2001:500:2f::f ; (Insecure) auth=1
g.root-servers.net. 3599580 IN A 192.112.36.4 ; (Insecure) auth=1
g.root-servers.net. 3599580 IN AAAA 2001:500:12::d0d ; (Insecure) auth=1
h.root-servers.net. 3599580 IN A 198.97.190.53 ; (Insecure) auth=1
h.root-servers.net. 3599580 IN AAAA 2001:500:1::53 ; (Insecure) auth=1
i.root-servers.net. 3599580 IN A 192.36.148.17 ; (Insecure) auth=1
i.root-servers.net. 3599580 IN AAAA 2001:7fe::53 ; (Insecure) auth=1
j.root-servers.net. 3599580 IN A 192.58.128.30 ; (Insecure) auth=1
j.root-servers.net. 3599580 IN AAAA 2001:503:c27::2:30 ; (Insecure) auth=1
k.root-servers.net. 3599580 IN A 193.0.14.129 ; (Insecure) auth=1
k.root-servers.net. 3599580 IN AAAA 2001:7fd::1 ; (Insecure) auth=1
l.root-servers.net. 3599580 IN A 199.7.83.42 ; (Insecure) auth=1
l.root-servers.net. 3599580 IN AAAA 2001:500:9f::42 ; (Insecure) auth=1
m.root-servers.net. 3599580 IN A 202.12.27.33 ; (Insecure) auth=1
m.root-servers.net. 3599580 IN AAAA 2001:dc3::35 ; (Insecure) auth=1
. 85980 IN NS c.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS d.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS a.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS i.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS f.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS g.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS b.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS e.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS j.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS h.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS k.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS m.root-servers.net. ; (Indeterminate) auth=0
. 85980 IN NS l.root-servers.net. ; (Indeterminate) auth=0
recursor-4.1.1.security-status.secpoll.powerdns.com. -361 IN TXT "1 OK" ;
(Indeterminate) auth=0
wikipedia.com. 573 IN A 91.198.174.192 ; (Indeterminate) auth=0
; negcache dump from thread follows
;
; main packet cache dump from thread follows
;

Expected behaviour

We expect the following requests to "wikipedia.com" to be answered from cache until TTL expires.

Actual behaviour

The following attempts to resolve "wikipedia.com" are not answered form
cache and pdns-recursor goes always to 8.8.8.8 to provide an answer.

0 [18/1] question for 'wikipedia.com|A' from 10.0.3.200
[18] wikipedia.com: Wants NO DNSSEC processing, auth data in query for A
[18] wikipedia.com: Looking for CNAME cache hit of 'wikipedia.com|CNAME'
[18] wikipedia.com: No CNAME cache hit of 'wikipedia.com|CNAME' found
[18] wikipedia.com: No cache hit for 'wikipedia.com|A', trying to find an
appropriate NS record
[18] : got TA for '.'
[18] : setting cut state for . to Secure
[18] wikipedia.com: initial validation status for wikipedia.com is
Indeterminate
[18] wikipedia.com: Cache consultations done, have 1 NS to contact
[18] wikipedia.com: Domain has hardcoded nameserver
[18] wikipedia.com: Resolved '.' NS (empty) to: 8.8.8.8
[18] wikipedia.com: Trying IP 8.8.8.8:53, asking 'wikipedia.com|A'
[18] wikipedia.com: Got 2 answers from (empty) (8.8.8.8), rcode=0 (No
Error), aa=0, in 30ms
[18] wikipedia.com: accept answer 'wikipedia.com|A|91.198.174.192' from '.'
nameservers? ttl=319, place=1 YES! - This answer was received from a server
we forward to.
[18] wikipedia.com: OPT answer '.' from '.' nameservers
[18] : got initial zone status Indeterminate for record wikipedia.com
[18] wikipedia.com: determining status after receiving this packet
[18] wikipedia.com: answer is in: resolved to '91.198.174.192|A'
[18] wikipedia.com: status=got results, this level of recursion done
[18] wikipedia.com: validation status is Indeterminate
0 [18/1] answer to question 'wikipedia.com|A': 1 answers, 1 additional,
took 1 packets, 30.615 netw ms, 30.737 tot ms, 0 throttled, 0 timeouts, 0
tcp connections, rcode=0

Other information

In version 4.0.4 of pdns-recursor this scenario works as expected and recursor is able to answer the queries using available cache entry until TTL expires

Usecase

Description

@rgacogne rgacogne added this to the rec-4.1.x milestone Mar 13, 2018

@rgacogne

This comment has been minimized.

Member

rgacogne commented Mar 13, 2018

Thank you for opening this issue! Initial discussion available at https://mailman.powerdns.com/pipermail/pdns-users/2018-March/025253.html :

I can indeed reproduce this issue. The root cause is that 4.1 only uses
non-authoritative cached data for "infra" queries, ie retrieving NS and
their IP addresses. This works quite well except for
forward-zones-recurse, where the answers come from a recursor instead of
an authoritative server and thus don't have the AA bit set.

So we probably need to either stop requesting authoritative answers from the cache for domains we forward-recurse to, or fake an authoritative answer for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment