Inconsistent TTL in (nxdomain) responses,

Unbound
1

Hi,

I configured a stub-zone for testing a new zone that solely responds nxdomain with a min ttl of 1 week on all PTR’s
Assumption is that unbound would limit the TTL to the value configured in unbound.conf that equals 1 day by default.

cache-max-ttl: 86400

I noticed that unbound responds with either the TTL configured in the zone or the cache-max-ttl. The inconsistency in ttl in the answers seem to be sort of random to me.
To be sure only 1 cache wil be used, I set the thread number to 1.

Stub-zone conf

stub-zone:
name: “98.95.in-addr.arpa.”
stub-host: ns1.info.nl.
stub-host: ns2.info.nl.
stub-host: ns2.info.nl.

Tcpdump shows that the auth nameserver is consulted only once for 95.98.40.50 and returns a min ttl of 1 week.

pkill unbound

/opt/unbound-1.4.8/sbin/unbound

[1299446231] unbound[8183:0] warning: increased limit(open files) from 1024 to 8338

dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40349
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604800 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 531 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:15 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62410
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604798 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:17 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.51

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.51
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17167
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;51.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 86400 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 86400

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:21 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58939
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 86397 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:24 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45396
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 86393 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:28 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.53

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.53
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39376
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;53.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 86400 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 86400

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:31 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.535

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.535
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33243
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;535.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 86400 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 86400

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:33 2011
;; MSG SIZE rcvd: 101

dig @localhost -x 95.98.40.54

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.54
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33576
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;54.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604800 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:38 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.54

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.54
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14717
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;54.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604797 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:41 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.53

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.53
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21754
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;53.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604795 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:43 2011
;; MSG SIZE rcvd: 100

dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48501
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604792 IN SOA ns1.info.nl. postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:46 2011
;; MSG SIZE rcvd: 100

Is this a bug or am I missing something obvious here?

Thanks,
Mike

2

Hi Michael,

Hi,

I configured a stub-zone for testing a new zone that solely responds
nxdomain with a min ttl of 1 week on all PTR's
Assumption is that unbound would limit the TTL to the value configured
in unbound.conf that equals 1 day by default.

cache-max-ttl: 86400

Yes that works. This TTL is used internally, the client sees the
original large TTL value.

I noticed that unbound responds with either the TTL configured in the
zone or the cache-max-ttl. The inconsistency in ttl in the answers seem
to be sort of random to me.

You did not configure your 1week TTL properly. Just dig @ns1.info.nl
and you see that for NXDOMAIN you get 24hr TTL.

# dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40349
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604800 IN SOA ns1.info.nl.
postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 531 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:15 2011
;; MSG SIZE rcvd: 100

# dig @localhost -x 95.98.40.50

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.50
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62410
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 604798 IN SOA ns1.info.nl.
postmaster.info.nl. 2010067876 3600 900 1209600 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:17 2011
;; MSG SIZE rcvd: 100

# dig @localhost -x 95.98.40.51

; <<>> DiG 9.4.2-P2 <<>> @localhost -x 95.98.40.51
; (3 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17167
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;51.40.98.95.in-addr.arpa. IN PTR

;; AUTHORITY SECTION:
98.95.in-addr.arpa. 86400 IN SOA ns1.info.nl.
postmaster.info.nl. 2010067876 3600 900 1209600 86400

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 6 22:17:21 2011
;; MSG SIZE rcvd: 100

Notice here the SOA with 2010067876 3600 900 1209600 86400
is different from the SOA 2010067876 3600 900 1209600 604800
above. Your authority server is giving the different responses.
(are your ns1, ns2, ns3 properly in sync? Incremented SOA serial?)

Best regards,
   Wouter

3

Hi Wouter,

You are correct, ns2 is not consistent with the other ns.
I knew it had to be something obvious :s

Thanks,
Mike

4

Hi,

What about the 'other way around' ?

Is there a TTL-value setting in Unbound which will send a lower TTL to
clients and keep it cached normally ?

I've found this to be very useful for people who deal with frequently
changing domains and using them shortly after.

Because it is pretty easy to just clear the cache (of that DNS-entry)
centrally at the recursors, through the same webinterface which also
handles doing DNS changes.

I currently point these users at a dnscache which forwards queries to a
'normal' recursor. It has a HIDETTL-setting, although it sets the TTL to
0. That is really very low.

Thus not so great.

Have a nice day,
    Leen.