I setup a local zone example.com and set the default ttl to 86400.
Use unbound as the recursive server and config a stub_zone example.com
address to the local server setup above.
When I dig example.com soa, I got the following answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;example.com. IN SOA
;; ANSWER SECTION:
example.com. 86400 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
;; AUTHORITY SECTION:
example.com. 86400 IN NS NS2.demo.example.com.
example.com. 86400 IN NS NS1.example.com.
example.com. 86400 IN NS NS3.noexist.cn.
;; ADDITIONAL SECTION:
NS1.example.com. 86400 IN A 10.53.0.2
NS2.demo.example.com. 86400 IN A 218.241.108.15
Then I dig noexist.example.com a, I got this:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20213
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;noexist.example.com. IN A
;; AUTHORITY SECTION:
example.com. 3600 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
Both of the above results seem to be fine, but when I dig
noexist.example.com again, the ttl of the soa record changed:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59999
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;noexist.example.com. IN A
;; AUTHORITY SECTION:
example.com. 86292 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
Anybody experienced the same thing as me? Whether the second answer should
use the original ttl of the soa record?
a message of 49 lines which said:
When I dig example.com soa, I got the following answer:
...
example.com. 86400 IN SOA NS1.example.com. root.example.com. 2010091701 3600 900 604800 3600
Fresh from the authoritative name server so TTL is the original value.
Then I dig noexist.example.com a, I got this:
...
example.com. 3600 IN SOA NS1.example.com. root.example.com. 2010091701 3600 900 604800 3600
"Artificial" value for the TTL, per RFC 2308, section 3. Nothing to do
with the value Unbound has in its cache.
I dig noexist.example.com again, the ttl of the soa record changed:
...
example.com. 86292 IN SOA NS1.example.com. root.example.com. 2010091701 3600 900 604800 3600
Original TTL of the SOA record, minus the 108 seconds elapsed between
the two tests. Not normal, should be 3600 again.
Whether the second answer should use the original ttl of the soa
record?
I agree with you.
Hi,
Bortzmeyer Sent On Friday, May 06, 2011 9:31 PM
> When I dig example.com soa, I got the following answer:
...
> example.com. 86400 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
Fresh from the authoritative name server so TTL is the original value.
> Then I dig noexist.example.com a, I got this:
...
> example.com. 3600 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
"Artificial" value for the TTL, per RFC 2308, section 3. Nothing to do
with the value Unbound has in its cache.
> I dig noexist.example.com again, the ttl of the soa record changed:
...
> example.com. 86292 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
Original TTL of the SOA record, minus the 108 seconds elapsed between
the two tests. Not normal, should be 3600 again.
According section 5 in RFC2308, it should be a bug of unbound, especially when the TTL and minimal of soa are different.
Thanks
Likun
Hi Likun,
Hi,
Bortzmeyer Sent On Friday, May 06, 2011 9:31 PM
When I dig example.com soa, I got the following answer:
...
example.com. 86400 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
Fresh from the authoritative name server so TTL is the original value.
Then I dig noexist.example.com a, I got this:
...
example.com. 3600 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
"Artificial" value for the TTL, per RFC 2308, section 3. Nothing to do
with the value Unbound has in its cache.
I dig noexist.example.com again, the ttl of the soa record changed:
...
example.com. 86292 IN SOA NS1.example.com.
root.example.com. 2010091701 3600 900 604800 3600
Original TTL of the SOA record, minus the 108 seconds elapsed between
the two tests. Not normal, should be 3600 again.
According section 5 in RFC2308, it should be a bug of unbound, especially when the TTL and minimal of soa are different.
Yes, there seems to be a bug. Unbound picks up the SOA from the
positive answer, with its longer TTL, and uses that to answer the
negative answer as well, mixing the positive-answer-SOA with the
negative-answer-SOA and getting the TTL wrong.
The negative answer does not get a longer cache time because of this.
That time is administered on its own, for the NXDOMAIN.
The TTL reported to downstream requestors, is then not correct. I am
not sure how to fix this, as unbound puts information in the RRset and
in the message cache.
Best regards,
Wouter