dump_cache strange format for PTR

Unbound
1

I run 'unbound-control dump_cache' and I get, among other things:

70.168.69.4.in-addr.arpa. 86252 IN PTR ae-2-70.edge3.Paris1.Level3.net.

msg 108.7.134.192.in-addr.arpa. IN PTR 32896 1 86250 3 1 1 0
108.7.134.192.in-addr.arpa. IN PTR 0

Why two different formats for these two IP addresses (and the second
one seems difficult to parse...)? Using dig gives
reasonable results:

% dig PTR 108.7.134.192.in-addr.arpa.

; <<>> DiG 9.10.3-P4-Debian <<>> PTR 108.7.134.192.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27699
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;108.7.134.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
108.7.134.192.in-addr.arpa. 172498 IN PTR mx80-1-sqy.interco.nic.fr.

;; AUTHORITY SECTION:
7.134.192.in-addr.arpa. 172498 IN NS ns1.nic.fr.
7.134.192.in-addr.arpa. 172498 IN NS ns2.nic.fr.
7.134.192.in-addr.arpa. 172498 IN NS ns3.nic.fr.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 17:23:25 CEST 2016
;; MSG SIZE rcvd: 148

dig PTR 70.168.69.4.in-addr.arpa.

; <<>> DiG 9.10.3-P4-Debian <<>> PTR 70.168.69.4.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22322
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;70.168.69.4.in-addr.arpa. IN PTR

;; ANSWER SECTION:
70.168.69.4.in-addr.arpa. 86089 IN PTR ae-2-70.edge3.Paris1.Level3.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 16 17:23:36 CEST 2016
;; MSG SIZE rcvd: 98

Version 1.5.9
linked libs: libevent 2.0.21-stable (it uses epoll), OpenSSL 1.0.2h 3 May 2016
linked modules: dns64 python validator iterator

2

Hi Stephane,

Your script is picking up the wrong parts as RRs. The other lines are
part of the message cache dump.

Look for these marker lines through the cachedump (perhaps with
csplit(1)?)

START_RRSET_CACHE
.. RRs
END_RRSET_CACHE
START_MSG_CACHE
.... not RRs!!
END_MSG_CACHE
EOF

Best regards, Wouter

3

a message of 93 lines which said:

Your script is picking up the wrong parts as RRs. The other lines
are part of the message cache dump.

OK, I never noticed there are two sections. Any way to dump only one?

Look for these marker lines through the cachedump (perhaps with
csplit(1)?)

My initial goal was to find a specific pattern in the RR cache. This
seems to work, thanks for the help:

findincache() {
    if [ -z "$1" ]; then
  echo "Usage: findincache PATTERN"
  return 1
    fi
    pat="$1"
    TMP=$(mktemp -d)
    cur="$(pwd)"
    cd "$TMP"
    sudo unbound-control dump_cache | csplit - /END_RRSET_CACHE/ > /dev/null
    egrep "$pat" xx00
    cd "$cur"
    rm -rf $TMP
}

% findincache nlnetlabs |head -n 2
nlnetlabs.nl. 10149 IN NS ns.nlnetlabs.nl.
nlnetlabs.nl. 10149 IN NS sec2.authdns.ripe.net.

% findincache 'renater\.fr\.\s+[0-9]+\s+IN\s+AAAA'
ns1.renater.fr. 15 IN AAAA 2001:660:3001:4002::2
ns2.renater.fr. 15 IN AAAA 2001:660:3001:4002::9